In the upcoming release of WPF Studio we've made several enhancements to our Docking & MDI product's support for interop support, further improving its capabilities of hosting content like Windows Forms controls within tool and document windows.
Auto-Hide Popups
Background
In previous versions, interop content was effectively restricted to tabbed MDI documents or permanently pinned tool windows. So if you needed to include interop content in a tool window, you had to disable the auto-hide (or pinning) feature for that window. This was due to a limitation with how our auto-hide popups were implemented.
Two types of auto-hide popups are supported. The first, and default, uses the WPF adorner layers to display the auto-hidden tool windows. This allows us to implement the snazzy WPF effects and animations, such as sliding and fading. The second type used a transparent WPF Popup to display the auto-hidden tool windows. Since the WPF Popup uses a Win32 HWND internally, any WPF content inside the Popup would appear on top of any interop content below it.
The type of auto-hide popup is controlled by the DockSite.UseAutoHideHostedPopups property. The first type described above, is considered "hosted" as it is considered a child of the DockSite. So by setting UseAutoHideHostedPopups to false, you could include any interop content in the tabbed MDI documents or tool windows that would never be auto-hidden.
Problems
Interop content doesn't play nice, if at all, with the effects and animations used with the hosted auto-hide popups. The interop content would end up appearing in the incorrect spot and/or covering some WPF content it shouldn't be. In addition, if any interop content was included in the DockSite below the hosted popup, it would appear on top of the titlebar and borders of the hosted auto-hide popups.
Non-hosted popups had several problems of it's own. Because interop content cannot be displayed on transparent windows (or popups), it could not be displayed in non-hosted auto-hide popups either. In addition, WPF Popups include internal "repositioning" code to prevent it from falling off-screen. So in cases where the application may be half on one screen and half on another, the Popup used may move by itself. There is currently no way to turn this repositioning code off.
Finally, the non-hosted auto-hide popups had a nasty habit of appearing on top of windows belonging to other applications. This was due to the fact that Popups are set to be "top-most". This meant they would appear on top of any window running on the system, until closed. Our answer at the time was to close the Popup when the main window was deactivated, but this had it's own drawbacks.
Solution
Our solution to these issues was to use a custom Window to present our auto-hide popups when UseAutoHideHostedPopups is set to false. This allowed us to precisely position the Window, without fear that it would reposition itself. We could also configure the auto-hide Window to be owned by the Window hosting the DockSite. This meant that when the main Window was deactivated, the auto-hide Window would fall behind any other application windows just as you'd expect.
The image above shows an interop WebBrowser control in a non-hosted auto-hide popup, but you'll really need to see it in action.
Dock Guides and Previews
Background
The dock guides are the glyphs you see when dragging windows around the DockSite with the mouse, which indicate possible drop locations. The dock previews show a blue transparent rectangle, which gives you a relative idea of where the window will locations if dropped at the currently location.
The dock guides and previews used to leverage the same DockSite.UseAutoHideHostedPopups property as above. So just like auto-hide popups, there were hosted dock guides/previews and non-hosted versions as well.
Problems
The hosted dock guides/previews work fine in most cases, but obviously cannot appear on top of interop content as they are WPF content hosted in an adorner layer. In addition, any floating windows (such as documents or tool windows) would obscure their use. In the screenshot below, you can see that the dock guides/previews are in fact there and working, but appear below the floating window.
Non-hosted dock guides/previews would appear on top of floating windows, but suffered from the same "repositioning" issues as the non-hosted popups. So if the dock guides/previews had to span two monitors, then they would either not appear or appear in the wrong position.
Solution
First, we add a new DockSite.UseHostedDockGuides option, so the dock guides/previews could be configured independently of the auto-hide popups. Like with the auto-hide popups, we leveraged a custom Window to present the dock guides/previews when UseHostedDockGuides is set to false (which is the default value for full trust applications).
Some of our users prefer to not have the floating windows owned by the DockSite's hosting Window. This allows the main Window to be minimized and allow the floating windows to remain visible. In addition, unowned windows can be optionally shown in the task bar. Because of this, we added additional code to ensure that the dock guides would appear on top the unowned floating window. This code only kicks in when needed, but provides a better experience for all.
Summary
These changes put our interop support on par with Visual Studio 2010's docking framework and we can't wait to get it out the door. Keep any eye out for additional blog posts as we get ready for our next maintenance release.