[lazarus] ComboBox problems

[Mattias Gaertner]

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.

1) This is to late. A SetBounds sends a WM_SIZE message after LCL internal
resizing.


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. 


Mattias