View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0029475||Packages||Packages||public||2016-01-22 15:51||2018-04-15 13:25|
|Reporter||BBaz||Assigned To||Ondrej Pokorny|
|Priority||normal||Severity||minor||Reproducibility||unable to reproduce|
|Summary||0029475: [AnchorDocking, 1.6RC2] Splitter top position jumps|
|Description||After 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:
//if (FPercentPosition > 0) or SameValue(FPercentPosition, 0) then
//NewTop := Round(FPercentPosition*Parent.ClientHeight)
NewTop := (DockBounds.Top*Parent.ClientHeight) div DockParentClientSize.cy;
related forum messages:
|Tags||No tags attached.|
|Fixed in Revision|
||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)." ?|
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 DockParentClientSize.cy;"
is totally dead code, meaning that
"if (FPercentPosition > 0) or SameValue(FPercentPosition, 0)"
is always true.
Sounds like FPercentPosition could be uninitialized in some situations.
This is just a wild (maybe dummy) guess, I have not debugged it.
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
>> @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?
||Btw. r51338 will be merged into 1.6 (http://wiki.freepascal.org/Lazarus_1.6_fixes_branch) so you'll be able to use public ResetSplitters in 1.6 final.|
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.
>> 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 DockParentClientSize.cx;" 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.).
@BBaz: Could you please try to replace this function
procedure TAnchorDockSplitter.UpdatePercentPosition; begin case ResizeAnchor of akTop, akBottom: if FDockParentClientSize.cy > 0 then FPercentPosition := FDockBounds.Top / FDockParentClientSize.cy else FPercentPosition := -1; else if FDockParentClientSize.cx > 0 then FPercentPosition := FDockBounds.Left / FDockParentClientSize.cx else FPercentPosition := -1; end; end;
And omit the ResetSplitters workaround?
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...
>> 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 DockParentClientSize.cx;
it works. If this is called:
(B) NewLeft := Round(FPercentPosition*Parent.ClientWidth)
it doesn't work.
This is strage because of
FPercentPosition := DockBounds.Left / FDockParentClientSize.cx
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.
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...
>> 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 / DockParentClientSize.cy) 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.
||Yes, you can close. If i load the layout in DoFirstShow then the jump disapears.|
||sorry if you get notified, i didn't remember that the reporter can close|
|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|