[lazarus] ComboBox problems

Mattias Gaertner nc-gaertnma at netcologne.de
Fri Aug 15 06:15:15 EDT 2003


On Fri, 15 Aug 2003 11:25:46 +0200
"Marc Weustink" <marc.weustink at cuperus.nl> wrote:

> + From: Mattias Gaertner [mailto:nc-gaertnma at netcologne.de]
> + Sent: vrijdag 15 augustus 2003 9:05
> +
> + On Thu, 14 Aug 2003 22:22:11 -0300
> + Karl Brandt <pascalive at bol.com.br> wrote:
> +
> + > Mattias Gaertner wrote:
> + > > On Thu, 14 Aug 2003 14:02:11 -0300
> + > > Karl Brandt <pascalive at bol.com.br> wrote:
> + > >
> + > >
> + > >>Mattias Gaertner wrote:
> + > >>
> + > >>>Karl Brandt <pascalive at bol.com.br> wrote:
> + > >>>
> + > >>>
> + > >>>>  Height is set to 100
> + > >>>>  WM_SIZE message with parameter = 100
> + > >>>>  Default window proc is called
> + > >>>>     Height is modified to 21
> + > >>>>     a new WM_SIZE message is sent with parameter = 21
> + > >>>>     LCL is updated with Height = 21
> + > >>>>  Default window proc finishes and returns to WindowProc
> + > >>>>  LCL is updated with Height = 100
> + > >>>>  Now we have diferents sizes between LCL and win32
> + > >>>>  with TWin32Object.SetComboMinDropDownSize the height
> + > >>>>  goes to more then 1000 easily. This is not noted
> + > >>>>  because win32 ignores it and adjust the dropdown
> + > >>>>  according to the number of items
> + > >>>>
> + > >>>>I see the following solutions
> + > >>>>1) Call DefWindowproc after sending the message to LCL
> + > >>>>   But this can affect other messages/controls
> + > >>>>2) Implements a TCustomComboBox.WMSize proc that retrieves the
> + > >>>>   current/real size from interface and call inherited with
> + > >>>>   updated value
> + > >>>>3) sends a WM_SIZE message with correct value -> did in the patch
> + > >>>
> + > >>>
> + > >>>The 3) is right. Whenever the LCL or the interface changes
> + > >>>the height, a WM_SIZE message should be sent to tell the other.
> + > >>>
> + > >>
> + > >>The downside of this approach is that the LCL is asked
> + > >>three times to change the height each time the size is updated in
> + > >>interface.
> + > >>In the above example changes to 21 -> 100 -> 21
> + > >>What do you,and other developers, think about 1) and 2)?
> + > >
> + > >
> + > > 2) is combobox specific. The problem exists for all controls. I
> think,+ > > TWinControl should be advanced.
> + >
> + > AFAIK it's related only for ComboBox
> +
> + I ment the general problem, that the interface does not always follow
> the+ resizing requests of the LCL. For example: Under gtk you can not
> + change the width of a vertical scrollbar.
> +
> +
> + > I was thinking about something like this:
> + > procedure TCustomComboBox.WMSize(var Message: TLMSize);
> + > begin
> + >    GetWindowSize(FHandle,Message.Width,Message.Height);
> + >    Inherited;
> + > end;
> +
> + I'm not sure, if I can follow you.
> + The WMSIZE messages are notifications, that a control has been resized.
> If+ the WMSIZE message comes from the interface, it should already contain
> the+ correct values. Other sources should use SetBounds.
> 
> Indeed, the win32interface itself can IMO makeup what it is sending as
> WM_SIZE messages to the LCL. The Interface knows what the correct size is
> of a widget. IMO it is a BadThing to modify TCustomComboBox for that.
> If the win32interface exacly knows what the heigt of a combo would be I
> have no problem that the interface send a WM_SIZE message 3 times with the
> same height. Caution, be sure you know ther height, its change may be
> valid as a result of font and or theme change.
> 
> [snip]
> 
> + > Back with combo: DefWindowProc for comboboxes in win32 resizes the
> + > control and call the control windowproc that,for your time, call LCL.
> + > what is happening now:
> + >    first LCL receives right value from the nested WindowProc(called by
> + >    DefWindowProc)
> +
> + But it lacks the information, that the height is fixed and the width is
> + variable. So, how can the LCL know, that there are some constraints?
> +
> +
> + >    then LCL receives invalid value overriding the previous one
> +
> + Who is sending the wrong values?
> +
> +
> + > If the cited order is inverted then LCL will receive the right size at
> + > last
> + >
> + > >
> + > > What about this:
> + > > TWinControl already uses DoConstrainedResize before resizing.
> + > > We can add
> + > > a function, which asks the interface to apply interface specific
> + > > constraints, before resizing occurs.
> 
> I think the interface doesn't always know this, so there should be a
> general"handling" anyhow. In case of a working general handling, I don't
> see the need for extra case specific functionality in the LCL.

You are right. There is no real need.
It is only for optimization and avoiding circles.
For example, when the user changes the width of a vertical scrollbar to 20,
the LCL will automatcially resize all aligned controls and then it sends the
setsize message to the interface. The gtk ignores the width change and sets
the width to say 14 and sends a size message back. Then the LCL resizes the
aligned controls again.
If we add an interface constraint function, the SetBounds (ChangeBounds)
method would first ask the interface to apply some constraints. The gtk
interface knows in this case, that a vertical scrollbar has a fixed size and
will change the width. Then the auto aligning of the LCL occurs. And only
once. 
Under the gtk interface you will not see any acceleration, because of the
caching. But it will surely make it easier for the win32 intf and other yet
to come interfaces.
So, although this function is rarely used and it is not really needed, it
reduces some overhead.

 
> Again, I think poking around in the LCL to solve interface specifig things
> should be avoided. 

yep. But I think the struggle between the autosizing of the LCL and
interface limits can be called interface independent.


> If a interface sends a "wrong" value, it shouldn't be
> solved in the LCL, it should be solved in the  interface.

yep


> So I prefer option 3, with the correct sizes.



Mattias






More information about the Lazarus mailing list