How to get Window Handles in VBA

jal

Registered User.
Local time
Today, 11:46
Joined
Mar 30, 2007
Messages
1,709
Out of curiosity, suppose a VBA control seems to be lacking a feature and so I decide to modify the control's behavior using a Windows API call.

Don't I need a handle on the control to do it? How do I get a handle on it?

Access forms have a handle property as I recall, but I'm talking about other controls such as textboxes, cbos, listboxes, etc.
 
There's hWnd property, but even then I'm not entirely sure this will work. The thing is that Access controls are not derived from common controls as seen in other Windows. On usenet, some speculates that it's just a lookalike with different codebase. One supporting evidence is the tiny difference in how listbox renders the scrollbars. In any other applications or Windows control panel, the textbox's scrollbars are always visible, but could be grayed out if the list didn't extend beyond the listbox. OTOH, Access's textbox's scrollbars are visible *only* if it has the focus and the list is long enough. This can be a bit confusing (IMHO) to users who would think that it's a textbox limited to so many lines.

Thus, if the Access controls are not in fact derived from common controls use everywhere else, then it may not always work correctly. I am not saying it won't. I just don't know and wouldn't expect it to.

What are you trying to fill in?
 
There's hWnd property, but even then I'm not entirely sure this will work.
Well that's the thing. In VB6 I see this property, but not in Access VBA, at least not in in Intellisense. For instance I tried:

cbo.hwnd

but that property doesn't show in Intellisense.

What are you trying to fill in?
The question came to mind today while wrestling with a cbo. I just thought it would be nice to have some Windows API options at my disposal. I don't have in mind anything specific at the moment.
 
Ken Getz et al first stated many years ago that Access controls are merely paint on screen and only the active control becomes a legitimate window to which a handle can be retrieved. (At least to any reliable extent).
Even events like GotFocus don't sufficiently guarantee that the control has become an active window. In theory only the OnChange event is reliable enough. The standard example cited is for limiting characters typed in a textbox (an obvious implementation of the OnChange event).

I'd imagine you could do more (in different events) with lots of checking to verify the existence of the window and active control.

Cheers.
 
Ken Getz et al first stated many years ago that Access controls are merely paint on screen and only the active control becomes a legitimate window to which a handle can be retrieved. (At least to any reliable extent).
Even events like GotFocus don't sufficiently guarantee that the control has become an active window. In theory only the OnChange event is reliable enough. The standard example cited is for limiting characters typed in a textbox (an obvious implementation of the OnChange event).

I'd imagine you could do more (in different events) with lots of checking to verify the existence of the window and active control.

Cheers.

Leigh,

Great info. thanks.

Cheers.
 
Hi Boyd.

Nice to see you over here too.
(What can I say - I'm a question *****. I go where there are vaguely interesting ones lol).

There's no such emoticon here it seems - but none the less...
:thumbup:

;-)

Cheers.
 

Users who are viewing this thread

Back
Top Bottom