Message Mechanism of WPF (II)-hidden message windows in five windows of WPF

Directory

WPF message mechanism (1)-Let the application get started

WPF message mechanism (2)-five windows in WPF

(1) Hide the message window

(2) window for processing activated and closed messages and system resource notification windows

(3) visible window for user interaction

(4) Visible windows used for UI window painting

WPF message mechanism (III)-source of WPF input events

WPF message mechanism (4)-UI update in WPF

 

Five windows in WPF

For Windows systems, it is a message system, and the core of the message system is the window. This is also true for WPF. So why do windows need to exist in WPF?

In the previous article, we frequently mentioned "Threads". "dispatcher" is actually the thread where the WPF application is running. call dispatcher. run checks whether a dispatcher object exists in the current thread. If no dispatcher object exists, construct one. Here, a thread corresponds to one dispatcher. Therefore, when a WPF object obtains the this. Dispatcher attribute, different objects take the same dispatcher instance. In addition, the "message loop" and "message queue" mentioned above are all Win32 application concepts. We know that when these concepts are mentioned, they will inevitably follow Win32's "window ", "handle", "wndproc" and other concepts are inseparable. Is there any "form", "handle", or "wndproc" in WPF?

What I want to say is: yes, there are more than one, but they are not exposed, and you do not need to care about them outside.

Generally, when a WPF application is running, five Win32 windows are created in the background to help the WPF system process messages in the operating system and in the application. Only one of the five windows is visible. It can process input events and user interaction. The other four windows are invisible and help WPF process messages from other sources. Next, I will introduce how these five Win32 Windows Help WPF process messages. I will introduce the order in which each window is created.

 

Hide message window

Creation Time: when the application constructor calls the dispatcherobject constructor of the base class, a dispatcher object is created in the private constructor of the dispatcher.

Purpose: Implement Asynchronous calls to the WPF thread model.

When talking about asynchronous calls, I believe many people are familiar with it. In winform, we usually divide this operation into many steps to make some method calls that spend a lot of time without affecting the UI response, and then use begininvoke to call each step, in this way, the UI response will not be blocked. The essence of begininvoke is to send a message to the Message Queue instead of calling it directly. At the same time, the UI behavior (mousemove) causes the system to update the UI in the message queue by using the postmessage. However, it takes a short time for each other to update the UI, the interface will not be blocked if two messages are processed at the same time. WPF also faces such a problem. How does it solve it? Here window 1 # plays a vital role. The following figure shows what window 1 is doing?

WPF is also implemented through begininvoke, while WPF's begininvoke is exposed on the dispatcher because the entire message system is coordinated by dispatcher. The figure above shows the process that dispatcher experienced after calling begininvoke, and when Foo () was actually executed.

Step 1The call delegate and priority are encapsulated into a dispatcheroperation and put into the priority queue maintained by the dispatcher. This queue is sorted by dispatcherpriority, And the dispatcheroperation with a higher priority is always processed first. For more information about priority, see msdn's explanation of the WPF thread model.

Step 2To post a message named msgprocessqueue to the Message Queue of the current thread. This message is defined by WPF. For details, refer to the static constructor of dispatcher.

_ Msgprocessqueue = unsafenativemethods. registerwindowmessage ("dispatcherprocessqueue ");

Before the message is post to the message queue, you must set MSG. Handle, which is the handle of window 1. Handle is used to specify the window wndproc (Window Process) in which to process the message when the message is cyclically dispatch. All the messages caused by begininvoke are processed by the window1 # window process.

Step 3To read messages cyclically.

Step 4The system obtains the handle of the message and finds that it is the same as the handle of window1 #. Then, the message is distributed to the window of window1 # for processing.

Step 5In the window, take a dispatcheroperation in the priority queue.

Step 6Run the dispatcheroperation. Invoke method. The core of the invoke method is the delegate passed in when the dispatcheroperation construction is called, that is, the delegate passed in by dispatcher. begininvoke. Finally, the Foo () method is executed.

Through the above six steps, a dispatcher. begininvoke is processed. This process requires the continuous flow of messages, so you must join the message queue and finally handle specific window processes. The core thing is this hidden window1 #, in WPF, he is only responsible for processing asynchronous calls. He does not care about other messages, and the remaining four windows are being processed. This window1 # contains a shell in WPF. If you are interested, you can view the messageonlyhwndwrapper type.