I have a CComboBox, along with some other controls, on a custom-written display that for the most part does its own painting. Normally the display is embedded in a section of a window, although it has the option of going to full-screen mode, where, it uses GetDesktopWindow() to disassociate itself from the background application - setting its parent window to the result of GetDesktopWindow()which then causes it to use the full size of the screen to display itself.
When I do this, the combo box stops working.
The second thing is that the ComboBox is out of place when you switch between the embedded view and the full-screen view. You can actually see the display going black, except where the ComboBox was, where it leaves a little desktop-background hole, before it renders itself in an unresponsive state.
Reversing this process, i.e. toggling the display back into a section of the main app window, makes the combo box work as normal, although it's still out of place.
Now I've read up on what might be cauing this problem and seen that using GetDesktopWindow is a bad idea, but I've also heard Combo Boxes are a little tricky when doing this sort of thing on XP, which I'm using. I'm also concerned about which windows messages the display is receiving - it seeems to receive a lot more when it's part of another window. Using Spy++, it looks as if mouse events, some but not as many as when in "windowed mode", are getting to it but not being processed. The other controls work fine, but they have their own paint and hit test functions written for them.
What do I need to do to get the combo box working again? Redraw it somewhere in the code when resizing? Sub-class it and write a handler for it, like the other controls? Make the control part of a separate Window which somehow uses the whole screen and has no frame/dialog controls?