Advanced use of Docking

Hi Truls,

We haven't made a nested DockSite quickstart yet so I just put one together here. I have a root DockSite with two tool windows that also contains tabbed MDI of two document windows, each with their own DockSite and two tool windows in them.

I see bugs with the rendering of tool window tabs in the document window DockSites where they look like the tabbed MDI tabs.

1) I think it is showing the tabs at the bottom, just that they are rendering incorrectly right now. Can you confirm that?

2) Not right now however I'll mark do to try and add an option that prevents docking for documents. Then you'll still be able to drag to resort. Sound good?

3) Yes you can do this however it will close automatically when you switch tabs to show another "Desktop". This is because the DockSite.Unloaded event hides floating windows in our updated code here.

4) Unfortunately you can't do this. Each tool window is associated with a specific DockSite. You'd have to close the tool window, remove it from its current DockSite.ToolWindows collection, then you could dock it on the second DockSite.

Ah, speedy reply. Love it!

You are fairly close to what I am doing.

1)
My Desktop TabStrip is the Root DockSite and will show the tabs at the top. I did not find a property/method that allowed me to set it to Bottom.

The Tabs of ToolWindows docked in the same DockSite within the Desktop are shown at the bottom in my project, altough this is not a feature I will use much as most Views will be fully docked and visible within the containing Desktop.

2)
Right now, my research project uses Docking to 'simulate' a standard TabControl (I like your rendering and theme support better) at the root. I do not understand whether your answer on this point confirmed that there will be an option that can prevent docking/redocking, but let the user still drag the tabs around within the TabStrip header to reorder the tabs? English is not my native language, so it may be my reading, but if your answer results in a mechanism that will make me add/remove Desktops through the API and reorder them visually, you are spot on! The Close button may be used to remove Desktops though.

3)
In my research project, floating ToolWindows that prevsiously where docked in "Desktop 1" are still visible after avtivating "Desktop 2" (which hides "Desktop 1"), but not moveable. They can be activated though (switching to the dark blue window header). I guess your code has changed this since the Beta25 'Release'?

4)
Would your technique suggestion on this point make the ToolWindow 'blink' (lengthy visual redraw) or become hidden? Could I trap an 'OnFloated'-event on the ToolWindow/other and remove it from its owning DockSite? Would it become 'orphaned'? My real need is to support a way for users to move a View from one Desktop to another. Combine this with View creation and View cloning and you may see my actual need. User friendliness and intuitive functionality is the key here. Since I have not yet seen an existing product using this 'Multi-Desktop' UI-metaphor, I am searching for a good way to handle this.

5)
What is a QuickStart?

Looking forward to your product launch!

Some info for your marketing guys:

a)
I selected Actipro as you are one of the first actors in the WPF market offering missing (relative to .NET 3.5) UI functionality of high enough quality (quality is one of my key 'filters').

b)
Pricing and Licensing is right!

c)
FULL support of XBAP with as low a threshold to use as I think is possible. I demo my products as XBAP applications and use the 'real' application with all the storage and network mechanisms simulated. As such, it is the actual frontend of the applications that are used.

d)
And now, my support experiences are great too!

Truls Gartland

1) Can you maybe email a screenshot so I know we are talking about the same thing here? Maybe circle what you want to appear at the bottom. Thanks!

2) If you are talking about the tabbed MDI portion, then yes, one I add those options to disable docking, it will still allow for reordering and closing.

3) Yes this has changed in the code here so that when the DockSite gets unloaded, it closes its rafting (floating) windows. The build you have didn't do that yet.

4) Hmm I don't think there would be a drag/drop way to do this. However you can customize the context menus and maybe add an item that does the steps i said to move it from Desktop 1 to Desktop 2. Would that work for you? Perhaps we could even create a QuickStart to show that too.

5) The term "QuickStart" is just what we call a small sample in our Sample Browser that focuses on certain functionality for a product.

Thanks for the other info too.

BTW, a whole array of new global options are now implemented for the tabbed MDI area that can let you prevent docking but still allow reordering. These will be in the next build.

You also can turn off close buttons in the tabbed MDI area.

I sent an e-mail with an attached image regarding pt. 1)

You may use the image in the forum or other public material.

As to pt. 4) I am cranking my brain trying to find a good way for the user to dock and move a ToolWindow in any Desktop.

My current design still stands as I find this mechanism to be the most intuitive and flexible for now:

- When a new View is created or an existing View is cloned, the new View is displayed as Floating. It will not be 'attached' to any Desktop as far as the user is concerned, i.e. double-clikcing the View header will not dock the View. Also, when the user wishes to move an existing View to another Desktop, this View is first Floated.
- While the View is Floated and visible in front of the MainView, the target Desktop is selected in the Desktop TabStrip
- The user now drags the Floating View over the target Desktop, the Preview kicks in when above the Desktop client area and the user drops in the desired docking position.
- The View is now bound to a Desktop.

Can you see a coded way of doing this with the Actipro Docking? I.e. overriding methods, implementing new code to support the above case, etc? I do not expect this to be supported in Docking out of the box, so a coded solution is fully acceptable.

Also, I have another question:

6)
Is it possible to edit the Desktop title directly in the Tab?

Truls Gartland

4) Hmm.. I'm really not sure how you would go about doing this since a tool window is tied to a DockSite. To be able to dock onto another DockSite you would need to detach it first from the first DockSite. But this probably means that you lose visual docking functionality.

Maybe you could create your own floating window that contained the tool window content when you create this "unattached View". But there wouldn't be an easy way to transition back to a floating tool window that has docking previews, etc.

I'm really not sure how you envision it is possible. However you definitely could provide some option to "assign" a tool window to another DockSite via a context menu item, like I suggested before. It takes away the drag/drop aspect of things like you thought but would let you at least get it over to the second DockSite and drag/drop it from there.

6) That's a great idea... I've just added an option for it for document windows. One question, how would you like to be notified of title changes? Just a general title change event or do you need specific events for in-place editing so that you can cancel changes, etc.?

The next build now has an option for showing document tabs at the bottom instead of the top.

Your new build looks very promising. I will test it tomorrow.

4)
Since I do control when the user selects another Desktop, I could simply remove the floating views from the current DockSite ("Desktop 1") and add it to the DockSite of "Desktop 2" when the tab is selected. Doing this for all floating ToolWindows on all "OnTabActivated" could be an option. The user should not notice any difference since only one Desktop is visible at any time.

6)
My current need would be well covered with an "OnTitleChanged" event. If you could support cancelling an edit using the Esc key (or something), it would suffice.

Truls Gartland

6) We've added DockingWindow.TitleChanging and TitleChanged events (that bubble) for the next beta build.

Also Esc does cancel entry.

[Modified at 06/16/2008 01:27 PM]

This is going great!

4)
I tried trapping the WindowActivated and WindowDeactivated events on the root DockSite for the TDI (my 'Desktop' container) to test whether moving (remove + add) the Floating/Undocked ToolWindows from the deactivating DocumentWindow to the activating one. Activating "Desktop 2" using the mouse produced 3-4 sets of WindowDeactivated/WindowActivated events and the ToolWindows was lost. Do you have any suggestions as to whether my plan here might work at all or not (see my previous posts in this thread)?

6)
Excellent! I did test the Esc-key and it works.

7)
I added 2 DocumentWindows to my root TDI, closed both using the Close button on the right in the TabStrip. Even when using the Office2007Blue theme, the background after closing all document windows is Dark Grey. Is this intentional or should it follow the theme closer (white?)?

8)
A minor rendering bug when entering editing mode in a DocumentWindow Title and pressing Esc. A strange vertical line shows to the left in the client area. This occurs when there are child ToolWindows in the DocumentWindow.

Truls Gartland

4) Maybe you could make a simple sample showing what you have done so far and we can look at it to see if anything pops into our head on how to work around this.

7) Thanks, the next build will use the app workspace background colors that Office uses (for Office themes).

8) Thanks the auto-hide tabstrip was getting focus. This is fixed for the next build.

4)
I discovered a flaw in MY test-code that provoked the many sets of events. Now my code only receives a single set of WindowDeactivated/WindowActivated when selecting another desktop. I will continue work on the concept test for mutiple DockSite instances and moving ToolWindows between them.

7)
Great!

8)
Also great!

4)
I want to document that I got help for this from Actipro through e-mail. Great!

When removing a ToolWindow from one DockSite and adding it to another I use the ToolWindow.Dock(Position p) method to set the Undocked ToolWindow to a specific position on screen since if not using the Position override, I will get a random position. My goal is to place it at the same position as it was when part of the first DockSite. The problem however is that I can not seem to get the position values from it prior to removing it from the first DockSite. Window.Top returns NaN. Do you have any tips?

Truls Gartland

Correct right now there isn't anything that will tell you a general location. What would you like to see? Just a property telling the current side in general upon which the tool window is docked?

Ah, I may not have been too clear here.

What I am looking for is a Loction property (only a getter is required) for ToolWindow when it is Undocked, i.e. a Nullable<Point> UndockedPosition where there is only a value when the ToolWindow is undocked.

Truls Gartland

Hi Truls,

Just FYI, we've added support for linked DockSites, which will be included in the next maintenance release.

If you'd like access to a preview build to help us test prior to the next maintenance release, please email support with your request.