--- title: "Sharing Message Loops Between Win32 and WPF" titleSuffix: "" ms.date: "03/30/2017" helpviewer_keywords: - "Win32 code [WPF], sharing message loops" - "message loops [WPF]" - "sharing message loops [WPF]" - "interoperability [WPF], Win32" ms.assetid: 39ee888c-e5ec-41c8-b11f-7b851a554442 --- # Sharing Message Loops Between Win32 and WPF This topic describes how to implement a message loop for interoperation with [!INCLUDE[TLA#tla_winclient](../../../includes/tlasharptla-winclient-md.md)], either by using existing message loop exposure in or by creating a separate message loop on the Win32 side of your interoperation code. ## ComponentDispatcher and the Message Loop A normal scenario for interoperation and keyboard event support is to implement , or to subclass from classes that already implement , such as or . However, keyboard sink support does not address all possible message loop needs you might have when sending and receiving messages across your interoperation boundaries. To help formalize an application message loop architecture, [!INCLUDE[TLA#tla_winclient](../../../includes/tlasharptla-winclient-md.md)] provides the class, which defines a simple protocol for a message loop to follow. is a static class that exposes several members. The scope of each method is implicitly tied to the calling thread. A message loop must call some of those APIs at critical times (as defined in the next section). provides events that other components (such as the keyboard sink) can listen for. The class calls all the appropriate methods in an appropriate sequence. If you are implementing your own message loop, your code is responsible for calling methods in a similar fashion. Calling methods on a thread will only invoke event handlers that were registered on that thread. ## Writing Message Loops The following is a checklist of members you will use if you write your own message loop: - : your message loop should call this to indicate that the thread is modal. - :your message loop should call this to indicate that the thread has reverted to nonmodal. - : your message loop should call this to indicate that should raise the event. will not raise if is `true`, but message loops may choose to call even if cannot respond to it while in modal state. - : your message loop should call this to indicate that a new message is available. The return value indicates whether a listener to a event handled the message. If returns `true` (handled), the dispatcher should do nothing further with the message. If the return value is `false`, the dispatcher is expected to call the Win32 function `TranslateMessage`, then call `DispatchMessage`. ## Using ComponentDispatcher and Existing Message Handling The following is a checklist of members you will use if you rely on the inherent [!INCLUDE[TLA2#tla_winclient](../../../includes/tla2sharptla-winclient-md.md)] message loop. - : returns whether the application has gone modal (e.g., a modal message loop has been pushed). can track this state because the class maintains a count of and calls from the message loop. - and events follow the standard rules for delegate invocations. Delegates are invoked in an unspecified order, and all delegates are invoked even if the first one marks the message as handled. - : indicates an appropriate and efficient time to do idle processing (there are no other pending messages for the thread). will not be raised if the thread is modal. - : raised for all messages that the message pump processes. - : raised for all messages that were not handled during . A message is considered handled if after the event or event, the `handled` parameter passed by reference in event data is `true`. Event handlers should ignore the message if `handled` is `true`, because that means the different handler handled the message first. Event handlers to both events may modify the message. The dispatcher should dispatch the modified message and not the original unchanged message. is delivered to all listeners, but the architectural intention is that only the top-level window containing the HWND at which the messages targeted should invoke code in response to the message. ## How HwndSource Treats ComponentDispatcher Events If the is a top-level window (no parent HWND), it will register with . If is raised, and if the message is intended for the or child windows, calls its , , keyboard sink sequence. If the is not a top-level window (has a parent HWND), there will be no handling. Only the top level window is expected to do the handling, and there is expected to be a top level window with keyboard sink support as part of any interoperation scenario. If on an is called without an appropriate keyboard sink method being called first, your application will receive the higher level keyboard events such as . However, no keyboard sink methods will be called, which circumvents desirable keyboard input model features such as access key support. This might happen because the message loop did not properly notify the relevant thread on the , or because the parent HWND did not invoke the proper keyboard sink responses. A message that goes to the keyboard sink might not be sent to the HWND if you added hooks for that message by using the method. The message might have been handled at the message pump level directly and not submitted to the `DispatchMessage` function. ## See also - - - [WPF and Win32 Interoperation](wpf-and-win32-interoperation.md) - [Threading Model](threading-model.md) - [Input Overview](input-overview.md)