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.
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.
> 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: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.
floele said: 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.
Just to follow up on this: Works actually quite good. If you exclude the documents from saving/loading layouts, only the content around the document area is rearranged, without the performance hit I worried about. I'm glad that it worked out, thanks for your help :)
Only culprit I found is that you need to remove the "selectedIndex" attribute from the document container in the layout XML when loading layouts, otherwise it may happen that switching tabs will not work properly (it apparently conflicts with loading layouts at the time another document is selected). Also, there will be an exception if you drag documents out of the document area, and you use the (default) "toolbox" style for flyout windows. I submitted support cases for these issues if you are interested in fixing them, but it works fine for me as is.
OK, thanks, I will check how it works out for me.
floele said:The layout would be shared among document types.
floele said: I would aonly allow documents in the document area, if that is technically possible. Panes would have to go top, left, right or bottom to the document area.
I would aonly allow documents in the document area, if that is technically possible. Panes would have to go top, left, right or bottom to the document area.
The ContentPane has a number of "Allow" properties so presumably you would set the AllowInDocumentHost on the supporting panes to false to prevent them from being allowed into the document content host and you would probably set the AllowDocking for the documents to false (so they remain within the document content host.
Andrew Smith said: So the layout for each instance of a document is unique and not shared across all document instances of that same document type or that the toolwindows may be shared across document types?
So the layout for each instance of a document is unique and not shared across all document instances of that same document type or that the toolwindows may be shared across document types?
The layout would be shared among document types.
Andrew Smith said:However if you allow other panes to be dragged into the DocumentContentHost area then the layout will likely reparent one or more documents because there would be information about the document elements in the layout in order to preserve the position of the panes relative to the other panes it was dragged sibling to.