[lazarus] ComboBox problems

[Karl Brandt]

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.

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.

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

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

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


karl