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.
La interoperación entre WPF y Windows Forms requiere que ambas tecnologías tengan el procesamiento de entrada de teclado adecuado. En este tema se describe cómo estas tecnologías implementan el procesamiento de mensajes y el teclado para habilitar la interoperación fluida en aplicaciones híbridas.
Este tema contiene las siguientes subsecciones:
Formularios y cuadros de diálogo sin modo
Teclado y procesamiento de mensajes de WindowsFormsHost
Procesamiento de mensajes y teclado ElementHost
Formularios y cuadros de diálogo sin modo
Llame al EnableWindowsFormsInterop método en el WindowsFormsHost elemento para abrir un formulario o cuadro de diálogo modeless desde una aplicación basada en WPF.
Llame al EnableModelessKeyboardInterop método en el ElementHost control para abrir una página WPF modeless en una aplicación basada en Windows Forms.
Teclado y procesamiento de mensajes de WindowsFormsHost
Cuando se hospeda en una aplicación basada en WPF, el teclado y el procesamiento de mensajes de Windows Forms constan de lo siguiente:
La WindowsFormsHost clase adquiere mensajes del bucle de mensajes de WPF, que implementa la ComponentDispatcher clase .
La WindowsFormsHost clase crea un bucle de mensajes suplente de Windows Forms para asegurarse de que se produce el procesamiento normal del teclado de Windows Forms.
La WindowsFormsHost clase implementa la IKeyboardInputSink interfaz para coordinar la administración del foco con WPF.
Los WindowsFormsHost controles se registran a sí mismos e inician sus bucles de mensaje.
En las secciones siguientes se describen estas partes del proceso con más detalle.
Adquisición de mensajes desde el bucle de mensajes de WPF
La ComponentDispatcher clase implementa el administrador de bucles de mensajes para WPF. La ComponentDispatcher clase proporciona enlaces para permitir que los clientes externos filtren los mensajes antes de que WPF los procese.
La implementación de interoperación controla el ComponentDispatcher.ThreadFilterMessage evento, lo que permite que los controles de Windows Forms procesen mensajes antes de los controles de WPF.
Bucle de mensajes alternativo de Windows Forms
De forma predeterminada, la System.Windows.Forms.Application clase contiene el bucle de mensajes principal para las aplicaciones de Windows Forms. Durante la interoperación, el bucle de mensajes de Windows Forms no procesa los mensajes. Por lo tanto, esta lógica debe reproducirse. El controlador del ComponentDispatcher.ThreadFilterMessage evento realiza los pasos siguientes:
Filtra el mensaje mediante la IMessageFilter interfaz .
Llama al método Control.PreProcessMessage.
Traduce y envía el mensaje, si es necesario.
Pasa el mensaje al control de hospedaje, si ningún otro control procesa el mensaje.
Implementación de IKeyboardInputSink
El bucle de mensajes suplente controla la administración del teclado. Por lo tanto, el IKeyboardInputSink.TabInto método es el único IKeyboardInputSink miembro que requiere una implementación en la WindowsFormsHost clase .
De forma predeterminada, la HwndHost clase devuelve false para su IKeyboardInputSink.TabInto implementación. Esto impide la tabulación de un control WPF a un control de Windows Forms.
La WindowsFormsHost implementación del IKeyboardInputSink.TabInto método realiza los pasos siguientes:
Busca el primer o último control de Windows Forms que contiene el WindowsFormsHost control y que puede recibir el foco. La elección del control depende de la información de trayectoria.
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 WindowsFormsHost control, el WindowsFormsHost control llama a un método estático interno que registra su presencia para el bucle de mensajes.
Durante el registro, el WindowsFormsHost control examina el bucle de mensajes. Si no se ha iniciado el bucle de mensajes, se crea el ComponentDispatcher.ThreadFilterMessage controlador de eventos. El bucle de mensajes se considera que se está ejecutando cuando se adjunta el ComponentDispatcher.ThreadFilterMessage controlador de eventos.
Cuando se destruye el identificador de ventana, el WindowsFormsHost control se quita del registro.
Procesamiento de mensajes y teclado ElementHost
Cuando se hospeda en una aplicación de Windows Forms, el teclado WPF y el procesamiento de mensajes constan de lo siguiente:
HwndSource, IKeyboardInputSink y IKeyboardInputSite implementaciones de interfaz.
Teclas de tabulación y flecha.
Teclas de comando y teclas de cuadro de diálogo.
Procesamiento del acelerador de Windows Forms.
En las secciones siguientes se describen estas partes con más detalle.
Implementaciones de interfaz
En Windows Forms, los mensajes de teclado se enrutan al identificador de ventana del control que tiene el foco. En el control ElementHost, estos mensajes se dirigen al elemento hospedado. Para ello, el ElementHost control proporciona una HwndSource instancia. Si el control ElementHost tiene el foco, la instancia HwndSource enruta la mayoría de la entrada de teclado para que la clase InputManager WPF pueda procesarla.
La HwndSource clase implementa las IKeyboardInputSink interfaces y IKeyboardInputSite .
La interoperación de teclado se basa en la implementación del método para controlar la OnNoMoreTabStops tecla TAB y la entrada de tecla de flecha que mueve el foco fuera de los elementos hospedados.
Teclas de tabulación y flecha
La lógica de selección de Windows Forms se asigna a los métodos y IKeyboardInputSink.TabInto para implementar la OnNoMoreTabStops navegación de tabulación y tecla de dirección. Al sobrescribir el método Select, se realiza este mapeo.
Teclas de comando y teclas de cuadro de diálogo
Para dar a WPF la primera oportunidad de procesar las claves de comando y las teclas de diálogo, el preprocesamiento de comandos de Windows Forms está conectado al TranslateAccelerator método . Al invalidar el Control.ProcessCmdKey método se conectan las dos tecnologías.
Con el método TranslateAccelerator, los elementos hospedados pueden controlar cualquier mensaje de tecla, como WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN o WM_SYSKEYUP, incluidas las teclas de comandos, como TAB, ENTER, ESC y las flechas de dirección. Si no se controla un mensaje de clave, se envía a la jerarquía antecesora de Windows Forms para controlarlo.
Procesamiento del acelerador
Para procesar los aceleradores correctamente, el procesamiento del acelerador de Windows Forms debe estar conectado a la clase WPF AccessKeyManager . Además, todos los mensajes de WM_CHAR deben enrutarse correctamente a los elementos hospedados.
Dado que la implementación predeterminada HwndSource del TranslateChar método devuelve false, WM_CHAR mensajes se procesan mediante la siguiente lógica:
El Control.IsInputChar método se invalida para asegurarse de que todos los mensajes de WM_CHAR se reenvieron a los elementos hospedados.
Si se presiona la tecla ALT, el mensaje se WM_SYSCHAR. Windows Forms no preprocesa este mensaje a través del IsInputChar método . Por lo tanto, el método ProcessMnemonic se anula para consultar en WPF AccessKeyManager un acelerador registrado. Si se encuentra un acelerador registrado, AccessKeyManager lo procesa.
Si no se presiona la tecla ALT, la clase WPF InputManager procesa la entrada no controlada. Si la entrada es un acelerador, AccessKeyManager lo procesa. El evento PostProcessInput se maneja para mensajes WM_CHAR que no se procesaron.
Cuando el usuario presiona la tecla ALT, las indicaciones visuales del acelerador se muestran en todo el formulario. Para admitir este comportamiento, todos los ElementHost controles del formulario activo reciben mensajes WM_SYSKEYDOWN, independientemente del control que tenga el enfoque.
Los mensajes solo se envían a controles en el formulario activo.
Consulte también
Colaborar con nosotros en GitHub
El origen de este contenido se puede encontrar en GitHub, donde también puede crear y revisar problemas y solicitudes de incorporación de cambios. Para más información, consulte nuestra guía para colaboradores.
.NET Desktop feedback