[lazarus] ComboBox problems

[Mattias Gaertner]

On Sat, 16 Aug 2003 00:36:06 -0300
Karl Brandt <pascalive at bol.com.br> wrote:

> Mattias Gaertner wrote:
> > 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:
> >>>>
> >>>>
> (...)
> >>>>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.
> > 
> 
> ok.
> >  
> > 
> >>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.
> > 
> 
> ok.
> Please remember that are just suggestions.
> 
> > 
> >>>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.
> > 
> I know.
> This has effect into interface if the bounds are set in LCL, like using
> Width, height properties, but in the cases of callback of move or resize
> then this will have no effect. See the scenario:
> We have a form with height=100 width=200
>    (In LCL height=100 width=200, In Intf height=100 width=200)
> Then the user resizes to Height=101
>    (In LCL height=100 width=200, In Intf height=101 width=200)
> Callback sends to LCL the intf values, updating them
>    (In LCL height=101 width=200, In Intf height=101 width=200)
> Now, as the bounds differ from last bounds the LCL asks the intf to
> update their values (height=101 width=200), but the intf already has
> these values,making a additional, not necessary, step.

Now I'm sure that I can't follow you.
If the win32 intf has already the same bounds, why does it not ignore the
LCL request?

BTW,
When the users resizes and the win32 intf sends the 200,101,
TWinControl.WMSize updates the FBoundsRealized variable.
So, if nothing special happens the LCL will not send the 200,101.


> It's occurring because changes came from callback or LCL share the same
> function (SetBounds).
> Maybe a way to split/diferentiate these calls could be useful.

There is already a difference: win32 intf uses WMSize as entry point to the
LCL.


> >>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?
> > 
> 
> Both comes from intf(in really win32).What occurs is that at win32 side,
>   the first value is changed to the second(determined by win32) and at
> the end the control has the correct size(we can see using GetClientRect
> or GetWindowRect).
> But, because of the order of calling the nested windowproc, as explained
> before, the LCL receives the first value by last.

Hmm. I think, I need a deeper look. Can you send me an example program
please?

 
> BTW in gtk, the message notifications are sent before calling default
> procedures ?

The gtk/X has a very different resize mechanism. For example it uses queued
resize requests. You can get the following:
gtk intf sends to gtk Width=100
gtk intf sends to gtk Width=200
gtk intf sends to gtk Width=300
gtk sends to gtk intf Width=100
gtk sends to gtk intf Width=200
gtk sends to gtk intf Width=300

 
> What is expected by LCL? LCL handles the messages before or after the
> toolkit?

The message handling and order depends too much on the interface to specify
an exact order. This implies: When the LCL sends a SetSize message to the
interface, it does neither expect, that it is applied immediately, nor that
the intf applies the coordinates. This also implies that the intf and the
LCL are not always in sync. Therefore the LCL tries to avoid asking the
interface about the current size of a window/widget. It is up to the intf to
update the LCL.


Mattias