Compartilhar via


WPF e a interoperação de formulários do Windows

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.

Observação

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.

Este tópico contém as seguintes seções.

  • Hospedagem de controles do Windows Forms no WPF
  • Hospedagem de controles do WPF no Windows Forms
  • Tópicos relacionados

Hospedagem de controles do Windows Forms no 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. Por exemplo, um Windows Forms ComboBox controle suporta apenas uma altura única, que é definida pelo tamanho de fonte. do controle 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 Formulários do Windows e mapeamento de propriedades do WPF.

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

  • Teclas de navegação com seta na WindowsFormsHost controle é o mesmo um comum Windows Forms o controle de recipiente: As teclas de seta para a esquerda e de seta para cima selecione o controle anterior e as teclas de seta para baixo e seta para selecionar o próximo controle.

  • As teclas de seta para cima e seta para a esquerda do primeiro controle que está contido no WindowsFormsHost controle executar a mesma ação que o atalho de teclado SHIFT + TAB. 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. Se nenhum outro focalizável WPF controle existe, o foco retorna para a última Windows Forms controle na ordem de guia.

  • As teclas de seta para baixo e seta para a direita a partir do último controle que está contido no WindowsFormsHost controle executar a mesma ação que a chave do guia. 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. Por exemplo, se você tiver um ToolStrip controlar com teclas de atalho CTRL + S definidas e não há um WPF comando vinculado a CTRL + S, o ToolStrip o manipulador de controle sempre é invocado pela primeira vez, independentemente do foco.

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

Hospedagem de controles do WPF no 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 Formulários do Windows e mapeamento de propriedades do WPF.

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.

Consulte também

Tarefas

Demonstra Passo a passo: Hospedando um controle Windows Forms no WPF

Referência

ElementHost

WindowsFormsHost

Conceitos

Demonstra Passo a passo: Hospedando um controle Windows Forms composto no WPF

Demonstra Passo a passo: Hospedando um controle composto do WPF no Windows Forms

Formulários do Windows e mapeamento de propriedades do WPF