We’ve had a lot of requests lately for improved support when using any sort of interop control (generally WinForms-based) within our Docking & MDI for WPF product.  In should be noted that interop content may also include things like DirectX content, etc.

The main problem is this, WPF renders any interop content on top of WPF content on the same root window.  The issues are described lower down in this topic:

http://msdn.microsoft.com/en-us/library/ms742522.aspx

In addition to the content rendering issues in WPF, there are some focus handling issues when dealing with interop controls.

What are we doing about it?

We have begun moving forward with finding ways to work around the above issues.  Today I’d like to talk about a new workaround included in build 482 that was just released.

One major issue with Docking & MDI was that auto-hide flyouts would appear below interop content that was located in the MDI area.  I’m happy to say that we’ve come up with a new property on DockSite that helps with this particular issue.

By setting the new DockSite.UseHostedAutoHidePopups property to false, you can now achieve auto-hide flyouts that appear above interop content.  In the screenshot above, you’ll notice a WPF tool window flys out on top of documents that contain a SyntaxEditor for WinForms control instance and a WinForms WebBrowser control instance.

We recommend that if you do not host WinForms content in your documents, you should still keep DockSite.UseHostedAutoHidePopups its default value of true.

This was very tricky to implement and is a major step forward for the product!

Moving forward

We still have some more areas to work on.  It’s likely that the next area will be a workaround so that the dock guides (when dragging a window) will appear on top of interop content.  Stay tuned!

We had a customer write us the other day mentioning that ClearType was turning off when using our RibbonWindow class in Windows Vista with Aero enabled and was falling back to grayscale antialiasing. 

After a lot of debugging and searching, we found that the root of the problem was the use of Vista's Aero glass in the client area of a Window in WPF.  Basically if glass is disabled or not available (like in Windows XP), everything is fine and renders properly using ClearType.  However if you implement your WPF Window such that glass can enter the client area (like in our RibbonWindow or previously-posted GlassWindow that is soon to be released), ClearType will disable and grayscale antialiasing will be used instead.

We traced the line that causes the issue down to this one, which is necessary for any WPF Window to properly support Aero glass in its client area:

// Ensure the background of the composition target is transparent
HwndSource.FromHwnd(hwnd).CompositionTarget.BackgroundColor = Colors.Transparent;

Basically if the Colors.Transparent is set to the Window's composition target, ClearType becomes disabled.  If you don't set this however, then glass is not able to enter the client area of the Window.

Here is a great post by Dax Pandhi on how to enable Aero glass in WPF Windows.

In there you can see how the line of code above is used to notify Win32 to use a transparent background for the client area of the window.

After some more searching on Google, we found this post too which explains the issue a bit more:

Give me back my ClearType

That post shows some screenshots of the issue and is very helpful for telling what things will cause ClearType to disable.

I've posted a question about this issue in the Microsoft WPF forum and hopefully Microsoft will do something about this in the future.

This is an issue that a couple customers have run into and emailed us on, so we wanted to post more about it. 

Scenario

The scenario is that you drag a Ribbon onto a Window and everything shows up fine at design-time.    But when you go to run your application, you see a blank Window.

Why Did It Disappear?

What happened was that you probably clicked and dragged something somewhere in the Visual Studio designer that either:

• Set the Width or Height of the Ribbon to an explicit size (very bad)
• Set the Margin around the Ribbon to something that forces it to have a smaller than desired size
• Did the above things to a direct container of Ribbon that affects its size

At run-time a feature of Ribbon is to collapses when there is not enough space for it.  You have full control over the threshold size at which this collapse occurs.  But one of the items in the list above would have caused this collapse code to kick in because the Ribbon is being forced smaller than desired.

Resolution

To fix this problem, simply look at the XAML for your Ribbon tag and remove any Width/Height property settings.  Also check to ensure that a Margin isn't set that could be causing this.  Then run your application and everything should appear like you would expect since now the Ribbon is not being forced to a small size.

Why Does It Show at Design-Time?

In the designer we force Ribbon to stay expanded and ignore its normal run-time collapse behavior.  This is done so that you can properly visually design the Ribbon.

Further Reading

We also have a section explaining this issue in the Ribbon control's Troubleshooting topic in the product documentation.