Maximize and restore a docked document

Hello,

From the XAML, it appears you are using Prism integration with Docking/MDI and have a tabbed MDI host for the document display.

Can you provide some more detail about your document setup and where you are asking about a document being maximized?  For instance do you mean in a floating document, or within the main MDI host while other documents are still open?  Have you seen other implementations in apps similar to the behavior you are looking for?  Thanks!

Hi,

Yes, we are using Prism integration with Docking/MDI.

The base class for docking item view-models derives from ObservableObjectBase.

Sample:

There are 3 docked windows that implement 3 charts (all visible).( The views are implemented using UserControl).

If the user needs to see one Chart with more details maximize this window:

dockSite.ActiveWindow.Float(new Size(width, height));

When the user has finished, press a "Restore button", and the window is docked again in the original place and layout.

-> This is the step I have not clear how to do. I have run all samples included in SampleBrowser, but i can't find this behaviour.

Please ask if you need more details.

Thanks

Hello,

If you run our main Docking/MDI demo, do these steps, which I believe will replicate what you're trying to achieve:

1) Move the "About.txt" document to the right of "Document1.cs".

2) Right click on the "About.txt" tab and click the "Float" menu item.

3) Right click on the "About.txt" tab (now in its own floating host window) and click the "Move to Main Document Group" menu item.

4) The document is restored back to the right of "Document1.cs".

If that is the behavior you want, the menu item executes the DocumentWindow.MoveToPrimaryMdiHostCommand command there.  You could have a custom button execute the same command.

Hello,

  This is the behaviour I want, but not only if a document windows is in the Primary Dock.

 In main Docking/MDI demo:

  1) File -> New -> Text File -> Make Floating Window

  2) Move the "About.txt" to the Right of the new Text File, then:

        - There is the Main Window with the "Document1.cs"

        - There is another group that contains "About.txt" and "New document"

 4) Right click on the "About.txt" tab and click the "Float" menu item.

 5) Now, the desired behaviour is that "About.txt" could be  restored to the right side of  "New Document" not to Primary mdi

Thanks

Hello,

Thank you for the clarification on the behavior you are after.  When a document is floated to another dock host, it should leave a breadcrumb behind where it can restore to a previous dock host in the same location it was in before.  And we do have a way to programmatically return a document to a particular dock host's MDI, which is an API the previously-mentioned DocumentWindow.MoveToPrimaryMdiHostCommand uses. 

That being said, we don't track which order a document moves between dock hosts.  This is something you would need to track on your own, perhaps by looking at the DocumentWindow.DockHost property.  If you do know the dock host to restore to, you can call DocumentWindow.MoveToMdi(dockHost) to move the document there.

A couple DockSite properties also provide access to the available dock hosts.  The DockSite.PrimaryDockHost property always points to the dock host in the main DockSite.  The DockSite.FloatingDockHosts collection tracks other dock hosts that are external to that main DockSite.

Hello,

  I have try this option previously:

   1.- Get window dockhost

   2.- Float window

   3.- Use methods .MoveToMdi(savedDockhost)

 This, returns the window to the Floating Dockhost as a Tabbed document, not maintains it's original Size and Position (that is the expected behaviour)

 Original Size and Position is only maintained if the window is in the PrimaryDockHost, but not in Floating Dockhosts.

Thanks

Hello,

What you described is accurate.  It appears that only one floating dock host tracks breadcrumbs (the ability to fully restore a document window) at a time.  In your scenario, you float the document window that is already in a floating dock host to a second floating dock host.  When that happens, the breadcrumb for that document window in the first floating dock host is removed since the document window is now in another floating dock host.

After revisiting this, the logic behind that was that if you would close a floating document window, it wants to have a single breadcrumb in any of the floating dock hosts so that it knows exactly where to restore to if the document window is reopened.  The primary dock host (in the dock site) always tracks a breadcrumb for document windows since that is used for the "Move to Main Document Group" functionality.

When you call MoveToMdi on a dock host that does not currently have a breadcrumb in place, it will go to a default location within that dock host instead of being exactly restored to its previous size and position.

Unfortunately due to the above, we don't have the information tracked to restore a floating document window back to another previous floating dock host in the exact same size and position.  The only fallback is to possibly try and save some location information about the document window (like its dock host, attached and surrounding other document windows, etc.) and use that to determine some programmatic docking methods to call when you want to restore it to the other floating dock host.

Hello,

   Thanks for your answer. 

    Now, parsing the layout xml before Floating the window, I'm saving all settings.

    Using dockWindow.Dock(....) -> I can restore the docking window to the original place.

    What I can't achieve is restoring the original windows sizes in the Workspace. 

    Could you give me some tips?

Hello,

When a docking window is docked, it will try and use its size set in ContainerDockedSize as described here.

The "Programmatic Sizing" and "Programmatic Layout" QuickStarts in the sample project also show multiple ways of programmatically updating a docking layout, including sizing container slots.  That might be a good reference to look at.