Changes to Docking/MDI for WPF?

Hi Peter,

Yes since we made massive internal changes for this 2016.1 version, we took the opportunity to make several breaking changes to refine the API a bit.  We've tried to make notes of all breaking changes in the "Converting to 2016.1" topic in the documentation and it provides a lot of extra info on certain altered feature areas too.  Since the updates to the product were so enormous, we may have missed a describing a couple API changes and are updating the topic as we come across those cases.

1) CanDrag is CanDragTab.  CanDockX is replaced with a general CanDock since the directions didn't always make sense in certain layout scenarios.  One thing we were considering doing is having an event or callback that would let you determine if a certain floating dock host would be valid for a drop target attach and sides. Thoughts on that?

2) We'll add the OnIsSelectedChanged virtual method back in for the next build.

3) All *Raft* properties are renamed to *Float*.

4) We will add these missing virtual methods back in for the next build.

5) Now floating dock hosts support full MDI areas too, so Workspace is now retrieved via dockSite.PrimaryDockHost.Workspace.  The DockSite's child content can be set via the Child property in 2016.1.  We'll update the docs for that.

6) TabbedMdiHost no longer inherits ContentControl so use its Child property to specify a child element instead.  We'll update the docs for that.

7) The DockingWindowState enumeration no longer has a Floating value. Now floating dock hosts can have docked, auto-hidden or document-oriented docking windows in them so that option no longer fit.  We'll update the docs for that.

8) You shouldn't have ever needed to access those since containers are transient.  What were you using them for?

Thank you for your detailed reply. Since I don't have time to deal with this right now (other deadlines) I am reverting back to version 14.1 for now, but I plan to come back to this later. 

Here is what I am doing with the TabbedMdiContainer (I last looked at this code back in 2012, so I am rusty with it)

Accessing it in a subclass of DockSite like this:

in the subclass constructor

    m_TabbedMdiHost = new TabbedMdiHost() { TabOverflowBehavior = TabOverflowBehavior.ScrollWithMenu };
    this.Content = new Workspace() { Content = m_TabbedMdiHost };

accessing it through

    private TabbedMdiContainer MdiContainer { get { return m_TabbedMdiHost.Content as TabbedMdiContainer; } }

and using this in the following properties/methods

    /// <summary>
    /// Get the content of the selected tab/window
    /// </summary>
    public object SelectedTabContent
    {
        get { return (MdiContainer != null) ? MdiContainer.SelectedContent : null; }
    }

    /// <summary>
    /// Remove a window containing the specified content.
    /// </summary>
    /// <param name="content"></param>
    public void RemoveContent(object content)
    {
        if (MdiContainer != null && MdiContainer.Items != null)
        {
            for (int i = 0; i < MdiContainer.Items.Count; ++i)
            {
                DockingWindow window = MdiContainer.Items[i] as DockingWindow;
                if (window != null)
                {
                    if (window.Content == content)
                    {
                        window.Close();
                        window.Content = null;
                        break;
                    }
                }
            }
        }
    }

Maybe this is not the best way to accomplish these functions, but it worked fine for use. If you can let me know the best way to do the same thing in 16.1 it would be much appreciated. As an aside, I do remember thinking that the object model for this control seemed a bit complex, so if the new version simplifies it that would be a good this (but I recognize sometime complexity can't be avoided!).

Thanks

Peter

Hi Peter,

Actually you can still remain on 2016.1 because we packaged the "old" version of Docking/MDI in the Docking.Legacy assembly.  This is also described in the Converting to 2016.1 topic and is good for a situation like yours since you can reference that version to have everything that was in the last 2015.1 version but with the latest other 2016.1 controls.

The way you are accessing containers isn't recommended.  Tabbed MDI containers are transient objects that get created/destroyed as layout changes occur in the dock site.  Things like DockSite, Workspace, and docking windows are really the only objects you should ever directly reference.

In 2016.1 we track a DockSite.PrimaryDocument property that points to the current (or last active) document.  Maybe that would be useful for you to know which one is active?  There are other props like DockSite.DocumentWindows that give you access to all of the registered documents.  If you have any other questions, feel free to write.

Hi Peter,

I forgot to post here that in the more recent builds of Docking/MDI 2016.1 we added a new DockSite.WindowsDragOver event.  This event is raised while dragging docking windows over a new drop target. This event is passed an instance of DockingWindowsDragOverEventArgs, which indicates the DockHost being dragged, the docking windows inside that DockHost, and the IDockTarget control that the pointer is currently over.  It tells you the dock guides that will be displayed by default and allows you to prevent certain ones from showing up, such as if you never want to allow left/right docking, etc.