Resize behavior of anchorable panels, the case when panels are not visible

[scdmitryvodich]

We have a case when document panel becomes hidden outside of the window.
Please, check the attached video for more details:
AvalonDock_fixedAnchorablePanelBehavior.zip

1. Add additional tools panel FileStats2.
2. Dock tools panel FileStats to left side and FileStats2 to the right side.
3. Start decrease width of main window.
   As result: the document panel start to decreasing, after it reach DockMinValue, the tool panel in right FileStats2 start hiding under the window border.

Is there any way if we can make behavior of docked anchorable window in same way as in VisualStudio for example (see video).
Here in first order decrease Document Panel and then start to decreasing the tool panels.

[Dirkster99]

I can confirm your video - this problem occurs consistently with all other test clients as well :-(

The only time where this seems to work as expected:

• if I arrange 2 toolwindows inside a floatingtoolwindow and change its size

Even using 2 toolwindows without a center document does not work as expected.

This one Is a tough problem to solve.

I can see the that the code LayoutGridControl.OnLayoutUpdated() is invoked when the window is resized but I am not sure, yet how this works, or what it is that does not work correctly when the window gets too small ...

[Dirkster99]

I have tested further focusing on the visual root and found that we also get correct sizing behavior if the toolwindow (LayoutAnchorable) is docked inside the LayoutPanelControl.

So, it looks like the problem is somewhere in or below the visual tree of the LayoutAnchorSideControl since that seem to behave differently compared to the LayoutPanelControl (which hosts the document root and seems to work as expected)?

[scdmitryvodich]

Unfortunately I'm not able to reproduce the correct sizing behavior. Could you please provide a demo / video / code sample?

[Dirkster99]

Yes, you are right - I should have posted more details. So, here are the test cases I was talking about:
TestCases.zip

The attached test cases

• 2FloatingTools
• 2Tools
• 2Tools_Doc

include screenshot and layouts that I produced with the MLibTest project.
To verify this, you have to remove the
anchorableToShow.CanDockAsTabbedDocument = false;

in the LayoutInitializer.cs file (see documentation here).

The tests that work for me are 2FloatingTools and 2Tools, while 2Tools_Doc works only with the lower tool window.

The first ContentPresenter below the DockingManager (in the VisualTree) is the DockingManager.LayoutRootPanel. So, it seems like the resizing works es expected (2Tools) if toolwindows (LayoutAnchorables) are arranged here without a document. And things do not work if both document and tool window are arranged in a horizontal line.

[Dirkster99]

Not sure if thats getting us anywhere but I have added an extended console dump branch to also output the ActualSize, ActualWidth via
MLibTest>Tools>Dump Console

...but to my surprise, the width data does not change, no matter how much I resize the window or its content. Also strange, the content below the AnchorablePaneGroup has a size equivalent to zero while content below DocumentPaneGroup seems to have useful values.

These actual size values are hard to find because the properties are implemented with double ILayoutPositionableElementWithActualSize.ActualWidth which makes them invisible inside the implementing class :-(

MainWindow ActualSize 08-Jun-19 13:20:02,523.2,550
RootPanel()
Panel() Horizontal ActualSize 790,494
DocumentPaneGroup(Horizontal, ActualSize 374.4,494)
DocumentPane(ActualSize 374.4,494)
Document()
AnchorablePane(ActualSize 409.6,494)
Anchorable()
Anchorable()
FloatingWindows()
FloatingAnchorableWindow()
AnchorablePaneGroup(Horizontal, ActualSize 0.4,0.4)
AnchorablePane(ActualSize 0.8,0.4)
Hidden()
Anchorable()
Anchorable()
Anchorable()

Update
I understand now why the models data always seems to be constant: It was updated via LayoutUpdated event which always seemed to produce 2 events and the second event always resulted in the original data value. So, I changed this to be triggered with the SizeChanged event and the console data makes more sense now:

Inital Values

MainWindow 08-Jun-19 17:11:34 | ActualSize 800,550
RootPanel()
Panel() Horizontal ActualSize 790,494
DocumentPaneGroup(Horizontal, ActualSize 157.2,494)
DocumentPane(ActualSize 157.2,494)
Document()
AnchorablePane(ActualSize 626.8,494)
Anchorable()
Anchorable()

Values after resizing with to be too small for tool window

MainWindow 08-Jun-19 17:12:11 | ActualSize 402.8,550
RootPanel()
Panel() Horizontal ActualSize 790,494
DocumentPaneGroup(Horizontal, ActualSize 157.2,494)
DocumentPane(ActualSize 24.8,494)
Document()
AnchorablePane(ActualSize 626.8,494)
Anchorable()
Anchorable()

[scdmitryvodich]

Thanks, I checked these cases. I see that you docked AncorablePanels into DocumentGroupPanel. In such case the LayoutAnchorablePanel will have relative size (new GridLength(1, GridUnitType.Star)) and it will have a little bit another behavior. The size of LayoutAnchorablePanel will change when changes the size of parent panel.
I'm working on implementation for resizing of LayoutAnchorablePanel if parent there is no available space. I attached test example. It works OK for simple layout structure, but still have some cases when it's working not correctly.
Cases that I know:

1. Layout have incorrect behavior if Application not have already saved config files "AvalonDock.Layout.config". So if delete it, start application and dock panels as required. LayoutAnchorablePanels will not resizing when it's needed.
2. Layout have incorrect behavior if it have complicated structure like in attached file compicated_AvalonDock_config.zip

complicated_AvalonDock_config.zip
MLib_Test.zip

[Dirkster99]

Hi, I've tested your MLib_Test.zip and it behaves a lot more like what you'd expect :-)

I have continued to invistigate this problem and saw in the last commit in my branch that the Resizing in the Measure and ArrangeMeasure override is not handled as expected since the control does not change its size even though its clearly been given less size than it wants to occupy. I guess, the cause of the problem is what you describe above about the GridUnitType parameter.

So, my idea for solving this problem was a Level-Order Visual-Tree walk that would ensure that all Children of a given Panel are minimized as required.

Then, when all children at their minimal size, it might be best to not let the user minimize the window further? Which could be implemented via SizeChanged in DockingManager class?

My problem is just that I have already spent a lot of time testing and am most likely not able to do a lot more this week :-( I also have too look deeper into the details of custom Panel control implementation since I have not done this, yet, but maybe my testing and your developments already gets us somewhere with this?

Anyway, it would be realy cool if you could commit this draft into a branch in your repository, this way, I could see how your doing the drafted solution and maybe be able to better understand the requirements for a more general solution(?).

I will stop testing or giving feedback to this since you seem to be getting very far with this already :-) cool, please let me know if there is anything I can do to help?

Thanks Dirk

[scdmitryvodich]

Hi, I've commited the changes: https://github.com/scdmitryvodich/AvalonDock/tree/AnchorablePanelSizingBehavior

It works stable, I didn't found any significant issues.
I not updated MeasureOveride or ArrangeOveride methods, just added AdjustFixedChildrenPanelSizes method which called from OnSizeChanged handles.

Best regards,
Dmitry.

[Dirkster99]

I have tested your branch https://github.com/scdmitryvodich/AvalonDock/tree/AnchorablePanelSizingBehavior and it is stable indeed :-) good work

I have tested the cases listed here.
Can you think of other workflows that might be related to this fix?

The only minor issues I found are related to the "expected visual studio" behavior which is basically that it can restore tool window sizes even after:

• exit/restart of application (save layout/restore layout)
• Auto Hide
• Hide

I had no time to analyze your solution, yet, so I don't fully understand it at the moment and will therfore no be able to make much useful suggestions other than guessing - but we can handle these minor issues
as expected behavior and fix it at some other time or try to fix it now.

What do you think about the test steps I've marked with Issue in the page linked above?

[scdmitryvodich]

I've fixed issues related to Save/Load layout config and Auto Hide. But not sure about Hide issue. Seems that it's not depends from my changes, it's also reproduced on master.
I also fixed issue with incorrect available size if one or more panel was Auto Hidden.
About test steps your asked, I note 1 error (or just missed step) in AutoHide chapter between steps 8 and 9

[Dirkster99]

1. Fixed the problem in the Wiki page and added a step for the below problem

2. Found a small crash that occurs when the MainWindow is resized such that the DockingManager's size is less than zero (the fix was easy):
   ee4c8c9

Otherwise, it appears that you fixed all issues that I previously found - awesome 🥇 👍 I am sure this will be the best AvalonDock release in a long time thanks to your support,
thank you so much for these fixes