[lazarus] ComboBox problems

Mattias Gaertner 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 
> >>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.


> > 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
sent bounds.

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


Mattias






More information about the Lazarus mailing list