[lazarus] ComboBox problems

[Marc Weustink]

+ 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.

Again, I think poking around in the LCL to solve interface specifig things
should be avoided. If a interface sends a "wrong" value, it shouldn't be
solved in the LCL, it should be solved in the  interface.
So I prefer option 3, with the correct sizes.

Marc