Does anyone know how to fix the WMSize loop bug in "AnchorDocking Design"?

[Akira1364]

It's rather annoying having to click through ten or so error message boxes every time I open Lazarus...

[balazsszekely]

1. Hide the component palette(Tools-->Options-->Component Palette-->Uncheck Palette is visible
2. Use the Component Window instead(Ctr+Alt+P  or  View-->Components). You can dock it if you like.

[JuhaManninen]

Is it related to this issue?
 http://bugs.freepascal.org/view.php?id=28096
I just added a comment there. Most people including me don't get any errors. I have the Component Palette visible.
How to reproduce? Does it happen with a clean configuration? Does it happen only on Windows?
Clear steps to reproduce please.

[balazsszekely]

@JuhaManninen
Most people including me don't get any errors.

Because this issue is not present under GTK2, but it did happened to you too on QT, in fact you where the first one who noticed. 
Please read this: http://forum.lazarus.freepascal.org/index.php/topic,30663.msg196033.html#msg196033

[JuhaManninen]

Because this issue is not present under GTK2, but it did happened to you too on QT, in fact you where the first one who noticed. 
Please read this: http://forum.lazarus.freepascal.org/index.php/topic,30663.msg196033.html#msg196033

I don't get such errors with any widgetset. I though the bugs were fixed already. Maybe not. Are you sure you use the latest RC2 version (or trunk)?
Akira1364, you did not mention your Lazarus version nor your widgetset.

[Edit] Actually I get some errors with the Windows version after playing with docking for a while.

[Akira1364]

I'm on 64-Bit Windows (so the "win32" widgetset), and I always use either the latest official release of Lazarus or a build of the latest trunk. Specifically, the error seems to happen when you re-open the IDE after closing it while the window is fully maximized (which is essentially always for me, and I imagine many other people.) It's been a consistently present bug in every possible iteration of the AnchorDocking Design package and the IDE itself going back presumably forever (as I don't remember it ever NOT being there.)

[Edit]: Also, yes, it appears to be the same bug that is described in the bugtracker page that was linked to. It's worth noting as well that it does not exist/occur in CodeTyphon's IDE GlassDocking package, which is clearly based directly on AnchorDocking Design...

[balazsszekely]

@Juha
Please take a look at this: http://bugs.freepascal.org/view.php?id=28063

[JuhaManninen]

It's worth noting as well that it does not exist/occur in CodeTyphon's IDE GlassDocking package, which is clearly based directly on AnchorDocking Design...

GlassDocking is apparently doing something better. I once went through its code to find differences for AnchorDocking, using an advanced diff tool. It was quite a laborious task because they had run the code through JCF or other similar code formatter.
The only relevant difference was an extra dock-master window CodeTyphon had added. I did not fully understand it purpose but very likely it fixes this bug.

Somebody should analyse the code and maybe port their solution to AnchorDocking. Hey, this is open source! Let's take all the fun out of it.
My own motivation, time and energy are not enough for an AnchorDocking task. I have a long list of other tasks.
Now the situation of AnchorDocking is strange. Many people apparently want to use it but very few want to contribute for it. Why is that?

Please take a look at this: http://bugs.freepascal.org/view.php?id=28063

@GetMem, that was a different issue at least when I reported it, but maybe they are caused by the same fundamental reason. Don't know.

[Akira1364]

Ok, I've figured out exactly how CodeTyphon fixed this bug. It seems that what they're doing differently that corrects the error isn't in the GlassDocking code, but in the code for the IDE itself. More specifically, in the file mainbar.pas they've changed the procedure "TMainIDEBar.DoSetMainIDEHeight" to consist of a single line:

Code: Pascal  [Select][+][-]

1. procedure TMainIDEBar.DoSetMainIDEHeight(const AIDEIsMaximized: Boolean; ANewHeight: Integer);
2. begin
3.   if ANewHeight < 25 then ANewHeight := 25;
4. end;

I copy and pasted this implementation of the procedure into the Lazarus version of mainbar.pas, rebuilt the IDE, and the bug seems to be completely gone. I even spent about half an hour going out of my way to set up weird docking layouts and then closing and re-opening the IDE, and it has never recurred.

[taazz]

Ok, I've figured out exactly how CodeTyphon fixed this bug. It seems that what they're doing differently that corrects the error isn't in the GlassDocking code, but in the code for the IDE itself. More specifically, in the file mainbar.pas they've changed the procedure "TMainIDEBar.DoSetMainIDEHeight" to consist of a single line:

Code: Pascal  [Select][+][-]

1. procedure TMainIDEBar.DoSetMainIDEHeight(const AIDEIsMaximized: Boolean; ANewHeight: Integer);
2. begin
3.   if ANewHeight < 25 then ANewHeight := 25;
4. end;

I copy and pasted this implementation of the procedure into the Lazarus version of mainbar.pas, rebuilt the IDE, and the bug seems to be completely gone. I even spent about half an hour going out of my way to set up weird docking layouts and then closing and re-opening the IDE, and it has never recurred.

which is not a solution just a cover up of the real problem. It is though a temporary solution to the problem until a someone rewrites the mess of resize on the main controls.

[Akira1364]

That might be true, but as it has no negative repercussions on any aspect of the IDE's functionality, and fixes a problem that's been a nuisance for years, it's good enough for me!

[taazz]

That might be true, but as it has no negative repercussions on any aspect of the IDE's functionality, and fixes a problem that's been a nuisance for years, it's good enough for me!

for me is uninteresting I do not use the component palette any more nor the docking interface at all but the underline problem is something that I see very often in my components and it is bad enough to have me thinking of forking lcl and disabling it all together. They have coded it in a way that it can not be disabled in any components and I do not think a patch that disables the inferno loop is going to be accepted by the team.

[balazsszekely]

@Akira1364
Ok, I've figured out exactly how CodeTyphon fixed this bug. It seems that what they're doing differently that corrects the error isn't in the GlassDocking code, but in the code for the IDE itself. More specifically, in the file mainbar.pas they've changed the procedure "TMainIDEBar.DoSetMainIDEHeight" to consist of a single line

That's great! I was aware that CalcMainIDEHeight causing the trouble(see my post here: http://forum.lazarus.freepascal.org/index.php/topic,30663.msg196033.html#msg196033). Please attach a patch to the following bug report: http://bugs.freepascal.org/view.php?id=28096 , so finally we can get rid of this ugly bug.
Ps: This is why I don't consider CT as evil as other people do, although I have to admit they should leave the license info intact.

@taazz
for me is uninteresting I do not use the component palette any more nor the docking interface at all but the underline problem is something that I see very often in my components and it is bad enough to have me thinking of forking lcl and disabling it all together. They have coded it in a way that it can not be disabled in any components and I do not think a patch that disables the inferno loop is going to be accepted by the team.

This particular issue is caused by a bug in TScrollBox(I will search it in the bug tracker) and I'm almost 100% convinced that @Akira1364's patch will be accepted as a temporary solution.

[Deepaak]

@Akira1364
solution is working perfectly. no more dialog mess. I too feel this solution must be accepted as a temporary solution, till something perfect comes out to save us.

[JuhaManninen]

Ok, I've figured out exactly how CodeTyphon fixed this bug. It seems that what they're doing differently that corrects the error isn't in the GlassDocking code, but in the code for the IDE itself. More specifically, in the file mainbar.pas they've changed the procedure "TMainIDEBar.DoSetMainIDEHeight" to consist of a single line:

Code: Pascal  [Select][+][-]

1. procedure TMainIDEBar.DoSetMainIDEHeight(const AIDEIsMaximized: Boolean; ANewHeight: Integer);
2. begin
3.   if ANewHeight < 25 then ANewHeight := 25;
4. end;

I copy and pasted this implementation of the procedure into the Lazarus version of mainbar.pas, rebuilt the IDE, and the bug seems to be completely gone. I even spent about half an hour going out of my way to set up weird docking layouts and then closing and re-opening the IDE, and it has never recurred.

The method makes no sense. It is essentially a no-op as ANewHeight is not a var parameter. Why not make an empty method instead?

I wanted to make tests with the code but for some reason I cannot reproduce the bug now. I am testing under Wine, maybe that has an effect.
So, I must analyse the code instead ...
The essential part of method  TMainIDEBar.DoSetMainIDEHeight is this:

Code: Pascal  [Select][+][-]

1.   if Assigned(IDEDockMaster) then
2.   begin
3.     if EnvironmentOptions.Desktop.AutoAdjustIDEHeight then
4.       IDEDockMaster.AdjustMainIDEWindowHeight(Self, True, ANewHeight)
5.     else
6.       IDEDockMaster.AdjustMainIDEWindowHeight(Self, False, 0);
7.   end else
8.   ...

The "else" part is for non-docked IDE and does not matter here.
If you turn off the "Automatically adjust IDE main window height" option, does it solve the problem?
If it does then it can be used as a workaround instead of changing code.
If not, then the problem must be in TIDEAnchorDockMaster.AdjustMainIDEWindowHeight.
I believe the exact error can be spotted by eliminating pieces of code and debugging.
I leave it to somebody who actually can reproduce the error. Anyway, looks like we a near solving this properly. Cool!

[Edit]
If the no-op (empty) DoSetMainIDEHeight solved the problem for a docked IDE, then the calls to IDEDockMaster.AdjustMainIDEWindowHeight can be removed and TIDEAnchorDockMaster.AdjustMainIDEWindowHeight, too, because it is not called from anywhere else.
Is this correct?