Is WindowsFormsHost fit for purpose (.net WPF hosting WinForms)?

Question

A GUI driven application needs to host some prebuilt WinForms based components. These components provide high performance interactive views using a mixture of GDI+ and DirectX. The views handle control input and display custom graphical renderings. The components are tested in a WinForms harness by the supplier.

Can a commericial application use WPF for its GUI and rely on WindowsFormsHost to host the WinForms components or have you experience of technical glitches e.g. input lags, update issues that would make you cautious?

Answer 1

I hosted WPF controls in WinForms and vice versa without problems. Though, I would test such scenarios extensively 'cause it's hard to predict how complex control will behave.

Answer 2

Do note the absence of a WPF Application object when hosting in Winforms. This can result in problems if you're taking an existing WPF component and hosting it in Winforms, since resource lookups and the likes will never look in application scope. You can create your own Application object if it is a problem.

Answer 3

We're currently using WindowsFormsHost in our software to host the WinForms DataGridView control, and we've not had any real problems with it. A few things to watch out for though:

The first is the air-space restrictions. Practically speaking, this means that WinForms content always appears on top of WPF content. So if you are using WPF adorners they will appear to be "trimmed" if they hit up against a WinForms region in your app.

The second is that, because they use Windows resources, you have to manage the lifetimes of WinForms components more carefully. Unlike WPF components, WinForms controls expect to be Disposed when they're finished with. This makes it tricky to include them in a pure XAML view.

The last thing is that WinForms controls don't seem to resize as smoothly as the rest of the WPF display: they tend to snap to their new size once you've finished making an adjustment.

Answer 4

As @Kent Boogaart mentioned, I've run into the situation where a WPF application hosted in WinForms doesn't have the WPF Application object (i.e. Application.Current). This can cause many issues such as Dispatchers not invoking threads back to the UI thread. This would only apply if you're hosting in WinForms, not the other way around.

I've also had strange issues with modal dialogs behaving strangely (i.e. ShowModal calls). I'm assuming this is because, in WinForms, each control has its own Win32 handle while in WPF, there is only one handle for the entire Window.

Whatever you do, test :)

Answer 5

You can solve the Airspace problem by using .net 3.5 SP1:

These types of airspace restrictions represent a huge limitation in a framework, like WPF, where element composition is used to create very rich user experiences. With a D3DImage solution, these restrictions are no longer present!

See Introduction to D3DImage.

Answer 6

One problem I've run into is that embedded Win Forms controls do not participate in any transform operations applied to their WPF container. This results in visual flashing effects and the embedded control appearing in an innappropriate location. I worked around this by binding the visibility of the Windows Forms Host to the animation state of its WPF container, so that the embedded control was hidden until the animation completed, like below.

<WindowsFormsHost Grid.Row="1" Grid.Column="1" Margin="8,0,0,0"
     Visibility="{Binding ActualHeight, RelativeSource={RelativeSource
     Mode=FindAncestor, AncestorType=UserControl},
     Converter={StaticResource WinFormsControlVisibilityConverter}}" >

     <winforms:DateTimePicker x:Name="datepickerOrderExpected" Width="140"
        Format="Custom" CustomFormat="M/dd/yy  h:mm tt"
        ValueChanged="OnEditDateTimeOrderExpected" />

</WindowsFormsHost>

Answer 7

http://dotnetways.blogspot.com/2010/10/host-wpf-controls-in-windows-forms.html