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

Preface

When talking about the word "message mechanism", we will all think of Windows message mechanism. The system packs the keyboard and mouse behavior into a Windows message, then, the system sends these windows messages to a specific window. In fact, messages are sent to the Message Queue of the thread where the specified window is located, the message loop of the application continuously obtains messages from the message queue, and sends the messages to the Window Process of the specific window class for processing. In the window process, the user interaction is completed.

In fact, the underlying level of WPF is also based on the Win32 message system. How does a WPF Application interact with Win32 messages? What kind of mechanism does it have? Next, I will introduce the message mechanism through the following blog posts:

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 windows used for UI window painting

(4) visible window for user interaction

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

WPF message mechanism (4)-UI update in WPF

 

Let the application get started

When talking about WPF messages, we should first know the roles of dispactherobject and Dispatcher in the WPF system.

Most of WPF objects are derived from dispatcherobject. The derived objects have an obvious feature: the thread where the object is modified, it must be the same thread as the thread where the object is created. This is Microsoft's simplest understanding of thread affinity. Who can guarantee the affinity of the thread? That's dispacher. The Type derived from dispatcherobject inherits three important members: the dispatcher attribute, checkaccess (), and verifyaccess () methods. The following two methods are used to check the affinity of the thread. According to the implementation of WPF, if you define a WPF type and a subclass of dispatcherobject, you must call the base at the beginning of the logic defined by the Public member. dispatcher. verifyaccess () to verify the affinity of the thread. So what else does dispatcher do?

First, let's take a look at the logic behind the startup of the next WPF application:

From the call stack, we can see that the blue part starts a thread, and Visual Studio runs the current application in the host process. The red part is from application. the main function is executed, and several functions are passed to the dispatcher. run (), and finally reach dispather. pushframeinpl () method. So why does an application call dispatcher. Run () after run? What has it done to you? If you carefully check application. Run () through reflector, you will find that there are not many actually used code in it, and finally dispatcher. Run is doing things. After an application is started, according to the previous understanding of the Win32 message mechanism, after the application is started, it must enter a message loop. The same applies to WPF. So where does the WPF Application enter the message loop? In fact, this is what dispatcher. Run () does. Check the code of dispacther. pushframeimpl () in the last step. You will see the following code:

Obviously, the orange part is a loop. Does it look familiar? Is it similar to the message loop encountered by Win32 programming? By the way, the WPF application enters the message loop. The getmessage method is called cyclically to get messages from the message queue of the current thread. After a MSG is retrieved, it is handed over to the translateanddispatchmessage method for processing in different window. In this way, any messages that need to be processed by the application are processed by different windows, and the application starts to work.

In the following section, I will introduce Win32 windows in WPF. These windows process messages from the system or from within the application.

Coming soon ~