Improved Docking/MDI for WPF WinForms compatibility

January 13, 2009 at 6:13 PM

In a December blog post titled Docking & MDI for WPF – Improving WinForms interop, I discussed some of the problems with WPF in general and WinForms interop, where interop content is rendered on top of any WPF content in the same root Window.

A number of our Docking & MDI for WPF customers are using WinForms controls in their MDI area and ran into the issue where auto-hide flyouts and dock guides would render below the WinForms content. Obviously that’s not good.

There is no easy way to fix the issue since it is a low-level WPF issue, however we have come up with design changes that sufficiently work around the problems. Back in December, a WPF Studio maintenance release resolved the issue where auto-hide flyouts would appear below interop content in the MDI area, via a new optional property setting.

Docking & MDI for WPF showing how recent code changes allow dock guides and drop targets to appear above WinForms controls in the MDI area

Today I’m happy to announce that WPF Studio build 4.5.0484 resolves the other main issue, which is dock guides appearing below interop content. Here is a screenshot taken today showing how dock guides and drop targets now appear above interop content, in this case a SyntaxEditor for WinForms control.

Grab the latest WPF Studio maintenance release to get this update.

Tags: wpf, docking

Filed under: Actipro, WPF, New features

February 15, 2009 at 13:24

Great Job!

Would it also be possible to use the same trick to draw a splitter line over the Win32 content? Currently when Win32 windows are hosted in the AcriPro docking and the user wants to resize the docking windows using the splitter, the splitter line is drawn below the Win32 windows...

Thanks,
Andrey.

Andrey

February 15, 2009 at 18:31

Hi Andrey,

Thanks for writing. We do have that last item on our TODO list in regards to interop compatibility.

Bill Henning (Actipro)

February 15, 2009 at 23:47

Hi Bill,

Thanks for quick Answer

Is there any rough time estimate for the release with this issue fixed? For us the transition from WinForms to WPF will take years so the solid interop is #1 priority.

Thanks,
Andrey.

February 16, 2009 at 04:51

I don't have a time estimate but it is one of the top 3 things on our Docking TODO list though.

February 16, 2009 at 09:57

Good to know. Thanks!

July 6, 2009 at 22:29

Hi. I am trying the evaluation release, and I have noticed I have a similar problem when showing the document windows in the standard MDI way (instead of the tabbed MDI). In that case, the winform content is always shown on the top, no matter if the containing window is below other mdi windows.
Not only, in that mode, the winform content is shown on top of everything else, even the toolboxes.

Any help ?

Thanks
Franco

Franco Andrea

July 6, 2009 at 22:39

Franco, the problem is an issue with WPF in general. Any WinForms or other interop content hosted in WPF will always have a z-order higher than any WPF content in the same root Window or Popup. Therefore standard MDI cannot be used when hosting interop content. Tabbed MDI doesn't allow overlapping of content though so it can be used properly with interop content.

March 25, 2010 at 15:23

My project requires that WPF forms and Winforms co-exist in the same MDI. Is that possible in your product?

dhaval

March 25, 2010 at 18:53

Yes, you can have WPF and WinForms content in tabbed MDI mode but not standard MDI mode due to WPF airspace limitations imposed by Microsoft's design of WPF.

The Actipro Blog

Twitter Feed

Month List

About Us