[lazarus] Jumping window bug
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...
>- 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
Did you notice that although WMSize is declared as protected, TSynEdit
redeclares it as private, calls inherited, and it *STILL* works? Weird :-)
More information about the Lazarus