[lazarus] Jumping window bug

Michal Bukovjan bukovjan at mbox.dkm.cz
Mon Mar 18 04:06:35 EST 2002

Mattias Gaertner wrote:

>On Mon, 18 Mar 2002 08:24:13 +0100
>Michal Bukovjan <bukovjan at mbox.dkm.cz> wrote:
>>This must have been my update.
>>Where did you fix it? I will look at that...
>Several places:
>- replaced the simple TWinControl.FIsResizing flag with 
>    FBoundsRealized: TRect;
>    FBoundsLockCount: integer;
>    procedure BeginUpdateBounds;
>    procedure EndUpdateBounds;
>    property BoundsLockCount: integer
>  The FBoundsRealized stores the Bounds sent from the lcl to the interface and back.
>  This way, no message is sent twice or is sent back. 
>  Also, this give the user the ability to lock the bounds, so that resizing can be 
>  programmed easily without flickering.
>- In order to distinguish what LM_Size/Move message comes from the interface and what is 
>  performed by the lcl/application, I used the flag in the messages and added WMSize 
>  and WMMove overrides to TWinControl. 
>- Also prevented TControl.ChangedBounds to send size/move messages during loading.
>     To unsubscribe: mail lazarus-request at miraclec.com with
>                "unsubscribe" as the Subject
>    archives at http://www.miraclec.com/list_archives/lazarus
This seems like a good fix (better than I could potentially come up 
with). It could also fix the problem that you cannot resize a form by 
changing its Width in Object Inspector, because for some reason, GTK 
fires resize request with original coords first and only after that a 
second request with new ones. The first request nullifies the effect of 
changing the Width property, effectively setting it back. (This also 
occured before my changes :-)

Maybe couple of things :

- we could move the WMSize / WMMove message back to TWinControl 
altogether (from TControl). It was originally there.
- I was thinking about removing WMWindowPosChanged message altogether. 
It is provided because of Windows compatibility, and duplicates WMSize / 
- In addition to BoundsChanged virtual procedure, adding a SizeChanged 
and PosChanged virtual methods for notifications. Thus we could remove 
the WMSize / WMMove entirely and the code would get much more 
straightforward right away (and portable). Sure, it would break some 
compatibility with existing Win32 code, but I noticed that Inprise did 
the same with CLX (no WM* messages anymore) and the compatibility fix 
would be to inherit from these new methods instead of messages. The WM* 
message handling then would move to Win32 interface object, where it 
actually belongs.

Did you notice that although WMSize is declared as protected, TSynEdit 
redeclares it as private, calls inherited, and it *STILL* works? Weird :-)

Please comment.


More information about the Lazarus mailing list