[comp.windows.ms.programmer] What don't I understand about ComboBoxes?

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-3331

bonneau@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