[lazarus] ComboBox problems
nc-gaertnma at netcologne.de
Fri Aug 15 02:51:11 EDT 2003
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
> >>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);
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.
> > 1) This is to late. A SetBounds sends a WM_SIZE message after LCL
> > internal resizing.
> I think you're saying a LM_SETSIZE, that in most cases will have no
> effect, will not generate a WM_SIZE (because win32 ignores when you try to
> set the size/position with the current/actual values, which is the most of
> the cases)
The LCL will send LM_SETSIZE only, if the new bounds differ from the last
> 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
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
> > 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.
More information about the Lazarus