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

[balazsszekely]

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?

If ANewHeigth <= 0 then CalcMainHeigth is called, which recalculate/sets the height of the MainIDEBar, which will trigger the TMainIDEBar.Resizing event, which calls DoSetMainIDEHeight again---> infinit loop.
The line

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

1. if ANewHeight < 25 then ANewHeight := 25

will break this.

[Deepaak]

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?

Anything that makes the bug go off, whether it is a temporary solution it is welcome, because it is really annoying each time ide is restarted.

[JuhaManninen]

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?

If ANewHeigth <= 0 then CalcMainHeigth is called, which recalculate/sets the height of the MainIDEBar, which will trigger the TMainIDEBar.Resizing event, which calls DoSetMainIDEHeight again---> infinit loop.
The line

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

1. if ANewHeight < 25 then ANewHeight := 25

will break this.

My analysis was that the new "fixed" method is functionally a no-operation. It does not do anything. Am I missing something? Are you saying it actually does something.

The value returned from CalcMainIDEHeight is used to set actual window height but only when the AutoAdjustIDEHeight option is set.
In my tests commenting out the calls to IDEDockMaster.AdjustMainIDEWindowHeight in DoSetMainIDEHeight has the same effect as turning off the AutoAdjustIDEHeight option.
Thus it can be used as a workaround. Am I right or wrong?

[JuhaManninen]

Anything that makes the bug go off, whether it is a temporary solution it is welcome, because it is really annoying each time ide is restarted.

C'mon ... you can make temporary solutions easily to your local copy.
In my earlier posts I asked help from people who can reproduce the issue. So, could you please test, debug and experiment with the code so we can fix it properly.

[balazsszekely]

In my tests commenting out the calls to IDEDockMaster.AdjustMainIDEWindowHeight in DoSetMainIDEHeight has the same effect as turning off the AutoAdjustIDEHeight option.

Yes, it would have the same effect, but then the MainIDEBar has to be resized manually. For example, if you add a new band to IDECoolbar, the height changes and AutoAdjustIDEHeigth kicks in. This is why it was implemented in the first place.

[Akira1364]

Alright, I've been playing around with this a bunch more and I believe I've found a "real" solution. By which I mean I'm pretty confident I've fixed the root bug in TMainIDEBar.CalcMainIDEHeight that in turn was causing the problem with TMainIDEBar.DoSetMainIDEHeight.

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

1. function TMainIDEBar.CalcMainIDEHeight: Integer;
2. var
3.   NewHeight: Integer;
4.   I: Integer;
5.   ComponentScrollBox: TScrollBox;
6. begin
7.   Result := 0;
8.   if not (Assigned(EnvironmentOptions) and Assigned(CoolBar) and Assigned(ComponentPageControl)) then
9.     Exit;
10.  
11.   if EnvironmentOptions.Desktop.IDECoolBarOptions.Visible then
12.   begin
13.     for I := 0 to CoolBar.Bands.Count-1 do
14.     begin
15.       NewHeight := CoolBar.Bands[I].Top + CoolBar.Bands[I].Height;
16.       Result := Max(Result, NewHeight);
17.     end;
18.   end;
19.  
20.   if EnvironmentOptions.Desktop.ComponentPaletteOptions.Visible
21.   and Assigned(ComponentPageControl.ActivePage) then
22.   begin
23.     ComponentScrollBox := nil;
24.     for I := 0 to ComponentPageControl.ActivePage.ControlCount-1 do
25.     if (ComponentPageControl.ActivePage.Controls[I] is TScrollBox) then
26.     begin
27.       ComponentScrollBox := TScrollBox(ComponentPageControl.ActivePage.Controls[I]);
28.       Break;
29.     end;
30.  
31.     if Assigned(ComponentScrollBox) then
32.     for I := 0 to ComponentScrollBox.ControlCount-1 do
33.     begin
34.       NewHeight := 55;
35.       Result := Max(Result, NewHeight);
36.       if not EnvironmentOptions.Desktop.AutoAdjustIDEHeightFullCompPal then
37.         Break;
38.     end;
39.   end;
40. end;

The relevant change starts at line 34 of the code snippet. The bug is avoided by setting that particular instance of NewHeight directly to 55 (which seems to be the "ideal" value for it in the first place) instead of pointlessly calculating it based on the palette button height and page control height. Again, this solution is a replacement for the one I posted earlier, not an addition. TMainIDEBar.DoSetMainIDEHeight does not need to be altered in the manner I indicated... only TMainIDEBar.CalcMainIDEHeight, as shown above.

[JuhaManninen]

Alright, I've been playing around with this a bunch more and I believe I've found a "real" solution. By which I mean I'm pretty confident I've fixed the root bug in TMainIDEBar.CalcMainIDEHeight that in turn was causing the problem with TMainIDEBar.DoSetMainIDEHeight.

No, I am sorry to say but you did not fix the root bug. What more, your solution breaks the palette height calculation especially when the buttons are split into 2 rows.

The relevant change starts at line 34 of the code snippet. The bug is avoided by setting that particular instance of NewHeight directly to 55 (which seems to be the "ideal" value for it in the first place) instead of pointlessly calculating it based on the palette button height and page control height. Again, this solution is a replacement for the one I posted earlier, not an addition. TMainIDEBar.DoSetMainIDEHeight does not need to be altered in the manner I indicated... only TMainIDEBar.CalcMainIDEHeight, as shown above.

The main window + palette are now too low always with my widgetset and 2 rows of buttons are not taken into account for obvious reasons.
The code is also frankly speaking quite stupid because the same value 55 is used inside a loop again and again. You could have dumped the whole loop.

Question:
Does unchecking the "Show complete component palette" option solve the problem as a workaround?
If it doesn't, then unchecking the "Automatically adjust IDE main window height" option certainly does. (?)
If there is such an easy workaround, what is all the fuzz about? Or, did nobody realize there is such a workaround?

I wonder why I didn't get answers for my questions earlier. For example the replacement DoSetMainIDEHeight method looked like a no-operation to me. Is it really so or did I miss some important detail?
It was considered a valid temporary fix by many people (including GetMem who surely is a good programmer) although it completely broke the height calculation also for non-docked IDE.

The root problem is not CalcMainIDEHeight. It calculates the height correctly.
The root problem may be how DoSetMainIDEHeight is called. It is called from many places, including the TMainIDEBar.Resizing method which creates the loop.
You should try to reduce the calls by using flag variables.
There may be a LCL layout bug involved, too. If you look at this issue:
  http://bugs.freepascal.org/view.php?id=28096
it makes no sense. The bounds in the error message are identical. It never should give an error.
Why it happens only at maximized state? Maybe LCL layout has trouble with that.

Anyway, do some experiments please. I still believe it can be fixed.

[balazsszekely]

@Juha

1. The error is very sporadic, I cannot reproduce consistently so it's hard to do some real time testing
2. Apparently everybody is ignoring the fact that the error message contains a very important information, namely the infinite loop is caused by a TScrollBox (see screenshot). The only component on the main IDE bar which contain a TScrollBox is the component palette. So yes, unchecking "Show complete component palette" almost certainly solves the problem, but then a cool feature is lost. This is why I personally don't like the unchecking solution, it can be a temporary fix though.
3. I believe the root cause of the problem is this(or something similar): http://bugs.freepascal.org/view.php?id=29194 . I will try to reproduce it whit a simple project.

[balazsszekely]

Hi guys,

@Ondrej fixed the bug in r51346. Now everybody who using Anchordocking please test it, so it can be merged to 1.6. Thank you!

regards,
GetMem

[JuhaManninen]

@Ondrej fixed the bug in r51346. Now everybody who using Anchordocking please test it, so it can be merged to 1.6. Thank you!

Actually it is r51337, r51338 and r51346.
I would not have found it. I was also convinced the problem was TScrollBox + LCL layout engine.
We have reports about TScrollBox and TScrollBar, so they may have other bugs lurking.

I would like to ask anybody to test with trunk for a while. If no regressions are found then we can merge the fix to 1.6.

[guest58172]

Does this bug only happen in the design package (so Laz only) or more globally in AnchorDocking ?

I encounter a bug since 1.6-RC2, e.g after reloading a xml config, the height of the docked form drops a bit the first time something is realigned (e.g move a splitter.)

I've seen two commits made two weeks ago that are maybe the cause of this regression.

http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/components/anchordocking/anchordocking.pas?root=lazarus&r1=50833&r2=51097&sortby=file

http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/components/anchordocking/anchordocking.pas?root=lazarus&r1=51097&r2=51099&sortby=file

Unfortuantely it's impossible to reproduce it in a simple example.

[balazsszekely]

@BBasile
I encounter a bug since 1.6-RC2, e.g after reloading a xml config, the height of the docked form drops a bit the first time something is realigned (e.g move a splitter.)
I've seen two commits by ondrej made two weeks ago that are maybe the cause of this regression.

Please report it on the bugtracker, otherwise there is only a small chance to be fixed.

[JuhaManninen]

Unfortuantely it's impossible to reproduce it in a simple example.

That can mean the problem is in your code. A simple example to reproduce is needed.

[Akira1364]

Just updated my sources to SVN revision 51358, rebuilt the IDE, and I can confirm that the bug is completely gone (with the proper resizing behaviour intact, which as JuhaManninen pointed out my previous solution broke.) Much thanks to Ondrej! I'm glad that I was able to get people talking about this issue, at least... it seems to have "fast-tracked" us to a real solution that I imagine would have taken much longer to arrive at otherwise. I sort of wish I had posted this thread a few years ago, haha.

[balazsszekely]

Yes it's gone! I cannot reproduce it either. However this bug revived several times in the past, I hope this time is dead for good.