[lazarus] Jumping window bug

[Mattias Gaertner]

On Mon, 18 Mar 2002 10:11:42 +0100
Michal Bukovjan <bukovjan at mbox.dkm.cz> wrote:

> 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 :-)

Even worse:
The gtk queues size messages and it sends size steps messages.
For example: doing 2 SetBounds, results in:
  1. lcl sets bounds and sends mesg to gtk
  2. lcl sets bounds and sends mesg to gtk
  3. gtk sends mesg back for first coord. -> lcl resizes to old
  4. gtk sends mesg back for second coord. -> lcl resizes to new

The user can not see this internal flickering. That's why I wrote, that the bugfix is incomplete. see devel list.


> Maybe couple of things :
> 
> - we could move the WMSize / WMMove message back to TWinControl 
> altogether (from TControl). It was originally there.

I vote for that.


> - I was thinking about removing WMWindowPosChanged message altogether. 
> It is provided because of Windows compatibility, and duplicates WMSize / 
> WMMove.
> - 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.

I never liked the WM* messages. But removing them, would break compatibility with almost all delphi components. How should the new methods look like?


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

Normal object pascal behaviour. IMO it's very useful.


Mattias