Hi,
I am currently using the free AvalonDock component for the docking functionalities of my application, but encountered a hard to fix issue in regard to the layout save and restore functionality, so I was wondering if your component might be a suitable replacement.
In my application, I have a document area plus dockable and floatable content. Each document is of a specific type, which requires certain windows (dockable and floatable content) to be displayed near the document area. So whenever the user selects a different tab, I need to load a specific window layout.
So when loading and saving layouts, I'd like to exclude the document area from modifications. I only want to re-arrange the windows around the document area, the document area itself should keep the same tabs. AvalonDock can be used to have this behaviour (with minor modifications), but it has the issue that it generates a new "root layout object" when restoring the layout which then replaces the old object in the logical tree. This is a highly expensive operation (http://blogs.microsoft.co.il/blogs/tomershamam/archive/2009/09/11/wpf-performance-sweets-contentcontrol-content-null.aspx), since some of the documents in my application have a rather large logical tree (also including an XamGrid for example). So if I load the layout on a tab change, it can take more than a second to finish loading the layout (does not sound much, but for a simple tab change this is clearly too much).
Would your control suffer from the same issue? Loading only a part of the layout could solve the issue, as well as not replacing the logical tree.
> Why wouldn't you just change the Visibility of the panes (i.e. collapse ones that should not be displayed and make others visible)?
The user may have a custom layout here. He may not only decide which panes to display (which would be easy), but also the size, the dock location, so everything that is usually possible, like dragging contents out of the window, combining multiple windows to a single tab control or arranging windows above or next to each other. For one tab, the user might want to arrange below each other, for another tab with possibly more available tool windows, he might want to create a tab group.
Did I understand you correctly that the logical tree only changes in regard to the panes that are moved and the document area remains in place? If so, that would be fine, because the tool windows do not have a complex logical tree and can easily be moved within the logical tree.
floele said: In my application, I have a document area plus dockable and floatable content. Each document is of a specific type, which requires certain windows (dockable and floatable content) to be displayed near the document area. So whenever the user selects a different tab, I need to load a specific window layout.
Loading a layout seems like overkill for such a behavior. Why wouldn't you just change the Visibility of the panes (i.e. collapse ones that should not be displayed and make others visible)?
floele said:So when loading and saving layouts, I'd like to exclude the document area from modifications. I only want to re-arrange the windows around the document area, the document area itself should keep the same tabs.
floele said:AvalonDock can be used to have this behaviour (with minor modifications), but it has the issue that it generates a new "root layout object" when restoring the layout which then replaces the old object in the logical tree. This is a highly expensive operation (http://blogs.microsoft.co.il/blogs/tomershamam/archive/2009/09/11/wpf-performance-sweets-contentcontrol-content-null.aspx), since some of the documents in my application have a rather large logical tree (also including an XamGrid for example). So if I load the layout on a tab change, it can take more than a second to finish loading the layout (does not sound much, but for a simple tab change this is clearly too much).
floele said: Would your control suffer from the same issue? Loading only a part of the layout could solve the issue, as well as not replacing the logical tree.