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.

Mattias

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

Handling of protected members is not always correct in the 1.0.x branch of the compiler. The 1.1 development compiler is more compatible with delphi.

Hi all,

Probably some people noticed, that one of the updates on wednesday has added a real nasty bug: messages and completion boxes in the IDE jumped around. Of course this was not a bug in the IDE, but the IDE became unusable on some systems and pretty annoying on the others.

I found out the reason for the bug: LCL and gtk were not in sync about the window bounds and there were a lot of rebouncing size+move messages between lcl and gtk. I reduced this rebouncing to a minimum and this solved the problem at least for gnome+sawfish. :) But: This is not a complete solution. :(

Hopefully this will also solve the bug for other systems as well.

Minor updates:
- improved property completion:

    if read specifier is variable and write specifier is method then
      'Variable:=AValue;' will be added to method body

- improved method completion:
if method has 'override' specifier, then 'inherited MethodName(params);' will be added to method body

Mattias

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

Looks like it works now :)

Jens

Hi all, Probably some people noticed, that one of the updates on wednesday has added a real nasty bug: messages and completion boxes in the IDE jumped around. Of course this was not a bug in the IDE, but the IDE became unusable on some systems and pretty annoying on the others.

I noticed that, too!

My windows are moving from gosthand out of the screen after resizing. It looked very funny.

Jens

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

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

Please comment.

Michal

Funny? Then it has at least one good side.

Did the bugfix worked for you too, or are they still moving?

Mattias

This must have been my update.
Where did you fix it? I will look at that...

Michal