DockSite serialization problem

Sorry but that hierarchy of controls is not supported. Check out the documentation's "Control Hierarchy" topic as that tells you what can be in what.

ToolWindowContainers can only be under a DockSite or SplitContainer. Thus your second code listing is not valid.

Maybe if you describe the layout you are trying to achieve, I can suggest the control hierarchy you'd want to use.

Ok, sorry about that. I have fixed it now. I do have two more questions though.

1) When is a good time to load/save layout? I want to automatically save layout on app exit and load it on app start. I presume Loaded event on DockSite is good for layout loading, is it not? Your sample only shows explicit layout loading/saving.

2) What is the proper/documented way to achieve contextual tool windows? I would like to dynamically show/hide various tool windows depending on the type of active document (like VS shows/hides e.g. palette tool window when editing images). Is this possible? I noticed DockingWindow.IsOpen property is read only. I thought binding that one to IsSelected of a document window would be a perfectly easy solution. Instead we have Open/Close methods. I tried using those and even though Close() works, Open() always opens the tool window in a docked position regardless of whether it was hidden or docked on closing. Perhaps this is not the right way to do it...

Any suggestions are welcome! Thanks!

1) DockSite.Loaded is a good place to do layout load. Window.Closing event is good for layout save.

2) Perhaps by using the DockSite.WindowActivated and WindowDeactivated events, and examining the source window in the event args you could determine when to show/hide your contextual tool windows.

The Open() method should reopen a tool window where it last was, however it needs to have been previously been open to restore it to that same spot.

I have tried your suggestion 1) and it appears to work ok. Thanks!

As for 2) I have had limited success and several problems. I have created a sample app with a tabbed MDI interface, two documents and a tool window (initially hidden). I have observed the following:

A) Upon app startup, no WindowActivated is fired initially (could be by design but it wouldn't hurt to have this).
B) Upon the first document switch (from doc1 to doc2) WindowActivated is fired for the doc2 but there is no WindowDeactivated for doc1. Further document switches correctly fire pairs of activated/deactivated events.
C) If one attempts to show/hide contextual tool window in WindowActivated/WindowDeactivated depending on the window in the event args does not work. Calling Close on ToolWindow in WindowDeactivated seems to reactivate the very window that was deactivated. After it was once closed, the ToolWindow is never reopened and after a few document switches a stack overflow exception occurs.

I have sent an app that reproduces these issues to your support email. Thanks!

Ok, after a couple of hours I have managed this to work almost as expected. I suppose the scenario I am now trying is not directly supported. If it were, it would probably have made it into your sample application. But there are ways to make it work.

After many trials and errors I abandoned WindowActivated and friends because this event is fired whenever a window is actually activated (including tool windows) and I was seeking "a document window selection change". I am now relying solely on DockSite.LastActiveDocument. As this is a DependencyProperty I get notifications about a change in the currently selected document. Works almost perfectly for now.

The only remaining issue is something I already mentioned. Closing and reopening an auto-hidden ToolWindow opens it in a docked mode. Is this by design? If so, how can I reopen the window in its last state?

Thanks!

We have an item on the TODO list to add reopening into auto-hide state. I'll try and bump the priority up on that. We are close to starting a large round of updates for the Docking product so hopefully we can get this in soon for you.

Thanks for the info! Is there a rough ETA for this update?

No not yet. We'll probably start digging into Docking enhancements after the next maintenance release.

We've added the DockSite.CanToolWindowsRestoreToAutoHideState property, which will restore ToolWindows to the auto-hide state if they were in that state when closed. By default, this is disabled so that it mimics how Visual Studio works.

This new property will be in the next maintenance release.

Quote:
2) What is the proper/documented way to achieve contextual tool windows? I would like to dynamically show/hide various tool windows depending on the type of active document (like VS shows/hides e.g. palette tool window when editing images). Is this possible?

In response to this question, we've added a concept of the "primary window" to our MDI hosts. The primary window is the currently selected window in the host. For tabbed MDI, which can have several selected windows at once, the primary document is the one that was selected/activated last. There is also an associated event that you can listen for.

We've added a QuickStart to show how this can be used. This will all be available in the next maintenance release.