jrv@demon.siemens.com (James R Vallino) (03/15/91)
I am starting to learn Windows code development using the Petzold book and
the SDK. I am using the first version of the book which I have had for a
while. The discussion of controls does not include ComboBoxes since these
were added in Windows 3.0. I decided to try modifying one of the programs
which used a List box to use a ComboBox instead.
The 'head' program in the book creates two child windows in the client area:
one static to display a file name, and the other as a List box of file names.
I changed the List Box to a Combo box. The program more or less works (I
still don't quite have the keyboard interface functioning correctly.) but
there is something weird which I do not understand.
If the list box is dropped down under the edit box, and I move the window on
the screen everything except the list box part of the combo box moves. I
can slide the window right out from under the list box. If the window is
minimized the list box is removed but when brought back the list box is in
the same place outside of the client area of its parent window. Why does
this control seem to break up into multiple parts? Shouldn't it all at
least stay within the client area of the control's parent?
The combo box window was created with the following style:
WS_CHILD | WS_VISIBLE | CBS_DROPDOWN | CBS_SORT | WS_VSCROLL | WS_BORDER
Is there something else which I need to do to keep the combo box all
together?
Thanks for any help!
--
Jim Vallino Siemens Corporate Research, Inc., Princeton, NJ
jrv@demon.siemens.com
princeton!siemens!demon!jrv
(609) 734-3331bonneau@hyper.hyper.com (Paul Bonneau) (03/17/91)
In article <55579@siemens.siemens.com> jrv@demon.siemens.com writes: >The 'head' program in the book creates two child windows in the client area: >one static to display a file name, and the other as a List box of file names. >I changed the List Box to a Combo box. The program more or less works (I >still don't quite have the keyboard interface functioning correctly.) but >there is something weird which I do not understand. > >If the list box is dropped down under the edit box, and I move the window on >the screen everything except the list box part of the combo box moves. I >can slide the window right out from under the list box. If the window is >minimized the list box is removed but when brought back the list box is in >the same place outside of the client area of its parent window. Why does >this control seem to break up into multiple parts? Shouldn't it all at >least stay within the client area of the control's parent? > I am pretty sure your problem is that the windows dialog manager is not being used to control the combo. Normally, a mouse click anywhere outside the dropped list will collapse it. So, if you call IsDialogMessage() in your main message loop with the window handle of the combo's parent, things should work much better. IsDialogMessage() allows the dialog manager to interpret messages for control-specific interaction. cheers - Paul Bonneau.
gpsteffl@sunee.waterloo.edu (Glenn Patrick Steffler) (03/18/91)
In article <55579@siemens.siemens.com> jrv@demon.siemens.com writes: >If the list box is dropped down under the edit box, and I move the window on >the screen everything except the list box part of the combo box moves. I Ha ha ha ... this little doozy hit me a little while ago whilst writing a window class handler for half-height cations, and 3-d boders around the window. I was capturing every WM_NC* message known to DefWindowProc in order to acheive this (daunting) task. Unfortunately, after placing a combobox control in one of these windows the above happened. (anyway, I digress...) Solution: Trap WM_SYSCOMMAND, and place a SetActiveWindow (handle of window passed in) n the SC_MOVE case. Worked fine for me...and even works when the application moves the window with a SetWindowPos() call. >can slide the window right out from under the list box. If the window is >minimized the list box is removed but when brought back the list box is in >the same place outside of the client area of its parent window. Why does >this control seem to break up into multiple parts? Shouldn't it all at >least stay within the client area of the control's parent? The dialog box handles the messages to allow the combo box to operate correctly. DefWindowProc does not provide this functionality. Done. >Jim Vallino Siemens Corporate Research, Inc., Princeton, NJ >jrv@demon.siemens.com >princeton!siemens!demon!jrv >(609) 734-3331 -- Co-Op Scum "Bo doesn't know software" - George Brett "The galaxial hearth steams the sea as the sky blood red embrasses darkness" -John Constantine (HellBlazer) Glenn Steffler