Thanks for the quick response. I cannot use the DocumentContentHost because it always displays the panes as TabGroup. The requirement for me is to simply displace multiple panes without a real document area. The content does need to be a pane because I need the float/dock/pin capabilities. And really, there is really no concept of a single "content" pane. The requirement is that each pane is equivalently as important so that each one is considered a conent pane. What other options do I have? Can I extend this SplitPane to make it work? or are there any base classes I can derive from?

AndreasAtWork said:

In the first solution - we have the problem, that there are TabHeader on the Main Area. Maybe we can try to remove that.

One would only use DocumentContentHost when one wanted to use a tabbed document interface like Visual Studio. It does not sound like you want a tabbed document interface so that is not what you would use.

AndreasAtWork said:

In the second solution everything looks good - but we lost the focus notification, so the splitpanes wont closed automatically if you click on a control inside the main content area.

The xamDockManager is a ContentControl for this reason - so that you could put your singular content as the central portion of the control. It sounds like you want your control to be within the center of the XDM and the panes docked around it so it sounds like this is the best solution for you. With regards to the issue you are describing I am not able to replicate that. BTW SplitPanes don't close so I assume that you mean that the flyout for an unpinned contentpane does not close. It would close as long as keyboard focus was shifted out of the pane. Just clicking into empty space within the element in the middle wouldn't necessarily take focus away from it. Take the following example:

<igDock:XamDockManager>
    <igDock:XamDockManager.Panes>
        <igDock:SplitPane SplitterOrientation="Horizontal" igDock:XamDockManager.InitialLocation="DockedLeft">
            <igDock:ContentPane Header="ABC" IsPinned="False">
                <TextBox AcceptsReturn="True" />
            </igDock:ContentPane>
            <igDock:ContentPane Header="DEF">
                <TextBox AcceptsReturn="True" />
            </igDock:ContentPane>
        </igDock:SplitPane>
    </igDock:XamDockManager.Panes>
    <Grid>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="Auto" />
            <ColumnDefinition />
        </Grid.ColumnDefinitions>
        <Grid.RowDefinitions>
            <RowDefinition />
            <RowDefinition />
            <RowDefinition />
        </Grid.RowDefinitions>
        <Label Content="First" Grid.Column="0" Grid.Row="0" />
        <TextBox Text="First" Grid.Column="1" Grid.Row="0" />
        <Label Content="Second" Grid.Column="0" Grid.Row="1" />
        <TextBox Text="Second" Grid.Column="1" Grid.Row="1" />
        <Label Content="Third" Grid.Column="0" Grid.Row="2" />
        <TextBox Text="Third" Grid.Column="1" Grid.Row="2" />
    </Grid>
</igDock:XamDockManager>

Run this and click on the ABC tab to activate it and fly it out. You'll notice that clicking on the labels in the middle won't cause the flyout to close because keyboard focus doesn't shift when you do that but if you click on the textboxes in the middle then the flyout does close. If you wanted the flyout to close when you clicked on the label then you would need to ensure that focus shifts. For example you might do that with your own usercontrol that contains that central content where if in the mouse down for it it doesn't have keyboard focus (e.g. IsKeyboardFocusWithin is false) that you call Focus on the usercontrol. Or you might put the content in a scrollviewer. You'll notice that if you put a scrollviewer around the Grid in the example above that clicking on the label will cause the flyout to close. If you use something like Snoop you will see that that is because the ScrollViewer sets focus to itself (assuming it is focusable).

AndreasAtWork said:

In the third solution, the header of the lst content pane will now fill the normal header area. Is it possible to remove this too? I dont want that the user can close, move, dock the main document area, so i dont want to have this extra space.

The FillContainer LayoutMode was added after a few requests came in for this functionality. It is specifically for customers that do not have a singular central content and don't want to use a tabbed document interface. Instead they want the available area of the XDM to be filled by the content panes docked within. In FillContainer mode the XDM will take the innermost dockable split pane and fill the available area. That pane is just like any other dockable pane in that panes may be dragged into it and out of it, etc. It does not sound like that is what you are looking to acheive.

Thank you for your reply. I have tested your solution and this will work, but our scenario is more complex. Please try this example.

<Grid>
        <igDock:XamDockManager Background="Blue">
            <igDock:XamDockManager.Panes>
                <DockManager:SplitPane SplitterOrientation="Horizontal" igDock:XamDockManager.InitialLocation="DockedLeft">
                    <DockManager:ContentPane Header="ABC" IsPinned="False">
                        <TextBox AcceptsReturn="True" />
                    </DockManager:ContentPane>
                    <DockManager:ContentPane Header="DEF" IsPinned="False">
                        <TextBox AcceptsReturn="True" />
                    </DockManager:ContentPane>
                </DockManager:SplitPane>
            </igDock:XamDockManager.Panes>
            <Grid>
                <igDock:XamDockManager Background="Bisque">
                    <igDock:XamDockManager.Panes>
                        <DockManager:SplitPane SplitterOrientation="Horizontal" igDock:XamDockManager.InitialLocation="DockedLeft">
                            <DockManager:ContentPane Header="ABC" IsPinned="True">
                                <TextBox AcceptsReturn="True" />
                            </DockManager:ContentPane>
                            <DockManager:ContentPane Header="DEF">
                                <TextBox AcceptsReturn="True" />
                            </DockManager:ContentPane>
                        </DockManager:SplitPane>
                    </igDock:XamDockManager.Panes>
                    <Grid>
                        <Grid.ColumnDefinitions>
                            <ColumnDefinition Width="Auto" />
                            <ColumnDefinition />
                        </Grid.ColumnDefinitions>
                        <Grid.RowDefinitions>
                            <RowDefinition />
                            <RowDefinition />
                            <RowDefinition />
                        </Grid.RowDefinitions>
                        <Label Content="First" Grid.Column="0" Grid.Row="0" />
                        <TextBox Text="First" Grid.Column="1" Grid.Row="0" />
                        <Label Content="Second" Grid.Column="0" Grid.Row="1" />
                        <TextBox Text="Second" Grid.Column="1" Grid.Row="1" />
                        <Label Content="Third" Grid.Column="0" Grid.Row="2" />
                        <TextBox Text="Third" Grid.Column="1" Grid.Row="2" />
                    </Grid>
                </igDock:XamDockManager>
            </Grid>
        </igDock:XamDockManager>
    </Grid>

If you open a parent flyout (blue) and then click on one of the both child flyouts (Bisque), then you will see, that the parent flyout will not be closed. If you click on one of the label - you see the same behavior. Only if you click on one of the textboxes, then the parent flyout will be closed.

The xamDockManager will not clear the ActivePane if keyboard focus is within a different focus scope than the focus scope containing the xamDockManager. It does this because when you put focus into a focus scope such as a ribbon, toolbar or menu within the same window it is assumed that you want the active pane to remain intact and that focus will be restored to the pane after that point. In this case the other focus scope is the pane in the other dockmanager. We can make a change such that we do not do this if the other focus scope is a contentpane of a different dockmanager. I'll see about getting a case created for this issue.

This would be nice, because there are other connected issues to that behaviour. In our project I had prefered solution 3 (a splitpane with XamDockManager LayoutMode="FillContainer"). Inside this splitpane (the main pane of the application) we have a child dockmanager. But if we use there a bubbled event, the OriginalSource of the event is always the Splitpane of the outer XamDockmanager. If we switch to solution 1 or 2, we get the right SplitPane of the inner XamDockmanager for that.

AndreasAtWork said:

This would be nice, because there are other connected issues to that behaviour. In our project I had prefered solution 3 (a splitpane with XamDockManager LayoutMode="FillContainer"). Inside this splitpane (the main pane of the application) we have a child dockmanager. But if we use there a bubbled event, the OriginalSource of the event is always the Splitpane of the outer XamDockmanager. If we switch to solution 1 or 2, we get the right SplitPane of the inner XamDockmanager for that.

I'm not sure what you are referring to. The nested dockmanager's wouldn't affect the OriginalSource of events you raised except for command related events because in that case the WPF CommandManager reraises the event each time it hits a focus scope as it it traversing up the tree. If you have a sample that demonstrates that issue I can better answer what is happening.