View Issue Details

IDProjectCategoryView StatusLast Update
0029475PackagesPackagespublic2018-04-15 13:25
ReporterBBaz Assigned ToOndrej Pokorny  
PrioritynormalSeverityminorReproducibilityunable to reproduce
Status closedResolutionfixed 
Summary0029475: [AnchorDocking, 1.6RC2] Splitter top position jumps
DescriptionAfter a layout is reloaded, the first time a main form is realigned, the height of all the docked forms is indirectly modified due to a problem caused by the splitters top position.

The problem happens since the splitter position is updated using a floating point value (FPercentPosition).


description of te problem by SVN revision:

- 51097 was still OK.
- 51099 introduced a problem, a huge height jump.
- 51184 fixed the huge jump, from here remains the slight modification, as described before.



If I deactivate the splitter top position update via the FP value then the problem disapears, around line 6127 in AnchorDocking.pas:

procedure TAnchorDockSplitter.SetBoundsPercentually;
//if (FPercentPosition > 0) or SameValue(FPercentPosition, 0) then
  //NewTop := Round(FPercentPosition*Parent.ClientHeight)
  NewTop := (DockBounds.Top*Parent.ClientHeight) div;


related forum messages:

TagsNo tags attached.
Fixed in Revision
Attached Files


Ondrej Pokorny

2016-01-22 20:06

developer   ~0089213

Have you tried what I told you in the forum: "Try to call TAnchorDockMaster.ResetSplitters after your layout and form has been initialized (the docking site has the correct height at last)." ?


2016-01-22 23:56

reporter   ~0089226

Yes but I couldn't, the method you speak about is private. Then I've tried to call a similar method (same content: iterator on DockMaster components, if is splitterstuff then...) but this led to a violation access.

Finally, i've found the workaround which is to comment the code that updates splitter pos with FPercentPosition and the bug disapeared directly.


During debugging I've also noticed that

"NewTop := (DockBounds.Top*Parent.ClientHeight) div;"

is totally dead code, meaning that

"if (FPercentPosition > 0) or SameValue(FPercentPosition, 0)"

is always true.

Juha Manninen

2016-01-23 00:06

developer   ~0089228

Sounds like FPercentPosition could be uninitialized in some situations.
This is just a wild (maybe dummy) guess, I have not debugged it.


2016-01-23 00:34

reporter   ~0089234

Last edited: 2016-01-23 00:34

View 2 revisions

wait, I've changed the visibility of ResetSplitters and finally it works as a workaround too, but ONLY in the DoShow() override of my main form.

If I call DockMaster.ResetSplitter directly after loading the config from file then the bug is still there

Ondrej Pokorny

2016-01-23 01:38

developer   ~0089235

>> @BBaz: wait, I've changed the visibility of ResetSplitters

I was just about to write you that you can easily make it public :) Btw. it's public in trunk since r51338.

>> @Juha: Sounds like FPercentPosition could be uninitialized in some situations.

Yes, ResetSplitters has to be called after AutoSizing has been enabled (EnableAutoSizing) - the percentual change of AnchorDocking is bypassed when AutoSizing is disabled.


Anyway, BBaz, ResetSplitters is automatically called after the workspace has been loaded. Therefore calling it right after config loading cannot help.

You probably disable AutoSizing for your form or it's size changes between loading the config and showing the form (for whatever reason). Manually calling ResetSplitters is probably the only possible way to fix it correctly.

Even Lazarus IDE has to do it after the CoolBar+Palette height has been calculated. See r51338.

Are you happy with this workaround? Can this issue be resolved?

Ondrej Pokorny

2016-01-23 01:45

developer   ~0089236

Btw. r51338 will be merged into 1.6 ( so you'll be able to use public ResetSplitters in 1.6 final.


2016-01-23 02:50

reporter   ~0089237

No I'm not happy but it's acceptable.

In the worst case I'll put a copy of AnchorDocking in my project with the workaround I've found sooner. You can close.

Ondrej Pokorny

2016-01-23 09:53

developer   ~0089242

>> No I'm not happy.

You should be :)

FPercentPosition is quite important and solves unwanted docked windows size changes due to rounding errors in TAnchorDockSplitter.SetBoundsPercentually ("NewLeft := (DockBounds.Left*Parent.ClientWidth) div;" and "NewTop " ..."). Unfortunately it can get wrong values during the initialization when dock site size changes and it isn't recognized by AnchorDocking.

ResetSplitters is fast and doesn't affect user experience of your program in any way (no extra flickering etc.).

Ondrej Pokorny

2016-01-23 11:01

developer   ~0089248

@BBaz: Could you please try to replace this function

procedure TAnchorDockSplitter.UpdatePercentPosition;
  case ResizeAnchor of
    akTop, akBottom:
      if > 0 then
        FPercentPosition := FDockBounds.Top /
        FPercentPosition := -1;
    if > 0 then
      FPercentPosition := FDockBounds.Left /
      FPercentPosition := -1;

And omit the ResetSplitters workaround?


2016-01-23 14:44

reporter   ~0089256

No it does not fix the issue.

Anyway as said previously I'm ok to use the workaround. I understand that the component is not completly developed but globally it does what it has to.
Furthemore, if I understand well, Laz had the same problem in trunk before r51338...

Ondrej Pokorny

2016-01-23 15:00

developer   ~0089258

Last edited: 2016-01-23 15:01

View 2 revisions

>> Laz had the same problem in trunk before r51338.

No. r51338 was needed because of r51337 (because the CoolBar height is now initialized before DoShow and thus it is ignored by AnchorDocking).
r51336 works fine for Lazarus.

>> No it does not fix the issue.

Actually this is very strange. Because you say that if you use:
(A) NewLeft := (DockBounds.Left*Parent.ClientWidth) div;

it works. If this is called:
(B) NewLeft := Round(FPercentPosition*Parent.ClientWidth)

it doesn't work.

This is strage because of
FPercentPosition := DockBounds.Left /

The FPercentPosition is calculated from DockBounds and FDockParentClientSize. There shouldn't be any difference using (A) or (B). DockBounds and DockParentClientSize shouldn't be updated without FPercentPosition.

Maybe you could debug into the problem and take a look when and why (A) and (B) give different results.


2016-01-25 20:02

reporter   ~0089358

No here you quote the code for the left position.

The bug only happens for the top position. And this is even weirder. I've rewieved the code several times and it's the same for the top and the left postion, but the bug only happens for the top position.

I mean that it's not logical. The "little jump" should also happen for the left position...

Ondrej Pokorny

2016-01-25 20:11

developer   ~0089360

Last edited: 2016-01-25 20:17

View 2 revisions

>> No here you quote the code for the left position.

Come on... Of course I meant both, left and top but avoided the top-duplicate... I am still waiting on the answer why (FPercentPosition <> DockBounds.Top / in TAnchorDockSplitter.SetBoundsPercentually [I updated the coordinates now to avoid confusion].

>> I mean that it's not logical. The "little jump" should also happen for the left position...

The little jump happens 99.9% due to the main menu. Because the main menu changes the site height.


2018-04-15 13:19

reporter   ~0107793

Yes, you can close. If i load the layout in DoFirstShow then the jump disapears.


2018-04-15 13:25

reporter   ~0107795

sorry if you get notified, i didn't remember that the reporter can close

Issue History

Date Modified Username Field Change
2016-01-22 15:51 BBaz New Issue
2016-01-22 17:00 Ondrej Pokorny Assigned To => Ondrej Pokorny
2016-01-22 17:00 Ondrej Pokorny Status new => assigned
2016-01-22 20:06 Ondrej Pokorny Note Added: 0089213
2016-01-22 23:56 BBaz Note Added: 0089226
2016-01-23 00:06 Juha Manninen Note Added: 0089228
2016-01-23 00:34 BBaz Note Added: 0089234
2016-01-23 00:34 BBaz Note Edited: 0089234 View Revisions
2016-01-23 01:38 Ondrej Pokorny Note Added: 0089235
2016-01-23 01:45 Ondrej Pokorny Note Added: 0089236
2016-01-23 02:50 BBaz Note Added: 0089237
2016-01-23 09:53 Ondrej Pokorny LazTarget => -
2016-01-23 09:53 Ondrej Pokorny Note Added: 0089242
2016-01-23 09:53 Ondrej Pokorny Status assigned => resolved
2016-01-23 09:53 Ondrej Pokorny Resolution open => fixed
2016-01-23 11:01 Ondrej Pokorny Note Added: 0089248
2016-01-23 14:44 BBaz Note Added: 0089256
2016-01-23 15:00 Ondrej Pokorny Note Added: 0089258
2016-01-23 15:01 Ondrej Pokorny Note Edited: 0089258 View Revisions
2016-01-25 20:02 BBaz Note Added: 0089358
2016-01-25 20:11 Ondrej Pokorny Note Added: 0089360
2016-01-25 20:17 Ondrej Pokorny Note Edited: 0089360 View Revisions
2018-04-15 13:19 BBaz Note Added: 0107793
2018-04-15 13:25 BBaz Note Added: 0107795
2018-04-15 13:25 BBaz Status resolved => closed