Troubleshooting Hybrid Applications
This topic lists some common problems that can occur when authoring hybrid applications which use both WPF and Windows Forms technologies.
Overlapping Controls
Controls may not overlap as you would expect. Windows Forms uses a separate HWND for each control. WPF uses one HWND for all content on a page. This implementation difference causes unexpected overlapping behaviors.
A Windows Forms control hosted in WPF always appears on top of the WPF content.
WPF content hosted in an ElementHost control appears at the z-order of the ElementHost control. It is possible to overlap ElementHost controls, but the hosted WPF content does not combine or interact.
Child Property
The WindowsFormsHost and ElementHost classes can host only a single child control or element. To host more than one control or element, you must use a container as the child content. For example, you could add Windows Forms button and check box controls to a System.Windows.Forms.Panel control, and then assign the panel to a WindowsFormsHost control's Child property. However, you cannot add the button and check box controls separately to the same WindowsFormsHost control.
Scaling
WPF and Windows Forms have different scaling models. Some WPF scaling transformations are meaningful to Windows Forms controls, but others are not. For example, scaling a Windows Forms control to 0 will work, but if you try to scale the same control back to a non-zero value, the control's size remains 0. For more information, see Layout Considerations for the WindowsFormsHost Element.
Adapter
There may be confusion when working the WindowsFormsHost and ElementHost classes, because they include a hidden container. Both the WindowsFormsHost and ElementHost classes have a hidden container, called an adapter, which they use to host content. For the WindowsFormsHost element, the adapter derives from the System.Windows.Forms.ContainerControl class. For the ElementHost control, the adapter derives from the DockPanel element. When you see references to the adapter in other interoperation topics, this container is what is being discussed.
Nesting
Nesting a WindowsFormsHost element inside an ElementHost control is not supported. Nesting an ElementHost control inside a WindowsFormsHost element is also not supported.
Focus
Focus works differently in WPF and Windows Forms, which means that focus issues may occur in a hybrid application. For example, if you have focus inside a WindowsFormsHost element, and you either minimize and restore the page or show a modal dialog box, focus inside the WindowsFormsHost element may be lost. The WindowsFormsHost element still has focus, but the control inside it may not.
Data validation is also affected by focus. Validation works in a WindowsFormsHost element, but it does not work as you tab out of the WindowsFormsHost element, or between two different WindowsFormsHost elements.
Property Mapping
Some property mappings require extensive interpretation to bridge dissimilar implementations between the WPF and Windows Forms technologies. Property mappings enable your code to react to changes in fonts, colors, and other properties. In general, property mappings work by listening for either PropertyChanged events or OnPropertyChanged calls, and setting appropriate properties on either the child control or its adapter. For more information, see Windows Forms and WPF Property Mapping.
Layout-related Properties on Hosted Content
When the System.Windows.Forms.Integration.WindowsFormsHost.Child or System.Windows.Forms.Integration.ElementHost.Child property is assigned, several layout-related properties on the hosted content are set automatically. Changing these content properties can cause unexpected layout behaviors.
Your hosted content is docked to fill the WindowsFormsHost and ElementHost parent. To enable this fill behavior, several properties are set when you set the child property. The following table lists which content properties are set by the ElementHost and WindowsFormsHost classes.
| Host Class | Content Properties |
|---|---|
ElementHost |
|
WindowsFormsHost |
Do not set these properties directly on the hosted content. For more information, see Layout Considerations for the WindowsFormsHost Element.
Navigation Applications
Navigation applications may not maintain user state. The WindowsFormsHost element recreates its controls when it is used in a navigation application. Recreating child controls occurs when the user navigates away from the page hosting the WindowsFormsHost element and then returns to it. Any content that has been typed in by the user will be lost.
Message Loop Interoperation
When working with Windows Forms message loops, messages may not be processed as expected. The EnableWindowsFormsInterop method is called by the WindowsFormsHost constructor. This method adds a message filter to the WPF message loop. This filter calls the System.Windows.Forms.Control.PreProcessMessage(System.Windows.Forms.Message) method if a System.Windows.Forms.Control was the target of the message and translates/dispatches the message.
If you show a Window in a Windows Forms message loop with System.Windows.Forms.Application.Run, you cannot type anything unless you call the EnableModelessKeyboardInterop method. The EnableModelessKeyboardInterop method takes a Window and adds an System.Windows.Forms.IMessageFilter which re-routes key-related messages to the WPF message loop. For more information, see Windows Forms and WPF Interoperability Input Architecture.
Opacity and Layering
The HwndHost class does not support layering. This means that setting the Opacity property on the WindowsFormsHost element has no effect, and no blending will occur with other WPF windows which have AllowsTransparency set to true.
Dispose
Not disposing classes properly can leak resources. In your hybrid applications, make sure that the WindowsFormsHost and ElementHost classes are disposed, or you could leak resources. Windows Forms disposes ElementHost controls when its non-modal Form parent closes. WPF disposes WindowsFormsHost elements when your application shuts down. It is possible to show a WindowsFormsHost element in a Window in a Windows Forms message loop. In this case, your code may not receive notification that your application is shutting down.
Enabling Visual Styles
Microsoft Windows XP visual styles on a Windows Forms control may not be enabled. The System.Windows.Forms.Application.EnableVisualStyles method is called in the template for a Windows Forms application. Although this method is not called by default, if you use Visual Studio to create a project, you will get Microsoft Windows XP visual styles for controls, if version 6.0 of Comctl32.dll is available. You must call the EnableVisualStyles method before handles are created on the thread. For more information, see How to: Enable Visual Styles in a Hybrid Application.
Licensed Controls
Licensed Windows Forms controls that display licensing information in a message box to the user might cause unexpected behavior for a hybrid application. Some licensed controls show a dialog box in response to handle creation. For example, a licensed control might inform the user that a license is required, or that the user has three remaining trial uses of the control.
The WindowsFormsHost element derives from the HwndHost class, and the child control’s handle is created inside the BuildWindowCore method. The HwndHost class does not allow messages to be processed in the BuildWindowCore method, but displaying a dialog box causes messages to be sent. To enable this licensing scenario, call the System.Windows.Forms.Control.CreateControl method on the control before assigning it as the WindowsFormsHost element's child.
See Also
Tasks
How to: Enable Visual Styles in a Hybrid Application
Reference
Concepts
Windows Forms and WPF Interoperability Input Architecture
Layout Considerations for the WindowsFormsHost Element
Windows Forms and WPF Property Mapping