This project is read-only.

Parent of container is lost

Jun 17, 2010 at 12:20 PM
Edited Jun 17, 2010 at 12:20 PM

When I remove all the children in a dockable pane, the dockable pane disconnects from the parent. However, now I want to drop a new dockable content into the pane, but the parents are lost. Is there any way to restore the last position of a dockable pane without restorelayout (because that will do more than just re-positioning the dockable pane alone).

I am using 1.3 (latest source).

Thanks in advance!

Jun 17, 2010 at 1:47 PM

When further debugging, it seems that this happens due to the fact that ResizingPanels are merged when they contain a single item. Is this behavior configurable?

Jun 17, 2010 at 2:28 PM

For now, I have removed the calls from ResizingPanel and DockablePane that they remove themselves from their parent when they are empty. That seems to do the trick.

Jun 18, 2010 at 1:17 PM

Why don't you add first your new content and then remove other contents?

AvalonDock always remove pane that are empty and are not referenced by flyout contents or hidden contents. In anycase you could hide contents instead of remove them from parent pane container.


Jun 19, 2010 at 11:03 AM

That is not really possible. I will try to explain how we use AvalonDock.

We have a base application that in itself does not do anything. The base app can load plug-ins. Each plug-in has a public propery with all the dockable contents that should be visible. However, the dockable contents also require a specific context. Thus, sometimes, you don't want to show anything, sometimes you want to show it all.

Therefore, I have created a basic layout (document in the center, dan lefttop, leftbottom, bottom, righttop, rightbottom). Each dockable content specifies the context and the location it should be displayed in. Then, on every context change, the base app loops all the add-ins and the dockable contents to see whether they should be visible or not. All the locations have a dummy dockable content (empty one) so all the required ResizingPanes are created. Then, the right pane is determined by the location specified by the dockable content info in the add-in and the dummy parent pane.

For performance reasons and the initialization of the data in the right context, we cannot simply hide the existing dockable contents. We want to re-create them over and over again (sounds stupid, but for us, it's the best way, we don't want to keep unused dockable contents into memory).

I hope this makes it a little bit more clear how we use it, and why we don't want AvalonDock to merge ResizingPanes automatically (because then, we can't specify leftbottom, only left, which does not give the right result).

Jun 19, 2010 at 1:57 PM


In your case, I would make heavy use of layout persistence of AvalonDock. Instead of reference all needed dockable contents, your addins should only mantain a layout in the form of a XML document (maybe you can save layout within a addin configuration file). When the addin is loaded, the main application load the xaml layout for the addin. XAML layout will contain names of all the contents required by the addin. Next step would be the handling of method DockingManager.DeserializationCallback in order to return the actual content for each name found in the addin layout.

Hope it makes sense,


Jun 19, 2010 at 8:48 PM

The problem is that the add-ins can contain several dockable contents, which should not be visible at the same time. Also, an add-in might have 3 dockable contents in the lower-left, and 1 in the right-top. If you would do this via the default persistence, it would end up in a mess.

What we did until now was force a RestoreLayout every time and then build up the whole workspace again. However, you can imagine the performance issues we encountered when there were more and more add-ins and context switches. What we now do on a context switch is the following:

1) Determine which dockable contents should be visible and add them to the "todo" list

2) Loop all existing dockable contents. If the dockable content is already visible, remove the dockable content from the "todo" list, close all dockable contents that are not in the "todo" list

3) Now we have a clear set of new dockable contents in the new context, add them

This saves a lot of recreating the workspace, and performance very, very well. I have changed some code in the AvalonDock library in the past (I noticed that you have adapted most of them (my former name was Tischnoetentoet)). If you want, I can create a property "MergePanelsWhenContainingSingleChild", and then skip the merge functionality. It's not that much work, and I think that for some people, it might be a good feature (I read more posts that require the same behavior).

Thanks for all your fast replies and the community effort you put into this project.