What is the replacement for IDockingWindowInitializer?

Hi Ian,

In the new 2016.1 version, we no longer have an interop assembly for Docking/MDI and Prism and any code that was needed for it is now right in the main Prism sample we provide.

The IDockingWindowInitializer used to be a way to supply default location and property information for a docking window.  But now that Docking/MDI is much more MVVM friendly, all you do in the new version is bind properties in a docking window Style like we show in the MainView.xaml of the MvvmToolWindows and MvvmDocumentWindows samples to achieve similar property setting features.  Also using our new Default Location features (see documentation and related sample) are how you determine where a newly opened docking window will show up.

Moving from 2014.1 (Build 0600) is a real pain.  The documentation on what's changed more often hints at things but doesn't contain information like this.

Is there any other documentation that covers the changes in more detail highlighting where something has been removed and what it's replacement is?

Hi Ian,

The Docking/MDI "Converting to 2016.1" covers most breaking changes in detail, but it does look like the Prism portion could use more information.  If you run across portions that aren't clear and need more detail like this, please let us know and we will beef those sections up and give assistance.  We want to make the conversion information as clear as possible without the need for extra support.

Here's one for you.

Now that the IDockingWindowInitializer has gone we are creating the ToolWindow ourselves which was previously done for us.

This code was then used to add the tool windows to the primary window container.

// Add tool window to primary docking region
this.GetRegion(this.PrimaryWindowContainer).Add(toolWindow, name); // Tool windows are always in primary container

When we inspect dockSite.DocumentWindows we can see that it has increased the number of DocumentWindows by one causing our toolwindows to be duplicated.  It will then display them but only as document windows and not the tool window docked as we would expect.

Hi Ian,

All the source code for all Prism interaction is open source in our Prism sample project now.  That includes all the code (but updated) that used to be in the old Prism integration assembly prior to 2016.1.  So you can see and adjust all functionality as needed there.

For instance DockSiteRegionAdapter has a GetDockingWindowItemKind method that examines the VM item to see if it's a tool or document window and creates the appropriate one as a result.

The DockSiteRegionBehavior class has a lot of functionality for doing the legwork on connecting Prism and DockSite functionality.  But we also have a number of core MVVM features in use here behind the scenes.  Such as when a window is first opened, it will use any default location information that it is provided (see documentation on default locations) to determine where to open it.

It's hard to say what's going on in your case without debugging but perhaps you don't need that line if it's causing a duplicate?  If you'd like us to debug anything, please make a new very simple sample project showing the issue, and email that to our support address, referencing this thread in the email.  The simpler the better since Prism itself can get complex.  Thanks!

Thanks I've got a lot further but now I think I'm starting to get to the strangeness of my setup.

I have multiple docksites each with thier own PRISM region.  The docksites have been linked togther usnig your method to do so.  When a document is dragged to the new docksite OnDockSiteWindowUnregistered is called for the old docksite and OnDockSiteWindowRegistered is called for the new.  These are the same methods that get called if I make use of the Prism region manager to Add and Remove a viewmodel.

The problem is the region isn't updated when the docksite is and if I tried to remove and add it to the correct region in these methods it will cause a stack overflow as we recurse in constantly trying to remove or add to the region.

What is the suggested mechanisum to handle switching between regions in docksites?

Hi Ian,

Could you modify our Prism sample to show this scenario and email our support address with your sample?  That way we can debug what you are seeing and make sure that any changes we make properly fix the problem for you.  Be sure to rename the .zip file extension of what you send so it doesn't get spam blocked.  Thanks!

I'll set about getting this done as soon as possible to try and show the problem.

While I'm working on that can you confirm if you would expect the region a document belongs to to change when moved between docksites?  If not then on what event would you be listening for to process the change?

Hi Ian,

Thank you for the sample.  The code in our Prism sample now doesn't appear to handle linked DockSites, and nothing in there alters regions.  It only responds to region view changes.

Can you tell me which code (and where) to add to see the stack overflow occur you described?  I'd like to look into that.  Thanks!

Start it up and drag one of the default documents to the second container window.  Once it's there you'll note the bindings to the viewmodel get lost and you lose all the adornments on the tab for the document such as the title.

Secondly close the document that is now on the secondary screen.  You'll get an assert because the region that is on the secondary screen does not own the document.  If you do close documents on the main screen they are also not being removed from the region on that window.

Hi Ian,

We aren't experts in Prism so please bear with us and help provide any insight you have.

What's happening is that when the drop occurs on the linked DockSite, the DockSiteRegionBehavior.OnDockSiteWindowUnregistered method executes and clears the container bindings.  That is to be expected. 

1) A first question is, should the DockSiteRegionBehavior be removing the view model from the region here?  Right now we don't do that, and that's why you see that a closed document's view model is still listed in the region.  Would this code be appropriate at the end of that method?

// Ensure the view is removed from the region
var region = this.Region;
if (region != null) {
	if (region.Views.Contains(e.Window))
		region.Remove(e.Window);
	else if (region.Views.Contains(e.Window.DataContext))
		region.Remove(e.Window.DataContext);
}

2) The next issue is that in the OnDockSiteWindowRegistered method above it, the IsDockingWindowAValidContainer check returns false and it quits out without restoring container bindings.  This causes the empty tab title, etc.  The reason that returns false is that when we assign the new DockSite, we see if the view model can be added to the new DockSite's DocumentItemsSource.  In this scenario, the DockSite.DocumentItemsSource is a read-only collection, and thus the document window falls back to being added normally, without being flagged as a container generated by an items source.  To sum up, the problem here is that the document window is transferring as a non-container.  

3) It seems like OnDockSiteWindowRegistered might also need some way to register the view model into the new region?  Doing so would probably cause a new document window container to be generated though, instead of using the one we just dragged.

This is a bit of a pickle.  The main setback is that the DocumentsItemSource we use for Prism right now is read-only and that prevents #2 from working.  Which in turn I believe causes odd side effects and problems for #3.

I've sent a new version of the sample which I think works around the issue but would appreciate your opinion on if it will cause problems working the way that it does.

When a user drags a document between windows OnDockSiteWindowRegistered is triggered.  If you look in the sample behaviour it removes the datacontext of a DocumentWindow that is created at this point and takes the newly created window and removes it.  Then we add the datacontext viewmodel back to the new correct region for that container.

The unregister remains as your example.

Hi Ian,

The new sample you sent seems to be fine.  I don't think the issue you commented on is a problem in your scenario as long as you are doing everything via VMs being adding to regions and not views directly.

That being said, I think this all could be made better if we had some customization point for supporting trying to remove from an ItemsSource (when unregistering) and add to an ItemsSource (when registering).  Right now we see if the items source is an IList and update it if so.  But Prism uses read-only enumerables for the items source, so our code doesn't isn't able to add the document window as a "container" when it's moved to the new dock site.  Just not sure of the best way to add the customization point (virtual methods on DockSite, events, etc.).