[lazarus] ComboBox problems

Karl Brandt pascalive at bol.com.br
Thu Aug 14 21:23:53 EDT 2003

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 was thinking about something like this:
procedure TCustomComboBox.WMSize(var Message: TLMSize);

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

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
   then LCL receives invalid value overriding the previous one

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. 


More information about the Lazarus mailing list