Default WindowGroupName on Containers

Docking/MDI for WPF Forum

Posted 4 years ago by Andrew Hanlon
Avatar

With the new version, we have the ability to set a 'WindowGroupName' on DockingWindows which works wonderfully to ensure that associated windows have affinity to one another. 

It would be great to be able to set a similar property on layout elements such that a DockingWindow would fall back to opening in an associated container if no other windows with the same 'WindowGroupName' are present. This would greatly simplify setting up a complex default layout.

Example:

        <docking:DockSite Name="DockSite" Grid.Row="2">
            <docking:Workspace>
                <docking:TabbedMdiHost>
                    <docking:SplitContainer Orientation="Vertical">
                        <docking:TabbedMdiContainer DefaultWindowGroupName="Setup"/>
                        <docking:TabbedMdiContainer DefaultWindowGroupName="Results"/>
                    </docking:SplitContainer>
                </docking:TabbedMdiHost>
            </docking:Workspace>
        </docking:DockSite>

Comments (10)

Posted 4 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 4 years ago by Andrew Hanlon
Avatar

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!

[Modified 4 years ago]

Posted 4 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 4 years ago by Andrew Hanlon
Avatar

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.

[Modified 4 years ago]

Posted 4 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 4 years ago by Andrew Hanlon
Avatar

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!

Posted 4 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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


Actipro Software Support

Posted 4 years ago by Andrew Hanlon
Avatar

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.

Posted 4 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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;


Actipro Software Support

Posted 4 years ago by Andrew Hanlon
Avatar

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.

The latest build of this product (v2019.1 build 0683) was released 1 month ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.