--- title: "Windows Forms and WPF interop input architecture" titleSuffix: "" ms.date: "03/30/2017" helpviewer_keywords: - "input architecture [WPF interoperability]" - "messages [WPF]" - "Windows Forms [WPF], interoperability with" - "Windows Forms [WPF], WPF interoperation" - "interoperability [WPF], Windows Forms" - "modeless forms [WPF]" - "ElementHost keyboard and messages [WPF]" - "keyboard interoperation [WPF]" - "WindowsFormsHost keyboard and messages [WPF]" - "modeless dialog boxes [WPF]" ms.assetid: 0eb6f137-f088-4c5e-9e37-f96afd28f235 --- # Windows Forms and WPF Interoperability Input Architecture Interoperation between the [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] and Windows Forms requires that both technologies have the appropriate keyboard input processing. This topic describes how these technologies implement keyboard and message processing to enable smooth interoperation in hybrid applications. This topic contains the following subsections: - Modeless Forms and Dialog Boxes - WindowsFormsHost Keyboard and Message Processing - ElementHost Keyboard and Message Processing ## Modeless Forms and Dialog Boxes Call the method on the element to open a modeless form or dialog box from a [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)]-based application. Call the method on the control to open a modeless [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] page in a Windows Forms-based application. ## WindowsFormsHost Keyboard and Message Processing When hosted by a [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)]-based application, Windows Forms keyboard and message processing consists of the following: - The class acquires messages from the [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] message loop, which is implemented by the class. - The class creates a surrogate Windows Forms message loop to ensure that ordinary Windows Forms keyboard processing occurs. - The class implements the interface to coordinate focus management with [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)]. - The controls register themselves and start their message loops. The following sections describe these parts of the process in more detail. ### Acquiring Messages from the WPF Message Loop The class implements the message loop manager for [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)]. The class provides hooks to enable external clients to filter messages before [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] processes them. The interoperation implementation handles the event, which enables Windows Forms controls to process messages before [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] controls. ### Surrogate Windows Forms Message Loop By default, the class contains the primary message loop for Windows Forms applications. During interoperation, the Windows Forms message loop does not process messages. Therefore, this logic must be reproduced. The handler for the event performs the following steps: 1. Filters the message using the interface. 2. Calls the method. 3. Translates and dispatches the message, if it is required. 4. Passes the message to the hosting control, if no other controls process the message. ### IKeyboardInputSink Implementation The surrogate message loop handles keyboard management. Therefore, the method is the only member that requires an implementation in the class. By default, the class returns `false` for its implementation. This prevents tabbing from a [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] control to a Windows Forms control. The implementation of the method performs the following steps: 1. Finds the first or last Windows Forms control that is contained by the control and that can receive focus. The control choice depends on traversal information. 2. Sets focus to the control and returns `true`. 3. If no control can receive focus, returns `false`. ### WindowsFormsHost Registration When the window handle to a control is created, the control calls an internal static method that registers its presence for the message loop. During registration, the control examines the message loop. If the message loop has not been started, the event handler is created. The message loop is considered to be running when the event handler is attached. When the window handle is destroyed, the control removes itself from registration. ## ElementHost Keyboard and Message Processing When hosted by a Windows Forms application, [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] keyboard and message processing consists of the following: - , , and interface implementations. - Tabbing and arrow keys. - Command keys and dialog box keys. - Windows Forms accelerator processing. The following sections describe these parts in more detail. ### Interface Implementations In Windows Forms, keyboard messages are routed to the window handle of the control that has focus. In the control, these messages are routed to the hosted element. To accomplish this, the control provides an instance. If the control has focus, the instance routes most keyboard input so that it can be processed by the [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] class. The class implements the and interfaces. Keyboard interoperation relies on implementing the method to handle TAB key and arrow key input that moves focus out of hosted elements. ### Tabbing and Arrow Keys The Windows Forms selection logic is mapped to the and methods to implement TAB and arrow key navigation. Overriding the method accomplishes this mapping. ### Command Keys and Dialog Box Keys To give [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] the first opportunity to process command keys and dialog keys, Windows Forms command preprocessing is connected to the method. Overriding the method connects the two technologies. With the method, the hosted elements can handle any key message, such as WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN, or WM_SYSKEYUP, including command keys, such as TAB, ENTER, ESC, and arrow keys. If a key message is not handled, it is sent up the Windows Forms ancestor hierarchy for handling. ### Accelerator Processing To process accelerators correctly, Windows Forms accelerator processing must be connected to the [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] class. Additionally, all WM_CHAR messages must be correctly routed to hosted elements. Because the default implementation of the method returns `false`, WM_CHAR messages are processed using the following logic: - The method is overridden to ensure that all WM_CHAR messages are forwarded to hosted elements. - If the ALT key is pressed, the message is WM_SYSCHAR. Windows Forms does not preprocess this message through the method. Therefore, the method is overridden to query the [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] for a registered accelerator. If a registered accelerator is found, processes it. - If the ALT key is not pressed, the [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] class processes the unhandled input. If the input is an accelerator, the processes it. The event is handled for WM_CHAR messages that were not processed. When the user presses the ALT key, accelerator visual cues are shown on the whole form. To support this behavior, all controls on the active form receive WM_SYSKEYDOWN messages, regardless of which control has focus. Messages are sent only to controls in the active form. ## See also - - - - - [Walkthrough: Hosting a Windows Forms Composite Control in WPF](walkthrough-hosting-a-windows-forms-composite-control-in-wpf.md) - [Walkthrough: Hosting a WPF Composite Control in Windows Forms](walkthrough-hosting-a-wpf-composite-control-in-windows-forms.md) - [WPF and Win32 Interoperation](wpf-and-win32-interoperation.md)