MSForms UserForm Window Handle - Win32 API Call from VBA
 

Hello,

Is there anyone out there that can maybe help me with some code or the name
of the Win32 API function to obtain the window handle of an MSForms UserForm
and/or control on that form?

Let me explain a bit further. I've created a large model/application
(xl2003, WinXP Pro) - works peachy. I've also created a compiled help file
with HTMLHelp (*.chm) - again, no problems. Declaring and then calling the
HTMLHelp API in hhctrl.ocx successfully links the compiled help topics to the
Excel application.

All great so far, but I have also created context-sensitive popup text help
which used to work great in the 'good old days' of WinHelp (*.hlp) and Help
Workshop via the "What's This" button. Things are different now.

What I can successfully do in Access is write code for the MouseUp event of
an Access Form control to call the HTMLHelp API function and pass the
relevant parameters required. I intercept the right mouse button click and
'presto' my text popups appear perfectly. The kicker is that this relies on
passing the built-in .hWnd property of Access Forms to the HTMLHelp API
function. (I also make use of the GetDlgCtrlID API function to pass the
relevant Access Form control's identifier and context-sensitive help text to
the HTMLHelp API function call).

Excel MSForms don't seem to have the same built-in .hWnd property available,
so I'm thinking that I need to make a call to another Win32 API function in
order to return the window handle of my MSForms UserForm in Excel. I've spent
the best part of a week searching and trying different functions and methods
to obtain and return a) the window handle of an MSForms UserForm and
subsequently by using GetDlgCtrlID; b) the UserForm control's identifier.

Is this even possible? Does anyone out there know how. Extremely grateful
for any tips, assistance or suggestions that anyone can provide. Let me know
if more info is needed from me.

Thanks and Regards, Sean.

MSForms UserForm Window Handle - Win32 API Call from VBA
 

the class name for the form is ThunderXFrame or ThunderDFrame depending on
the version of Excel. So you can use findwindow with that. The MSforms 2.0
controls are windowless controls, so I don't know if your GetDlgCtrlID API
function will work or not since I don't know anything about it.

--
Regards,
Tom Ogilvy


"Sean Connolly" .(DoNotSpam) wrote in
message ...
Hello,

Is there anyone out there that can maybe help me with some code or the
name
of the Win32 API function to obtain the window handle of an MSForms
UserForm
and/or control on that form?

Let me explain a bit further. I've created a large model/application
(xl2003, WinXP Pro) - works peachy. I've also created a compiled help file
with HTMLHelp (*.chm) - again, no problems. Declaring and then calling the
HTMLHelp API in hhctrl.ocx successfully links the compiled help topics to
the
Excel application.

All great so far, but I have also created context-sensitive popup text
help
which used to work great in the 'good old days' of WinHelp (*.hlp) and
Help
Workshop via the "What's This" button. Things are different now.

What I can successfully do in Access is write code for the MouseUp event
of
an Access Form control to call the HTMLHelp API function and pass the
relevant parameters required. I intercept the right mouse button click and
'presto' my text popups appear perfectly. The kicker is that this relies
on
passing the built-in .hWnd property of Access Forms to the HTMLHelp API
function. (I also make use of the GetDlgCtrlID API function to pass the
relevant Access Form control's identifier and context-sensitive help text
to
the HTMLHelp API function call).

Excel MSForms don't seem to have the same built-in .hWnd property
available,
so I'm thinking that I need to make a call to another Win32 API function
in
order to return the window handle of my MSForms UserForm in Excel. I've
spent
the best part of a week searching and trying different functions and
methods
to obtain and return a) the window handle of an MSForms UserForm and
subsequently by using GetDlgCtrlID; b) the UserForm control's identifier.

Is this even possible? Does anyone out there know how. Extremely grateful
for any tips, assistance or suggestions that anyone can provide. Let me
know
if more info is needed from me.

Thanks and Regards, Sean.

MSForms UserForm Control Identifier - Win32 API Call from VBA
 

Many thanks Tom,

FindWindow("ThunderDFrame", vbNullString) works just great to return the
window handle of the MSForms UserForm object. (As does GetActiveWindow() -
xl2003, WinXP Pro).

However, I'm still having some trouble obtaining the control identifier of
the relevant controls on that MSForms UserForm. (Maybe this might be what you
meant by 'windowless controls'?). GetDlgCtrlID is simply another Win32 API
function declared as follows:

Declare Function GetDlgCtrlID Lib "user32" (ByVal hWnd As Long) As Long

Where hWnd is the handle of the window (or control) for which you want the
control identifier returned. Works perfectly on Access and Windows Forms.

Logically enough, passing the window handle of an MSForms UserForm to
GetDlgCtrlID returns 0 (null) - it doesn't have a control identifier because
it is not a 'control'.

So what I need to do (if it is even possible, or unless there is another way
that you or one of the other gurus here can advise) is obtain the window
handle of each control on the MSForms UserForm that I want to add
context-sensitive help to so that I can pass that to GetDlgCtrlID and obtain
the control identifier to pass to HtmlHelp. (Phew!). Do MSForms userform
controls (ListBox, CommandButton etc.) also have class names (as for
'ThunderDFrame')?

I'm continuing to search and poke around, but any further assistance or tips
that you or anyone else here can provide *very* gratefully received.

Thanks again, Sean.

"Tom Ogilvy" wrote:

the class name for the form is ThunderXFrame or ThunderDFrame depending on
the version of Excel. So you can use findwindow with that. The MSforms 2.0
controls are windowless controls, so I don't know if your GetDlgCtrlID API
function will work or not since I don't know anything about it.

--
Regards,
Tom Ogilvy


"Sean Connolly" .(DoNotSpam) wrote in
message ...
Hello,

Is there anyone out there that can maybe help me with some code or the
name
of the Win32 API function to obtain the window handle of an MSForms
UserForm
and/or control on that form?

Let me explain a bit further. I've created a large model/application
(xl2003, WinXP Pro) - works peachy. I've also created a compiled help file
with HTMLHelp (*.chm) - again, no problems. Declaring and then calling the
HTMLHelp API in hhctrl.ocx successfully links the compiled help topics to
the
Excel application.

All great so far, but I have also created context-sensitive popup text
help
which used to work great in the 'good old days' of WinHelp (*.hlp) and
Help
Workshop via the "What's This" button. Things are different now.

What I can successfully do in Access is write code for the MouseUp event
of
an Access Form control to call the HTMLHelp API function and pass the
relevant parameters required. I intercept the right mouse button click and
'presto' my text popups appear perfectly. The kicker is that this relies
on
passing the built-in .hWnd property of Access Forms to the HTMLHelp API
function. (I also make use of the GetDlgCtrlID API function to pass the
relevant Access Form control's identifier and context-sensitive help text
to
the HTMLHelp API function call).

Excel MSForms don't seem to have the same built-in .hWnd property
available,
so I'm thinking that I need to make a call to another Win32 API function
in
order to return the window handle of my MSForms UserForm in Excel. I've
spent
the best part of a week searching and trying different functions and
methods
to obtain and return a) the window handle of an MSForms UserForm and
subsequently by using GetDlgCtrlID; b) the UserForm control's identifier.

Is this even possible? Does anyone out there know how. Extremely grateful
for any tips, assistance or suggestions that anyone can provide. Let me
know
if more info is needed from me.

Thanks and Regards, Sean.