Comboex: CBES_EX_NOSIZELIMIT

[Bill Medland]

----- Original Message -----
From: "Bill Medland" <billmedland at look.ca>
To: <dimi at bigfoot.com>
Cc: <wine-devel at winehq.org>
Sent: Wednesday, August 21, 2002 12:13 PM
Subject: Re: Comboex: CBES_EX_NOSIZELIMIT


> ----- Original Message -----
> From: "Dimitrie O. Paun" <dimi at bigfoot.com>
> To: "Bill Medland" <billmedland at look.ca>
> Cc: <wine-devel at winehq.org>
> Sent: Wednesday, August 21, 2002 11:45 AM
> Subject: Re: Comboex: CBES_EX_NOSIZELIMIT
>
>
> > On August 21, 2002 02:21 pm, Bill Medland wrote:
> > > Coincidentally I am just starting to investigate an issue with our
> software
> > > that relates to the ComboBox code so since you are thinking about it
> maybe
> > > you can bear it in mind.
> >
> > That's an interesting point, and I think it's related to my question, if
> only
> > from the perspective that it might help us understand things better in
> > this area.
> >
> > But to be honest with you, I'm don't understand exactly how you
> > set the size of the the Combo and how you set the size of the Listbox
> > (when you have a dropdown combo).
> >
> > All these are related:
> >   -- we change the size of the combo when we should change just
> > the size of the Listbox (your problem)
> >   -- when we do change the size of the comboex, we should limit
> > it (I think) to the size of Listbox unless we have the NOSIZELIMIT
> > flag set (my problem).
> >
> > It seems we have 3 sizes here:
> >
> >  +=========+
> >  |  ________    |
> >  |  |_______|    |
> >  |  {                }    |
> >  |  {_______}    |
> >  +=========+
> >
> >
> >  The = is the comboex window
> >  The -- is the combo
> >  The {} is the listbox
> >
> > Right?
> >
> > --
> > Dimi.
> >
> >
> I agree
> (Small issue while we are on the subject.  "Setting position" should
> presumably do everything based upon the listbox appearing below the main
> window even though it may be near the bottom of the screen which would
cause
> the listbox to be painted above it).
>
> I am just about to try getting a decent log of associated messages which
> will help; I'll post it when I have it.

OK.  Here it is

We have a call to SetWindowPos

<00362> 00000EE4 S ..WM_WINDOWPOSCHANGING lpwp:0064F224
<00363> 00000EE4 R ..WM_WINDOWPOSCHANGING

(The above call disappears if SWP_NOSENDCHANGING is specified)

<00364> 00000EE4 S ..WM_NCCALCSIZE fCalcValidRects:True lpncsp:0064F1F0
<00365> 00000EE4 R ..WM_NCCALCSIZE fuValidRect:0000 lpncsp:0064F1EC
<00366> 00000EE4 S ..WM_CHILDACTIVATE
<00367> 00000EE4 R ..WM_CHILDACTIVATE

(The following occurs even if SWP_NOSENDCHANGING is specified)

<00368> 00000EE4 S ..WM_WINDOWPOSCHANGED lpwp:0064F260
<00369> 00000EE4 S ...WM_SIZE fwSizeType:SIZE_RESTORED nWidth:307 nHeight:52
<00370> 00000EE4 S ....WM_WINDOWPOSCHANGING lpwp:0064EBFA
<00371> 00000EE4 R ....WM_WINDOWPOSCHANGING
<00372> 00000EE4 S ....WM_NCCALCSIZE fCalcValidRects:True lpncsp:0064EBC6
<00373> 00000EE4 R ....WM_NCCALCSIZE fuValidRect:0000 lpncsp:0064EBC2
<00374> 00000EE4 S ....WM_WINDOWPOSCHANGED lpwp:0064EC36
<00375> 00000EE4 S .....WM_SIZE fwSizeType:SIZE_RESTORED nWidth:307
nHeight:21
<00376> 00000EE4 R .....WM_SIZE
<00377> 00000EE4 R ....WM_WINDOWPOSCHANGED
<00378> 00000EE4 S ....WM_PAINT hdc:00000000
<00379> 00000EE4 S .....WM_NCPAINT hrgn:00000001
<00380> 00000EE4 R .....WM_NCPAINT
<00381> 00000EE4 S .....WM_ERASEBKGND hdc:00001B6E
<00382> 00000EE4 R .....WM_ERASEBKGND fErased:True
<00383> 00000EE4 R ....WM_PAINT
<00384> 00000EE4 R ...WM_SIZE
<00385> 00000EE4 R ..WM_WINDOWPOSCHANGED

followed by a call to ResizeClient (Don't ask me why)

<00386> 00000EE4 S ..WM_WINDOWPOSCHANGING lpwp:0064F1F8
<00387> 00000EE4 R ..WM_WINDOWPOSCHANGING
<00388> 00000EE4 S ..WM_NCCALCSIZE fCalcValidRects:True lpncsp:0064F1C4
<00389> 00000EE4 R ..WM_NCCALCSIZE fuValidRect:0000 lpncsp:0064F1C0
<00390> 00000EE4 S ..WM_CHILDACTIVATE
<00391> 00000EE4 R ..WM_CHILDACTIVATE
<00392> 00000EE4 S ..WM_WINDOWPOSCHANGED lpwp:0064F234
<00393> 00000EE4 S ...WM_SIZE fwSizeType:SIZE_RESTORED nWidth:307 nHeight:52
<00394> 00000EE4 S ....WM_WINDOWPOSCHANGING lpwp:0064EBCE
<00395> 00000EE4 R ....WM_WINDOWPOSCHANGING
<00396> 00000EE4 S ....WM_NCCALCSIZE fCalcValidRects:True lpncsp:0064EB9A
<00397> 00000EE4 R ....WM_NCCALCSIZE fuValidRect:0000 lpncsp:0064EB96
<00398> 00000EE4 S ....WM_WINDOWPOSCHANGED lpwp:0064EC0A
<00399> 00000EE4 S .....WM_SIZE fwSizeType:SIZE_RESTORED nWidth:307
nHeight:21
<00400> 00000EE4 R .....WM_SIZE
<00401> 00000EE4 R ....WM_WINDOWPOSCHANGED
<00402> 00000EE4 S ....WM_PAINT hdc:00000000
<00403> 00000EE4 S .....WM_NCPAINT hrgn:00000001
<00404> 00000EE4 R .....WM_NCPAINT
<00405> 00000EE4 S .....WM_ERASEBKGND hdc:0000235A
<00406> 00000EE4 R .....WM_ERASEBKGND fErased:True
<00407> 00000EE4 R ....WM_PAINT
<00408> 00000EE4 R ...WM_SIZE
<00409> 00000EE4 R ..WM_WINDOWPOSCHANGED

I have just submitted the patch to get SetWindowPos to send the
WM_POSCHANGED.

So we can't do the size check in the WM_WINDOWPOSCHANGING code; it may not
be executed.

What I see happening is that the first WM_SIZE is being passed a different
size from the current size and different from the size of the text.  As a
result (of which difference?) it itself resizes down to the text size.

>
> I just spotted some of the relevant code; I guess the bit that confuses me
> is that in our case we appear to have specified not to send all sorts of
> messages which presumably only leaves the NCCALCSIZE to be sent.  But does
> that mean that windows is actually modifying the properties of the combo
box
> on the basis of what is in reality purely a question?

No.  See above

>
> Haven't we got fun!!
>
> Bill
>
>
>
Bill