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?

 I need the same behavior.

Why infragistics would deliver a control that would not have the same functionality as their WinForms control that we have come to love bafles me to this day.

 I did some experimenting.

Here is what I ended up with that simulate the splitter control filling in the page.

         <igDock:XamDockManager x:Name="_xamDockManager" HorizontalAlignment="Stretch" Margin="0,0,0,0" VerticalAlignment="Stretch" Content="" NavigationOrder="VisibleOrder">
            <igDock:XamDockManager.Panes>
                <igDock:SplitPane Height="{Binding Path=ActualHeight, ElementName=_xamDockManager, Mode=OneWay}"
                                  Width="{Binding Path=ActualWidth, ElementName=_xamDockManager, Mode=OneWay}">
                    <igDock:TabGroupPane>
                        <igDock:ContentPane AllowDocking="True" />
                    </igDock:TabGroupPane>
                    <igDock:TabGroupPane>
                        <igDock:ContentPane />
                    </igDock:TabGroupPane>
                </igDock:SplitPane>
            </igDock:XamDockManager.Panes>
        </igDock:XamDockManager>

You can just copy the code in any window and you will see the results.

 However! Tere is still area on the far right that does not get covered.

Can someone give some insight why is that still there?

Thanks

There are a couple of reasons why your xaml doesn't fill the available area. First, you're assuming that there is no chrome/padding/borders/etc. between the XamDockManager and the SplitPane itself which may or may not be the case depending on the styling, theme, property settings, etc. Second, when there is content, the XamDockManager will follow what VS does which is to always leave a minimal amount of space for the content. You set the Content to an empty string; you can remove the Content attribute you put on the element.

Note, I would not recommend going this approach - both for the first point that I mentioned but also because users can still create other docked panes (dragging over the root docking indicators for example) so your bounded width/height splitpane would likely hide/overlay those panes. Also, users can remove/drag out/close/unpin all the panes within that split pane at which point the split pane will be hidden. If they have dragged all the panes out of the split pane, the split would be hidden and when they drag the pane to a new docked location, a new split pane would be created docked to the edge to which the user has docked the pane.

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.

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.

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.

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.

JoeKahl said:

The XamDockManager is frustrating.  It has cool feature that take a lot of time to develop.  I appreciate the capabilities.  However...

Why does it reserve space?  For what?