Arquitectura de entrada de interoperabilidad entre formularios Windows Forms y WPF
Actualización: noviembre 2007
La interoperabilidad entre WPF y formularios Windows Forms requiere que ambas tecnologías tengan el procesamiento adecuado de la entrada de teclado. En este tema se describe cómo estas tecnologías implementan el procesamiento de teclado y de mensajes para habilitar la interoperabilidad sin contratiempos en aplicaciones híbridas.
Este tema contiene las siguientes subsecciones:
Formularios no modales y cuadros de diálogo
Procesamiento de mensajes y de teclado de WindowsFormsHost
Procesamiento de mensajes y de teclado de ElementHost
Formularios no modales y cuadros de diálogo
Llame al método EnableWindowsFormsInterop del elemento WindowsFormsHost para abrir un formulario no modal o un cuadro de diálogo desde una aplicación basada en WPF.
Llame al método EnableModelessKeyboardInterop del control ElementHost para abrir una página WPF no modal en una aplicación basada en formularios Windows Forms.
Procesamiento de mensajes y de teclado de WindowsFormsHost
Cuando se hospeda en una aplicación basada en WPF, el procesamiento de mensajes y teclado de formularios Windows Forms consta de lo siguiente:
La clase WindowsFormsHost adquiere mensajes del bucle de mensajes WPF, implementado por la clase ComponentDispatcher.
La clase WindowsFormsHost crea un bucle de mensajes de formularios Windows Forms suplente para asegurarse de que se produzca el procesamiento de teclado ordinario de formularios Windows Forms.
La clase WindowsFormsHost implementa la interfaz IKeyboardInputSink para coordinar la administración del foco con WPF.
Los controles WindowsFormsHost se registran por sí mismos e inician sus bucles de mensajes.
En las secciones siguientes se describen estas partes del proceso más detalladamente.
Adquirir mensajes del bucle de mensajes de Windows Presentation Foundation
La clase ComponentDispatcher implementa el administrador del bucle de mensajes para WPF. La clase ComponentDispatcher proporciona enlaces para permitir que los clientes externos filtren mensajes antes de que WPF los procese.
La implementación de la interoperabilidad administra el evento ComponentDispatcher.ThreadFilterMessage, que permite a los controles formularios Windows Forms procesar mensajes antes que los controles WPF.
Bucle de mensajes suplente de formularios de Windows Forms
De forma predeterminada, la clase System.Windows.Forms.Application contiene el bucle de mensajes primario para aplicaciones de formularios de formularios Windows Forms. Durante la interoperabilidad, el bucle de mensajes de formularios de formularios Windows Forms no procesa los mensajes. Por consiguiente, se debe reproducir esta lógica. El controlador para el evento ComponentDispatcher.ThreadFilterMessage realiza los pasos siguientes:
Filtra el mensaje mediante la interfaz IMessageFilter.
Llama al método Control.PreProcessMessage.
Traduce y envía el mensaje, si se requiere.
Pasa el mensaje al control host, si ningún otro control procesa el mensaje.
Implementación de IKeyboardInputSink
El bucle de mensajes suplente controla la administración del teclado. Por consiguiente, el método IKeyboardInputSink.TabInto es el único miembro de IKeyboardInputSink que requiere una implementación en la clase WindowsFormsHost.
De forma predeterminada, la clase HwndHost devuelve false para su implementación de IKeyboardInputSink.TabInto. Esto evita pasar con la tecla de tabulación de un control WPF a un control formularios Windows Forms.
La implementación de WindowsFormsHost del método IKeyboardInputSink.TabInto realiza los pasos siguientes:
Busca el primer o el último control formularios Windows Forms contenido en el control WindowsFormsHost y que puede recibir el foco. La opción de control depende de la información de recorrido.
Establece el foco en el control y devuelve true.
Si ningún control puede recibir el foco, devuelve false.
Registro de WindowsFormsHost
Cuando se crea el identificador de ventana para un control WindowsFormsHost, el control WindowsFormsHost llama a un método estático interno que registra su presencia para el bucle de mensajes.
Durante el registro, el control WindowsFormsHost examina el bucle de mensajes. Si no se ha iniciado el bucle de mensajes, se crea el controlador de eventos ComponentDispatcher.ThreadFilterMessage. Se considera que el bucle de mensajes se está ejecutando cuando está asociado el controlador de eventos ComponentDispatcher.ThreadFilterMessage.
Cuando se destruye el identificador de ventana, el control WindowsFormsHost se quita del registro.
Procesamiento de mensajes y de teclado de ElementHost
Cuando se hospeda en una aplicación formularios Windows Forms, el procesamiento de mensajes y teclado de WPF consta de lo siguiente:
Implementaciones de la interfaz HwndSource, IKeyboardInputSink y IKeyboardInputSite.
Teclas de tabulación y dirección.
Teclas de comando y de cuadro de diálogo.
Procesamiento de aceleradores de formularios de formularios Windows Forms.
En las secciones siguientes se describen estas partes más detalladamente.
Implementaciones de interfaces
En formularios Windows Forms, los mensajes del teclado se enrutan al identificador de ventana del control que tiene el foco. En el control ElementHost, estos mensajes se enrutan al elemento hospedado. Para lograr esto, el control ElementHost proporciona una instancia de HwndSource. Si el control ElementHost tiene el foco, la instancia de HwndSource enruta la mayor parte de la entrada del teclado para que pueda procesarla la clase WPFInputManager.
La clase HwndSource implementa las interfaces IKeyboardInputSink y IKeyboardInputSite.
La interoperabilidad del teclado se apoya en la implementación del método OnNoMoreTabStops para administrar la entrada de la tecla de tabulación y las teclas de dirección que mueve el foco fuera de los elementos hospedados.
Teclas de tabulación y dirección
La lógica de selección formularios Windows Forms está asignada a los métodos IKeyboardInputSink.TabInto y OnNoMoreTabStops para implementar la navegación con la tecla de tabulación y las teclas de dirección. Esta asignación se realiza invalidando el método Select.
Teclas de comando y de cuadro de diálogo
Para dar a WPF la primera oportunidad de procesar teclas de comando y teclas de diálogo, el procesamiento previo de comandos de formularios de formularios Windows Forms está conectado al método TranslateAccelerator. Al invalidar el método Control.ProcessCmdKey, se conectan las dos tecnologías.
Con el método TranslateAccelerator, los elementos hospedados pueden administrar cualquier mensaje clave, como WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN o WM_SYSKEYUP, incluidas las teclas de comando como TAB, Entrar, ESC y las teclas de dirección. Si no se administra un mensaje clave, se envía a la jerarquía de antecesor de formularios de formularios Windows Forms para su administración.
Procesamiento de aceleradores
Para procesar correctamente los aceleradores, el procesamiento de aceleradores de formularios de formularios Windows Forms debe estar conectado a la clase WPFAccessKeyManager. Además, todos los mensajes de WM_CHAR se deben enrutar correctamente a los elementos hospedados.
Dado que la implementación predeterminada de HwndSource del método TranslateChar devuelve false, los mensajes de WM_CHAR se procesan utilizando la lógica siguiente:
El método Control.IsInputChar se invalida para asegurarse que todos los mensajes de WM_CHAR se reenvíen a los elementos hospedados.
Si se presiona la tecla ALT, el mensaje es WM_SYSCHAR. formularios Windows Forms no preprocesa este mensaje a través del método IsInputChar. Por consiguiente, el método ProcessMnemonic se invalida para consultar un acelerador registrado en el objeto WPFAccessKeyManager. Si se encuentra un acelerador registrado, AccessKeyManager lo procesa.
Si no se presiona la tecla ALT, la clase WPFInputManager procesa la entrada no controlada. Si la entrada es un acelerador, el objeto AccessKeyManager lo procesa. El evento PostProcessInput se administra para los mensajes de WM_CHAR que no se procesaron.
Cuando el usuario presiona la tecla ALT, se muestran indicaciones visuales del acelerador en todo el formulario. Para admitir este comportamiento, todos los controles ElementHost del formulario activo reciben mensajes de WM_SYSKEYDOWN, sin tener en cuenta qué control tiene el foco.
Los mensajes solamente se envían a los controles ElementHost del formulario activo.
Vea también
Conceptos
Tutorial: Hospedar un control de Windows Presentation Foundation en formularios Windows Forms
Información general sobre la interoperabilidad de WPF y Win32