Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
WPF y Windows Forms presentan dos arquitecturas diferentes para crear interfaces de aplicación. El System.Windows.Forms.Integration espacio de nombres proporciona clases que permiten escenarios comunes de interoperación. Las dos clases clave que implementan las funcionalidades de interoperación son WindowsFormsHost y ElementHost. En este tema se describen qué escenarios de interoperación se admiten y qué escenarios no se admiten.
Nota:
Se da una consideración especial al escenario de control híbrido. Un control híbrido tiene un control de una tecnología anidada en un control de la otra tecnología. Esto también se denomina interoperación anidada. Un control híbrido multinivel tiene más de un nivel de anidamiento. Un ejemplo de interoperación multinivel anidada es un control de Windows Forms que contiene un control de WPF, el cual contiene otro control de Windows Forms. No se admiten controles híbridos de varios niveles.
Hospedaje de controles de Formularios Windows Forms en WPF
Se admiten los siguientes escenarios de interoperación cuando un control WPF hospeda un control de Windows Forms:
El control WPF puede hospedar uno o varios controles de Windows Forms mediante XAML.
Puede hospedar uno o varios controles de Windows Forms mediante código.
Puede hospedar controles de contenedor de Windows Forms que contengan otros controles de Windows Forms.
Puede hospedar un formulario maestro/detalle con WPF como maestro y Windows Forms como detalle.
Puede hospedar un formulario maestro o detalle con un patrón de Windows Forms y detalles de WPF.
Puede hospedar uno o varios controles ActiveX.
Puede hospedar uno o varios controles compuestos.
Puede hospedar controles híbridos mediante el lenguaje de marcado extensible de aplicaciones (XAML).
Puede hospedar controles híbridos mediante código.
Compatibilidad con el diseño
En la lista siguiente se describen las limitaciones conocidas cuando el WindowsFormsHost elemento intenta integrar su control hospedado de Windows Forms en el sistema de diseño WPF.
En algunos casos, los controles de Windows Forms no se pueden cambiar de tamaño o solo se pueden ajustar a dimensiones específicas. Por ejemplo, un control de Windows Forms ComboBox solo admite un alto único, que se define mediante el tamaño de fuente del control. En un diseño dinámico de WPF, que supone que los elementos se pueden estirar verticalmente, un control hospedado ComboBox no se estirará según lo previsto.
Los controles de Windows Forms no se pueden girar ni sesgar. Por ejemplo, al girar la interfaz de usuario en 90 grados, los controles hospedados de Windows Forms mantendrán su posición vertical.
En la mayoría de los casos, los controles de Windows Forms no admiten el escalado proporcional. Aunque las dimensiones generales del control se escalarán, es posible que los controles secundarios y los elementos que componen el control no se redimensionen según lo esperado. Esta limitación depende de qué tan bien sea compatible cada control de Windows Forms con el escalado.
En una interfaz de usuario de WPF, puede cambiar el orden z de los elementos para controlar el comportamiento superpuesto. Un control hospedado de Windows Forms se dibuja en un HWND independiente, por lo que siempre se dibuja por encima de los elementos WPF.
Los controles de Windows Forms admiten el escalado automático en función del tamaño de fuente. En una interfaz de usuario de WPF, cambiar el tamaño de fuente no cambia todo el diseño, aunque los elementos individuales pueden cambiar dinámicamente.
Propiedades ambientales
Algunas de las propiedades ambientales de los controles WPF tienen equivalentes de Windows Forms. Estas propiedades ambientales se propagan a los controles hospedados de Windows Forms y se exponen como propiedades públicas en el WindowsFormsHost control. El WindowsFormsHost control convierte cada propiedad ambiente de WPF en su equivalente de Windows Forms.
Para obtener más información, vea Asignación de propiedades de Windows Forms y WPF.
Comportamiento
En la tabla siguiente se describe el comportamiento de interoperación.
Comportamiento | Compatible | No está soportado |
---|---|---|
Transparencia | La representación de los controles de Windows Forms admite la transparencia. El fondo del control WPF primario puede convertirse en el fondo de los controles hospedados de Windows Forms. | Algunos controles de Windows Forms no admiten transparencia. Por ejemplo, los controles TextBox y ComboBox no serán transparentes cuando se alojen en un entorno WPF. |
Tabulación | El orden de tabulación de los controles hospedados de Windows Forms es el mismo que cuando esos controles se hospedan en una aplicación basada en Windows Forms. La tabulación desde un control WPF a un control de Windows Forms con la tecla TAB y las teclas MAYÚS+TAB funciona de manera habitual. Los controles de Windows Forms que tienen un TabStop valor de propiedad de false no reciben el foco cuando el usuario realiza tabulaciones a través de controles.- Cada WindowsFormsHost control tiene un TabIndex valor, que determina cuándo WindowsFormsHost ese control recibirá el foco. - Los controles de Windows Forms que se encuentran dentro de un WindowsFormsHost contenedor siguen el orden especificado por la TabIndex propiedad . La tabulación del último índice de tabulación coloca el foco en el siguiente control WPF, si hay alguno. Si no existe ningún otro control WPF con foco, el tabulador vuelve al primer control de Windows Forms en el orden de tabulación. - TabIndex Los valores para los controles dentro del WindowsFormsHost son relativos a los controles de Windows Forms del mismo nivel que se encuentran en el control WindowsFormsHost. - La tabulación respeta el comportamiento específico del control. Por ejemplo, al presionar la tecla TAB en un TextBox control que tiene un AcceptsTab valor de propiedad de true , se inserta un tabulador en el cuadro de texto en lugar de mover el foco. |
No aplicable. |
Navegación con teclas de dirección | - La navegación con teclas de dirección en el WindowsFormsHost control es la misma que en un control de contenedor normal de Windows Forms: las teclas FLECHA ARRIBA y FLECHA IZQUIERDA seleccionan el control anterior, y las teclas FLECHA ABAJO y FLECHA DERECHA seleccionan el siguiente control. - Las teclas de flecha arriba y flecha izquierda del primer control que se encuentra en el control WindowsFormsHost realizan la misma acción que la tecla de acceso directo MAYÚS+TAB. Si hay un control WPF enfocable, el foco se mueve fuera del control WindowsFormsHost. Este comportamiento difiere del comportamiento estándar ContainerControl en que no se produce ningún encapsulamiento al último control. Si no existe ningún otro control WPF con foco, el foco vuelve al último control de Windows Forms en el orden de tabulación. - Las teclas FLECHA ABAJO y FLECHA DERECHA del último control contenido en el control WindowsFormsHost realizan la misma acción que la tecla TAB. Si hay un control WPF enfocable, el foco se mueve fuera del control WindowsFormsHost. Este comportamiento difiere del comportamiento estándar ContainerControl ya que no se enlaza al primer control. Si no existe ningún otro control WPF con foco, el foco vuelve al primer control de Windows Forms en el orden de tabulación. |
No aplicable. |
Aceleradores | Los aceleradores funcionan como de costumbre, excepto cuando se indique en la columna "No compatible". | Los aceleradores duplicados entre tecnologías no funcionan como los aceleradores duplicados normales. Cuando un acelerador se duplica en diferentes tecnologías, con al menos uno en un control de Windows Forms y otro en un control WPF, el control de Windows Forms siempre recibe el acelerador. El foco no alterna entre los controles cuando se presiona el acelerador duplicado. |
Atajos de teclado | Las teclas de acceso directo funcionan como de costumbre, excepto cuando se indique en la columna "No compatibles". | - Las teclas de acceso rápido de Windows Forms, gestionadas en la fase de preprocesamiento, siempre tienen prioridad sobre las teclas de acceso rápido de WPF. Por ejemplo, si tiene un ToolStrip control con teclas de método abreviado CTRL+S definidas y hay un comando WPF enlazado a CTRL+S, el ToolStrip controlador de control siempre se invoca primero, independientemente del foco. - Las teclas de método abreviado de Windows Forms que el evento KeyDown controla se procesan por último en WPF. Puede evitar este comportamiento invalidando el método del IsInputKey control de Windows Forms o controlando el PreviewKeyDown evento. Devuelve true desde el método IsInputKey o establece el valor de la propiedad PreviewKeyDownEventArgs.IsInputKey a true en el controlador de eventos PreviewKeyDown. |
AcceptsReturn, AcceptsTab y otros comportamientos específicos del control | Las propiedades que cambian el comportamiento predeterminado del teclado funcionan como de costumbre, suponiendo que el control de Windows Forms invalide el IsInputKey método para devolver true . |
Los controles de Windows Forms que cambian el comportamiento predeterminado del teclado mediante el control del KeyDown evento se procesan por última vez en el control WPF del host. Dado que estos controles se procesan por última vez, pueden producir un comportamiento inesperado. |
Entrar y salir de los eventos | Cuando el foco no va al control contenedor ElementHost , los eventos Enter y Leave se generan como de costumbre cuando cambia el foco en un solo WindowsFormsHost control. | Los eventos Enter y Leave no se generan cuando se producen los siguientes cambios de foco: - Desde dentro hasta fuera de un WindowsFormsHost control. - Desde el exterior hacia el interior de un WindowsFormsHost control. - Fuera de un WindowsFormsHost control. - Desde un control de Windows Forms hospedado en un WindowsFormsHost control a un ElementHost control hospedado dentro del mismo WindowsFormsHost. |
Subprocesamiento múltiple | Se admiten todas las variedades de multithreading. | Tanto las tecnologías de Windows Forms como WPF asumen un modelo de simultaneidad uniproceso. Durante la depuración, las llamadas a objetos del framework desde otros hilos generarán una excepción para cumplir con este requisito. |
Seguridad | Todos los escenarios de interoperación requieren plena confianza. | No se permite ningún escenario de interoperación en confianza parcial. |
Accesibilidad | Se admiten todos los escenarios de accesibilidad. Los productos de tecnología de asistencia funcionan correctamente cuando se usan para aplicaciones híbridas que contienen controles de Windows Forms y WPF. | No aplicable. |
Portapapeles | Todas las operaciones del Portapapeles funcionan como de costumbre. Esto incluye cortar y pegar entre controles de Windows Forms y WPF. | No aplicable. |
Característica de arrastrar y colocar | Todas las operaciones de arrastrar y colocar funcionan como de costumbre. Esto incluye operaciones entre controles de Windows Forms y WPF. | No aplicable. |
Integración de controles WPF en Forms de Windows
Los siguientes escenarios de interoperación se admiten cuando un control de Windows Forms hospeda un control WPF:
Hospedar uno o varios controles WPF mediante código.
Asociar una hoja de propiedades con uno o varios controles WPF hospedados.
Hospedar una o varias páginas de WPF en un formulario.
Iniciar una ventana de WPF.
Alojar un formulario maestro/detalle con un formulario maestro de Windows Forms y detalles de WPF.
Alojar un formulario maestro/detalle con un maestro WPF y detalles de Windows Forms.
Hospedar controles WPF personalizados.
Hospedar controles híbridos.
Propiedades ambientales
Algunas de las propiedades ambientales de los controles de Windows Forms tienen equivalentes de WPF. Estas propiedades de ambiente se propagan a los controles WPF hospedados y se exponen como propiedades públicas en el control ElementHost. El ElementHost control traduce cada propiedad ambiente de Windows Forms a su equivalente de WPF.
Para obtener más información, vea Asignación de propiedades de Windows Forms y WPF.
Comportamiento
En la tabla siguiente se describe el comportamiento de interoperación.
Comportamiento | Compatible | No está soportado |
---|---|---|
Transparencia | La renderización del control WPF admite transparencia. El fondo del control primario de Windows Forms puede convertirse en el fondo de los controles WPF hospedados. | No aplicable. |
Subprocesamiento múltiple | Se admiten todas las variedades de multithreading. | Tanto las tecnologías de Windows Forms como WPF asumen un modelo de simultaneidad uniproceso. Durante la depuración, las llamadas a objetos del framework desde otros hilos generarán una excepción para cumplir con este requisito. |
Seguridad | Todos los escenarios de interoperación requieren plena confianza. | No se permite ningún escenario de interoperación en confianza parcial. |
Accesibilidad | Se admiten todos los escenarios de accesibilidad. Los productos de tecnología de asistencia funcionan correctamente cuando se usan para aplicaciones híbridas que contienen controles de Windows Forms y WPF. | No aplicable. |
Portapapeles | Todas las operaciones del Portapapeles funcionan como de costumbre. Esto incluye cortar y pegar entre controles de Windows Forms y WPF. | No aplicable. |
Característica de arrastrar y colocar | Todas las operaciones de arrastrar y colocar funcionan como de costumbre. Esto incluye operaciones entre controles de Windows Forms y WPF. | No aplicable. |
Consulte también
.NET Desktop feedback