Lots of people ask how a window like a combo box can cover a large part of the screen but only make use of the bottom part when it drops down the window. It does not affect the underlying windows any other time, letting you get straight to the windows underneath via mouse clicks. And you can write a small program to check that the combo box is not changing its size when the drop down list is lowered. It is that size all of the time, also obvious when you use the dialog editor to draw them.
Effectively what is happening is that the combo box is selectively making parts of itself transparent visuall and to input. Now everyone probably knows that its easy to make a window visual transparent by just not drawing anything during its painting events. Usually they first find this out by accident and wonder why their window seems to be dragging around a bit of the desktop background. But how do you make the window selectively transparent to mouse clicks?
Hit Testing
When it is time to dispatch a mouse event to a window, PM will send it a WM_HITTEST message. The window can respond it one of four ways by returning one of the HT_xxxx values.
In the first instance, the event is passed on to the window. In the second case, WM_HITTEST is passed to the next control in the z-order chain that contains the coordinate of the mouse event. In the third case, the event is just eaten. In the last case, the window is brought to the foreground and PM beeps at you, but the mouse event is otherwise eaten with no effect. This is how disabled windows can easily ignore mouse events but still get the required button down effect of coming to the foreground.
From that explanation, it's probably pretty obvious now how a combo box does its thing. When it gets a WM_HITTEST, it checks whether the event is over a part of itself that is not transparent. If the list is dropped down, then either the list box or entry field will get the message and just return HT_NORMAL. If the button hits the backing window, because the list box is not covering it, it just returns HT_TRANSPARENT and the button goes on to the window that is visible 'through' the combo box.
Handling Your Own Hit Testing
In your own window classes you likely never need to handle WM_HITTEST. You can just let it pass on to WinDefWindowProc(), which just returns HT_NORMAL to let the mouse event come to the window or HT_ERROR if the window is disabled. This is the correct behavior 99.99% of the time. If you do need to handle it, just use the passed mouse position to determine if your window is transparent to mouse input there and return the appropriate hit test result. This result will be passed to the actual mouse event later, as one of the message parameters (which is probably pretty universally ignored but its there.)
Copyright Notice
| Reply to Author
| Search
| Section Index
| Previous Page
| Next Page
If you see a problem with this web site, contact
edm2_eds@iqpac.com.