I have a subclass set up on a VB combobox hosted on a usercontrol. The usercontrol
is inside another usercontrol which is in a frame on a form. There are a
lot of windows in this app, probably 100 or so API windows.

Anyway, I'm wondering if it is possible for SetWindowLong to fail to deliver
a window message once in a blue moon. Or maybe VB is doing a setwindowlong
on top of my setwindowlong, then removing it.

Here is the problem. My combo box doesn't get WM_KEYDOWN, WM_CHAR, or WM_KEYUP
messages when I type the arrow keys. I DO get those messages when I type
other characters like the letters. I am using a custom subclassing component
that works well (AFAIK) and I wrote it. Looking at the component, I am NOT
getting any window messages to the combo box's hwnd when I type the up/down
arrow keys to the window function I SetWindowLong against. Except for a
WM_COMMAND message telling the combo to scroll its selection down or up,
that is.

When I use Spy++ to subclass the combo, Spy++ DOES see the character up /
down messages / char messages!

Maybe VB is hooking the SendMessage / Postmessage DLL entry points and eating
the messages and moving the combo box itself?

The weird thing is, when I try this same test with a combo sitting by itself
on a form, my subclass DOES see the WM_CHAR, WM_KEYUP, WM_KEYDOWN messages!

I've got a weird sneaking suspicion that some weird thing VB does with focus
management is making it do some kind of hook that takes precedence over my
SetWindowLong call.


AARRRRRGH!

Matthew Cromer