Message Mechanism of WPF (III)-five internal windows of WPF for processing activated and closed message windows and system resource notification windows

Directory

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

WPF message mechanism (2)-five windows in WPF

(1) Hide the message window

(2) process the activated and closed message windows 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

 

Process application activation and system close windows (window 2 # )

Creation Time: after application. Run is called, run it in the application. ensurehwndsource () method.

Purpose: distribute application activated, deactivated, and sessionending events.

For the sake of security, WPF does not allow the UI window to process the application activation, anti-activation, and the corresponding message when the operating system is closed. Instead, it creates a hidden window internally, it is used to receive Windows messages wm_activateapp and wm_queryendsession. After obtaining the two messages from the thread message queue, three events, application. activated, application. deactivated, and application. sessionending, are triggered for WPF.

For more details, see ensurehwndsource () and appfiltermessage () of the application type.

The preceding process can be described as follows:

 

 

 

System Resource Change Notification Window(Window 4 #)

Creation Time: After the mainwindow XAML of the application is deserialized into an object, you need to confirm the themestyle of the window.

Purpose: update the performance of WPF when the theme of the operating system changes and the resources associated with the system, such as systemcolors, systemfonts, power supply, and display.

After the initialization of the mainwindow that appears in the application is complete, WPF creates a hidden window to process the updated messages from system-related resources, such as wm_themechanged, wm_systemcolorchanged, wm_display, wm_powerbroadcast, and so on. Similar to the original intention of window2 #, for the sake of security, these messages are not processed through visible UI windows, but the hidden window4 # window is created for the content to process these messages, ensure that the UI window can be securely updated due to changes in the system theme and related resources.

The preceding process can be described as follows:

 

Maybe you will ask why window4 is explained first, instead of the visible window for user interaction (window3 )? This is because window3 has a lot of content, while window2 # is relatively independent from window4 #. Therefore, this article will introduce the detailed description of window3 in the next article. Stay tuned!