WPF FAQ - Message Loops Between

Message Loops can be written with the following properties.

IsThreadModal – returns whether the application has gone modal (e.g., a modal message loop has been pushed). ComponentDispatcher can track this state because the class maintains a count of ‘PushModal’ and ‘PopModal’ calls from the message loop.

ThreadFilterMessage and ThreadPreprocessMessage 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.

ThreadIdle – indicates an appropriate and efficient time to do idle processing (there are no other pending messages for the thread). ThreadIdle will not be raised if the thread is modal.

ThreadFilterMessage – raised for all messages that the message pump processes.

ThreadPreprocessMessage – raised for all messages that were not handled during ThreadFilterMessage.

We can do this by using WindowInteropHelper. This can be done with the following code snippets.

[C#]
var wpfWindow = new MainWindow();
            WindowInteropHelper windowInteropHelper = new WindowInteropHelper(wpfWindow);
            windowInteropHelper.Owner = this.Handle;
            wpfWindow.Show();

Note: While using the previous code in the form, add the following WPF assemblies to show the WPF window.

• PresentationCore
• PresentationFramework
• WindowsBase

Reference link: https://stackoverflow.com/questions/32701680/setting-a-form-as-owner-for-a-window

If the HwndSource is a top-level window (no parent HWND), it will register with ComponentDispatcher. If ThreadPreprocessMessage is raised and if the message is intended for the HwndSource or child windows, HwndSource calls its IkeyboardInputSink, TranslateAccelerator, TranslateChar, OnMnemonic keyboard sink sequence.
If the HwndSource 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 WndProc on an HwndSource is called without an appropriate keyboard sink method being called first, your application will receive the higher level keyboard events such as ‘KeyDown’. 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 ComponentDispatcher 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 add hooks for that message by using the ‘AddHook()’ method. The message might have been handled at the message pump level directly and not submitted to the DispatchMessage function.