[lazarus] ComboBox problems

[Karl Brandt]

Mattias Gaertner wrote:


(...)
> 
> 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?
> 

Good question.

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

ok

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

(...)

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


I'm sending  a testprogram and a patch to win32 that do some trace 
information. Also, add the following to Wincontrol.WMSize
   If FCompStyle = csComboBox then
     begin
     writeln('LCL is receiving height: ',Message.Height);
     writeln('LCL current height: ',Height);
     end;

The trace will look like this:

Entering DefWindowProc with height: 21
Exiting DefWindowProc with height: 21
LCL is receiving height: 21
LCL current height: 20
LCL is receiving height: 21
LCL current height: 21
Height is set to 127 for update DropDown list size limit
Entering DefWindowProc with height: 127
  -> Here DefWindowProc changes height to 21 and calls WindowProc with 
updated value
Entering DefWindowProc with height: 21 ; Here we are in the nested 
WindowProc
Exiting DefWindowProc with height: 21 ;The nested windowproc notify LCL
LCL is receiving height: 21
LCL current height: 21
Exiting DefWindowProc with height: 127 ;back to first Windowproc
LCL is receiving height: 127
LCL current height: 21
LCL is receiving height: 127  ;??? From where this call came?
LCL current height: 127      ;LM_SIZE is notified in another place?

Here we try to set Height to 12345
Same as above

Entering DefWindowProc with height: 12345
Entering DefWindowProc with height: 21
Exiting DefWindowProc with height: 21
LCL is receiving height: 21
LCL current height: 127
LCL is receiving height: 21
LCL current height: 21
Exiting DefWindowProc with height: 12345
LCL is receiving height: 12345
LCL current height: 21
LCL is receiving height: 12345  ???
LCL current height: 12345    ???

If DefWindowProc is called after notifying the LCL,
the LCL will receive the correct value, but other things will not work.

I already have an idea of how to fix this inside intf, it's a question 
of doing it and testing it.


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


karl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: zip00030.zip
Type: application/octet-stream
Size: 935 bytes
Desc: "testcombo.zip"
Url : http://localhost/pipermail/lazarus/attachments/20030816/a1aa06ea/zip00030.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zip00029.zip
Type: application/octet-stream
Size: 1381 bytes
Desc: "test.zip"
Url : http://localhost/pipermail/lazarus/attachments/20030816/a1aa06ea/zip00029.obj