Default WindowGroupName on Containers

Hi Andrew,

That wouldn't work well because containers are transient and get dynamically created/destroyed as layout changes occur.  You never really want to make empty containers or reference containers by name in Docking/MDI, because they won't reliably always be in the layout.

We're open to discussing other API suggestions though to help you with your scenarios.

Hi - 

Yes, I realized that quickly as I tried to implement a similar scheme using attached properties. It seems that even on initial layout (no serialization etc.) that the containers are only instantiated if they have concrete DockingWindows assigned meaning thay cannot be found/used as attachment targets.

I can move this into a separate question, but how can I achieve an initial layout with only MVVM databound documents split between two TabbedMdiContainers?

Thanks!

Hi Andrew,

Right I believe we optimize the layout (remove empty containers) at certain points.

To arrange windows with more control, you can use the DockSite.WindowDefaultLocationRequested event.  It allows you to specify the e.Target (could be another docking window, etc.) and e.Side around which the docking window should be placed against the target.  Check out the "Default Locations" QuickStart for examples of how to use it.

Hi - 

I have attempted to use the WindowDefaultLocationRequested event, however it does not seem to assist with my question, since:

A) As discussed, the container won't exist unless it already has a document, so there is no way to set a TabbedMdiContainer as a target.

B) The event fires before the document window is attached to any MDI container, meaning that you can not use any of the methods such as MoveToNewHorizontalContainer.

C) The event is reentrant if you try to first use MoveToMDI, then the MoveToNew... methods.

D) Setting the e.Side for DocumentWindows seems to have no effect on location, or at least does not create a new TabbedMdiContainer.

Hi Andrew,

I know there won't be a container yet but the logic I would use is:

1) If this the first document (meaning no Setup or Results are open), just let default document location logic execute.  That will open it in a TabbedMdiContainer.

2) If there is at least one document window already open, e.Target should already be filled in with a DocumentWindow that had the same WindowGroupName, assuming that there was a match made on that.  Look for that scenario.  If there is an e.Target with the same group name, let it use default logic. 

3) If not, then you know you need to handle the event with your own logic.  At this point, you'd want to target another document window (one of the existing ones with the other group name) and set e.Side to be one of the sides of that, whichever side is appropriate.  That should work, even for documents.

Hi - Thanks for the help.

That was the missing piece to the puzzle! Setting the target to another window did the trick. Works very well.

Thank you kindly!

Awesome... love the new features for default locations in 2016.1.  They provide a lot of flexibility.

I have run into another issue with the previous solution:

If I set the Target to another DocumentWindow and set a Side then the DocumentWindow does not get removed from the layout after a Close. I can see that both the WindowsClosing and WindowsClosed events are firing, and that the DcoumentWindow is detached from the DockSite, but it is not removed from the layout. I have tested removing all 'OnClose' logic/handlers and it still behaves the same way. Also there appears to also be an issue with Floating said window.

I have created an extremely bare bones solution that exhibits both behaviours:

https://www.dropbox.com/s/non40hwrr63dmcr/ActiproDockingIssue.zip?dl=0

Perhaps there is still an issue with the way I am implementing the WindowDefaultLocationRequested event.

Thanks kindly.

Hi Andrew,

Thanks for the sample, it looks like you found a one-liner bug in our dock-to-the-side logic when targeting a docking window.  We've fixed the bug for the next build, but in the meantime you can work around it by targeting the container instead with your line modified to something like this:

args.Target = args.Window.DockSite?.DocumentWindows?.FirstOrDefault(d => d != args.Window)?.ParentContainer as IDockTarget;

Works like a charm - Thank you kindly! With this depth of control over default layouts it really adds a level of professionalism and immediacy to the end-product. Much appreciated.