Solución de problemas de aplicaciones híbridas
Actualización: noviembre 2007
En este tema se muestra una lista de algunos problemas comunes que se pueden producir al crear aplicaciones híbridas que utilizan las dos tecnologías, WPF y formularios Windows Forms.
Controles superpuestos
Los controles no se pueden superponer como cabría esperar. formularios Windows Forms utiliza un HWND independiente para cada control. WPF utiliza un HWND para todo el contenido de una página. Esta diferencia de implementación da lugar a comportamientos de superposición inesperados.
Un control de formularios Windows Forms hospedado en WPF siempre aparece encima del contenido de WPF.
El contenido de WPF hospedado en un control de ElementHost aparece en el orden z del control ElementHost. Es posible superponer controles ElementHost, pero el contenido de WPF hospedado no se combina ni interactúa.
Propiedad secundaria
Las clases WindowsFormsHost y ElementHost pueden hospedar un solo control o elemento secundario. Para hospedar más de un control o elemento, debe utilizar un contenedor como contenido secundario. Por ejemplo, puede agregar controles de botón y casilla de formularios Windows Forms a un control System.Windows.Forms.Panel y, a continuación, asignar el panel a la propiedad Child del control WindowsFormsHost. Sin embargo, no puede agregar los controles de botón y casilla por separado al mismo control WindowsFormsHost.
Ajustar la escala
WPF y formularios Windows Forms tienen modelos diferentes de ajuste de escala. Algunas transformaciones de ajuste de escala de WPF resultan lógicas para los controles de formularios Windows Forms, pero otras, no. Por ejemplo, ajustar la escala de un control de formularios Windows Forms a 0 funcionará, pero si intenta ajustar la escala del mismo control a un valor distinto de cero, el tamaño del control sigue siendo 0. Para obtener más información, consulte Consideraciones sobre el diseño del elemento WindowsFormsHost.
Adaptador
Puede producirse confusión al trabajar con las clases WindowsFormsHost y ElementHost, porque incluyen un contenedor oculto. Las clases WindowsFormsHost y ElementHost tienen un contenedor oculto, denominado adaptador, que utilizan para hospedar el contenido. Para el elemento WindowsFormsHost, el adaptador se deriva de la clase System.Windows.Forms.ContainerControl. Para el control ElementHost, el adaptador se deriva del elemento DockPanel. Cuando encuentre referencias al adaptador en otros temas sobre interoperación, se refieren a este contenedor.
Anidamiento
No se admite anidar un elemento WindowsFormsHost dentro de un control ElementHost. Tampoco se admite anidar un control ElementHost dentro de un elemento WindowsFormsHost.
Focus
El foco funciona de manera diferente en WPF y en formularios Windows Forms, lo que significa que pueden producirse problemas de foco en las aplicaciones híbridas. Por ejemplo, si tiene el foco dentro de un elemento WindowsFormsHost, y minimiza y restaura la página o bien muestra un cuadro de diálogo modal, puede perderse el foco del elemento WindowsFormsHost. El elemento WindowsFormsHost sigue teniendo el foco, pero puede que el control que incluye no lo tenga.
El foco afecta también a la validación de datos. La validación funciona en un elemento WindowsFormsHost, pero no funciona cuando se presiona la tecla TAB para salir del elemento WindowsFormsHost, o para cambiar entre dos elementos WindowsFormsHost diferentes.
Asignación de propiedad
Algunas asignaciones de propiedad exigen una ardua labor de interpretación a fin de salvar las diferencias de implementación entre ambas tecnologías, formularios Windows Forms y WPF. Las asignaciones de propiedad permiten que el código reaccione ante los cambios de fuentes, colores y otras propiedades. En general, las asignaciones de propiedad funcionan realizando escuchas para detectar eventos de cambio de propiedad (PropertyChanged) o llamadas a OnPropertyChanged, y estableciendo las propiedades adecuadas en el control secundario o en su adaptador. Para obtener más información, consulte Asignación de propiedades en formularios Windows Forms y WPF.
Propiedades relacionadas con el diseño en el contenido hospedado
Cuando se asigna la propiedad WindowsFormsHost.Child o ElementHost.Child, automáticamente se establecen varias propiedades relacionadas con el diseño en el contenido hospedado. Cambiar estas propiedades de contenido puede producir comportamientos de diseño inesperados.
El contenido hospedado se acopla para rellenar el elemento primario WindowsFormsHost y ElementHost. Para habilitar este comportamiento de relleno, se establecen varias propiedades al establecer la propiedad secundaria. En la tabla siguiente se muestra qué propiedades de contenido establecen las clases ElementHost y WindowsFormsHost.
Clase host |
Propiedades de contenido |
|---|---|
No se establezca directamente estas propiedades en el contenido hospedado. Para obtener más información, consulte Consideraciones sobre el diseño del elemento WindowsFormsHost.
Aplicaciones de navegación
Las aplicaciones de navegación pueden no mantener el estado del usuario. El elemento WindowsFormsHost vuelve a crear los controles cuando se utiliza en una aplicación de navegación. La nueva creación de los controles secundarios se produce cuando el usuario sale de la página que hospeda el elemento WindowsFormsHost y, a continuación, vuelve a ella. Todo el contenido que el usuario haya escrito se perderá.
Interoperación de bucles de mensajes
Cuando se trabaja con bucles de mensajes de formularios Windows Forms, puede que los mensajes no se procesen como cabría esperar. El constructor WindowsFormsHost llama al método EnableWindowsFormsInterop. Este método agrega un filtro de mensajes al bucle de mensajes de WPF. Este filtro llama al método Control.PreProcessMessage si el destino del mensaje es System.Windows.Forms.Control y convierte o envía el mensaje.
Si muestra Window en un bucle de mensajes de formularios Windows Forms con el método Application.Run, no podrá escribir nada a menos que llame al método EnableModelessKeyboardInterop. El método EnableModelessKeyboardInterop toma una Window y agrega un System.Windows.Forms.IMessageFilter que vuelve a enrutar los mensajes relacionados con claves al bucle de mensajes de WPF. Para obtener más información, consulte Arquitectura de entrada de interoperabilidad entre formularios Windows Forms y WPF.
Opacidad y disposición en capas
La clase HwndHost no admite las capas. Esto significa que establecer la propiedad Opacity en el elemento WindowsFormsHost no surte ningún efecto, y que no se producirá ninguna mezcla con las demás ventanas de WPF cuya propiedad AllowsTransparency esté establecida en true.
Desechar
No desechar correctamente las clases puede malgastar recursos. En las aplicaciones híbridas, asegúrese de desechar las clases WindowsFormsHost y ElementHost, pues de lo contrario puede malgastar recursos. formularios Windows Forms desecha los controles ElementHost cuando se cierra su elemento primario Form no modal. WPF desecha los elementos WindowsFormsHost cuando se cierra la aplicación. Es posible mostrar un elemento WindowsFormsHost en una Window en un bucle de mensajes de formularios Windows Forms. En este caso, puede que el código no reciba la notificación de que la aplicación se está cerrando.
Habilitar estilos visuales
Puede que los estilos visuales de Microsoft Windows XP no estén habilitados en un control de formularios Windows Forms. Se llama al método Application.EnableVisualStyles en la plantilla para una aplicación de formularios Windows Forms. Aunque no se llama a este método de manera predeterminada, si utiliza Visual Studio para crear un proyecto, obtendrá estilos visuales de Microsoft Windows XP para los controles, si está disponible la versión 6.0 de Comctl32.dll. Debe llamar al método EnableVisualStyles antes de que se creen los controladores en el subproceso. Para obtener más información, consulte Cómo: Habilitar estilos visuales en una aplicación híbrida.
Controles con licencia
Los controles de formularios Windows Forms con licencia que muestran información de licencias en un cuadro de mensaje al usuario pueden provocar un comportamiento inesperado en una aplicación híbrida. Algunos controles con licencia muestran un cuadro de diálogo en respuesta, a fin de administrar la creación. Por ejemplo, un control con licencia podría informar al usuario de que se requiere una licencia o de que al usuario le quedan tres usos de prueba del control.
El elemento WindowsFormsHost se deriva de la clase HwndHost y el controlador del control secundario se crea dentro del método BuildWindowCore. La clase HwndHost no permite procesar los mensajes en el método BuildWindowCore, pero al mostrar un cuadro de diálogo se provoca el envío de mensajes. Para habilitar este escenario de licencias, llame al método Control.CreateControl del control antes de asignarlo como elemento secundario del elemento WindowsFormsHost.
WPF Designer
Puede diseñar el contenido de WPF mediante Windows Presentation Foundation (WPF) Designer for Visual Studio. En las secciones siguientes se indican algunos problemas comunes que se pueden producir al crear aplicaciones híbridas con WPF Designer.
BackColorTransparent se omite en tiempo de diseño
La propiedad BackColorTransparent puede no funcionar según lo previsto en tiempo de diseño.
Si un control de WPF no está en un elemento primario visible, el motor de tiempo de ejecución de WPF omite el valor BackColorTransparent. La razón por la que se puede omitir BackColorTransparent es porque el objeto ElementHost se crea en un AppDomainindependiente. Sin embargo, al ejecutar la aplicación, BackColorTransparent funciona según lo previsto.
Aparece la lista de errores en tiempo de diseño cuando se elimina la carpeta obj
Si se elimina la carpeta obj, aparece la lista de errores en tiempo de diseño.
Al diseñar mediante ElementHost, el Diseñador de Windows Forms utiliza los archivos generados en la carpeta Debug o Release situada en la carpeta obj del proyecto. Si elimina estos archivos, aparece la lista de errores en tiempo de diseño. Para corregir este problema, vuelva a generar el proyecto. Para obtener más información, vea Errores en tiempo de diseño en el Diseñador de Windows Forms.
ElementHost e IME
Los controles de WPF hospedados en ElementHost no admiten actualmente la propiedad ImeMode. Los controles hospedados omitirán los cambios realizados en ImeMode.
Vea también
Tareas
Cómo: Habilitar estilos visuales en una aplicación híbrida
Conceptos
Arquitectura de entrada de interoperabilidad entre formularios Windows Forms y WPF
Consideraciones sobre el diseño del elemento WindowsFormsHost
Asignación de propiedades en formularios Windows Forms y WPF
Errores en tiempo de diseño en el Diseñador de Windows Forms