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:
|
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.
|