Thanks for the pane helper. We don't use floating or tabbed panes, so the helper covers our use case.

Just for the clarification:

- Yes I do not need to know how your stuff works. No time to disassemble and look through your code, neither. That's why I asked for help. 

- It does not matter what typical scenarios are. Your controls should provide as much functionality as possible. There is and always will be need to do something programmatically and provide the rich experience to the end user. 

- I have been using your controls for about 2 years now. I know what works and what not. Lack of MVVM, public properties, helpers, performance :) But we are lucky that WPF provides templating so you can always hack yourself in. I would gladly like to be more cost efficient for our project... But that's life and then you die. 

At the end I must say your components are somehow more fancy than useful... But that is what's sells? Nice animations and stuff. Somehow reminds me of apple. They also always say what we need and what don't :)

Anyway thanks again for the help.

Regards

Igor

The samples provided are purposefully small to try and focus on just the issue being discussed. In this case you asked about adding a pane to the right of another but didn't really provide much context about the specific scenario. Typically one sets up the dockmanager at design time with the content to present to the end user, allows the end user to manipulate those panes and the developer need only save and load the layout. How the layout is saved or how the tree is manipulated to restore that layout is opaque and the developer need not worry about that. Those that do alter the tree at runtime typically are doing basic some manipulation of the pane tree (e.g. adding a new floating pane or a new root docked pane) and need only worry about creating a SplitPane, setting the attached InitialPaneLocation, and adding that to the Panes collection of the xamDockManager.

General manipulation though requires much more detailed knowledge about how the panes are organized, consider what the (logical) parent is, its current location, etc. The short answer is that there is no single method to replicate what the drag and drop does because there are lots of situations that the drag and drop has to handle which is why glyphs are presented and even those don't necessarily cover every possible option. If you're looking to create a new pane but inserting it somewhat like what the center dock glyph does then perhaps you would do something like what I have added to the attached sample. This handles the OptionsMenuOpening event and adds a few menu items that will call a helper method that creates a new pane relative to that pane. The helper method evaluates the pane's current location (because the pane may be unpinned or in a document content host) and then tries to either add a new pane directly to that parent or move the related pane (or one of its ancestors) to house the new pane and the related pane as close to where they were as possible.

Seriously? Example with one pane and add option. Array with integer position? Maybe your customers aren't first year students?

How about 20 panes, inside of couple split panes, try to index that :) Please next time post a real world example, not some demo app with 2 panes. How about how to position top, left etc. Find correct split pane (as a parent), keep the existing order of other split/content panes in the layout....

Thanks.

Igor