Edit

Share via

WPF and Windows Forms Interoperation

  • Article

WPF and Windows Forms present two different architectures for creating application interfaces. The System.Windows.Forms.Integration namespace provides classes that enable common interoperation scenarios. The two key classes that implement interoperation capabilities are WindowsFormsHost and ElementHost. This topic describes which interoperation scenarios are supported and which scenarios are not supported.

Note

Special consideration is given to the hybrid control scenario. A hybrid control has a control from one technology nested in a control from the other technology. This is also called a nested interoperation. A multilevel hybrid control has more than one level of hybrid control nesting. An example of a multilevel nested interoperation is a Windows Forms control that contains a WPF control, which contains another Windows Forms control. Multilevel hybrid controls are not supported.

Hosting Windows Forms Controls in WPF

The following interoperation scenarios are supported when a WPF control hosts a Windows Forms control:

  • The WPF control may host one or more Windows Forms controls using XAML.

  • It may host one or more Windows Forms controls using code.

  • It may host Windows Forms container controls that contain other Windows Forms controls.

  • It may host a master/detail form with a WPF master and Windows Forms details.

  • It may host a master/detail form with a Windows Forms master and WPF details.

  • It may host one or more ActiveX controls.

  • It may host one or more composite controls.

  • It may host hybrid controls using Extensible Application Markup Language (XAML).

  • It may host hybrid controls using code.

Layout Support

The following list describes the known limitations when the WindowsFormsHost element attempts to integrate its hosted Windows Forms control into the WPF layout system.

  • In some cases, Windows Forms controls cannot be resized, or can be sized only to specific dimensions. For example, a Windows Forms ComboBox control supports only a single height, which is defined by the control's font size. In a WPF dynamic layout, which assumes that elements can stretch vertically, a hosted ComboBox control will not stretch as expected.

  • Windows Forms controls cannot be rotated or skewed. For example, when you rotate your user interface by 90 degrees, hosted Windows Forms controls will maintain their upright position.

  • In most cases, Windows Forms controls do not support proportional scaling. Although the overall dimensions of the control will scale, child controls and component elements of the control may not resize as expected. This limitation depends on how well each Windows Forms control supports scaling.

  • In a WPF user interface, you can change the z-order of elements to control overlapping behavior. A hosted Windows Forms control is drawn in a separate HWND, so it is always drawn on top of WPF elements.

  • Windows Forms controls support autoscaling based on the font size. In a WPF user interface, changing the font size does not resize the entire layout, although individual elements may dynamically resize.

Ambient Properties

Some of the ambient properties of WPF controls have Windows Forms equivalents. These ambient properties are propagated to the hosted Windows Forms controls and exposed as public properties on the WindowsFormsHost control. The WindowsFormsHost control translates each WPF ambient property into its Windows Forms equivalent.

For more information, see Windows Forms and WPF Property Mapping.

Behavior

The following table describes interoperation behavior.

Behavior Supported Not supported
Transparency Windows Forms control rendering supports transparency. The background of the parent WPF control can become the background of hosted Windows Forms controls. Some Windows Forms controls do not support transparency. For example, the TextBox and ComboBox controls will not be transparent when hosted by WPF.
Tabbing Tab order for hosted Windows Forms controls is the same as when those controls are hosted in a Windows Forms-based application.

Tabbing from a WPF control to a Windows Forms control with the TAB key and SHIFT+TAB keys works as usual.

Windows Forms controls that have a TabStop property value of false do not receive focus when the user tabs through controls.

- Each WindowsFormsHost control has a TabIndex value, which determines when that WindowsFormsHost control will receive focus.
- Windows Forms controls that are contained inside a WindowsFormsHost container follow the order specified by the TabIndex property. Tabbing from the last tab index puts focus on the next WPF control, if one exists. If no other focusable WPF control exists, tabbing returns to the first Windows Forms control in the tab order.
- TabIndex values for controls inside the WindowsFormsHost are relative to sibling Windows Forms controls that are contained in the WindowsFormsHost control.
- Tabbing honors control-specific behavior. For example, pressing the TAB key in a TextBox control that has a AcceptsTab property value of true enters a tab in the text box instead of moving the focus.		 Not applicable.
Navigation with arrow keys - Navigation with arrow keys in the WindowsFormsHost control is the same as in an ordinary Windows Forms container control: The UP ARROW and LEFT ARROW keys select the previous control, and the DOWN ARROW and RIGHT ARROW keys select the next control.
- The UP ARROW and LEFT ARROW keys from the first control that is contained in the WindowsFormsHost control perform the same action as the SHIFT+TAB keyboard shortcut. If there is a focusable WPF control, focus moves outside the WindowsFormsHost control. This behavior differs from the standard ContainerControl behavior in that no wrapping to the last control occurs. If no other focusable WPF control exists, focus returns to the last Windows Forms control in the tab order.
- The DOWN ARROW and RIGHT ARROW keys from the last control that is contained in the WindowsFormsHost control perform the same action as the TAB key. If there is a focusable WPF control, focus moves outside the WindowsFormsHost control. This behavior differs from the standard ContainerControl behavior in that no wrapping to the first control occurs. If no other focusable WPF control exists, focus returns to the first Windows Forms control in the tab order.		 Not applicable.
Accelerators Accelerators work as usual, except where noted in the "Not supported" column. Duplicate accelerators across technologies do not work like ordinary duplicate accelerators. When an accelerator is duplicated across technologies, with at least one on a Windows Forms control and the other on a WPF control, the Windows Forms control always receives the accelerator. Focus does not toggle between the controls when the duplicate accelerator is pressed.
Shortcut keys Shortcut keys work as usual, except where noted in the "Not supported" column. - Windows Forms shortcut keys that are handled at the preprocessing stage always take precedence over WPF shortcut keys. For example, if you have a ToolStrip control with CTRL+S shortcut keys defined, and there is a WPF command bound to CTRL+S, the ToolStrip control handler is always invoked first, regardless of focus.
- Windows Forms shortcut keys that are handled by the KeyDown event are processed last in WPF. You can prevent this behavior by overriding the Windows Forms control's IsInputKey method or handling the PreviewKeyDown event. Return true from the IsInputKey method, or set the value of the PreviewKeyDownEventArgs.IsInputKey property to true in your PreviewKeyDown event handler.
AcceptsReturn, AcceptsTab, and other control-specific behavior Properties that change the default keyboard behavior work as usual, assuming that the Windows Forms control overrides the IsInputKey method to return true. Windows Forms controls that change default keyboard behavior by handling the KeyDown event are processed last in the host WPF control. Because these controls are processed last, they can produce unexpected behavior.
Enter and Leave Events When focus is not going to the containing ElementHost control, the Enter and Leave events are raised as usual when focus changes in a single WindowsFormsHost control. Enter and Leave events are not raised when the following focus changes occur:

- From inside to outside a WindowsFormsHost control.
- From outside to inside a WindowsFormsHost control.
- Outside a WindowsFormsHost control.
- From a Windows Forms control hosted in a WindowsFormsHost control to an ElementHost control hosted inside the same WindowsFormsHost.
Multithreading All varieties of multithreading are supported. Both the Windows Forms and WPF technologies assume a single-threaded concurrency model. During debugging, calls to framework objects from other threads will raise an exception to enforce this requirement.
Security All interoperation scenarios require full trust. No interoperation scenarios are allowed in partial trust.
Accessibility All accessibility scenarios are supported. Assistive technology products function correctly when they are used for hybrid applications that contain both Windows Forms and WPF controls. Not applicable.
Clipboard All Clipboard operations work as usual. This includes cutting and pasting between Windows Forms and WPF controls. Not applicable.
Drag-and-drop feature All drag-and-drop operations work as usual. This includes operations between Windows Forms and WPF controls. Not applicable.

Hosting WPF Controls in Windows Forms

The following interoperation scenarios are supported when a Windows Forms control hosts a WPF control:

  • Hosting one or more WPF controls using code.

  • Associating a property sheet with one or more hosted WPF controls.

  • Hosting one or more WPF pages in a form.

  • Starting a WPF window.

  • Hosting a master/detail form with a Windows Forms master and WPF details.

  • Hosting a master/detail form with a WPF master and Windows Forms details.

  • Hosting custom WPF controls.

  • Hosting hybrid controls.

Ambient Properties

Some of the ambient properties of Windows Forms controls have WPF equivalents. These ambient properties are propagated to the hosted WPF controls and exposed as public properties on the ElementHost control. The ElementHost control translates each Windows Forms ambient property to its WPF equivalent.

For more information, see Windows Forms and WPF Property Mapping.

Behavior

The following table describes interoperation behavior.

Behavior Supported Not supported
Transparency WPF control rendering supports transparency. The background of the parent Windows Forms control can become the background of hosted WPF controls. Not applicable.
Multithreading All varieties of multithreading are supported. Both the Windows Forms and WPF technologies assume a single-threaded concurrency model. During debugging, calls to framework objects from other threads will raise an exception to enforce this requirement.
Security All interoperation scenarios require full trust. No interoperation scenarios are allowed in partial trust.
Accessibility All accessibility scenarios are supported. Assistive technology products function correctly when they are used for hybrid applications that contain both Windows Forms and WPF controls. Not applicable.
Clipboard All Clipboard operations work as usual. This includes cutting and pasting between Windows Forms and WPF controls. Not applicable.
Drag-and-drop feature All drag-and-drop operations work as usual. This includes operations between Windows Forms and WPF controls. Not applicable.

See also