-Wince programming (3rd edition)-1.5 Analysis of Windows Applications

Windows ApplicationsProgramAnalysis
Windows-based programming is far different from MS-DOS-based or UNIX-based programming. As long as it is needed, any program based on MS-DOS or Unix can use GETC-or putc-style functions to read characters from the keyboard and write them to the screen. This is a typical "pull" style used by MS-DOS or Unix programs, which is process-oriented, while a Windows program uses the "push" mode. In this mode, you must write a program to respond to notifications from the operating system. For example, if a key is pressed down or you receive a command to repaint the screen.

Windows applications do not input requests from the operating system, but are generated by operating system notification applications. The operating system sends messages to the application window to complete these notifications. All windows are specific instances of the window class. Before going further, make sure you understand these terms.

Window Type
A window is an area on the screen. Except for special cases, it is basically a rectangle. The window has some basic parameters, such as location parameters -- X, Y, and Z (the window is above or below other windows on the screen) -- visibility and hierarchy -- the window forms a parent-child window relationship with the system desktop, the system desktop is also a window.

Each created window is a specific instance of the window class. A window class is a template that defines many common attributes for all windows of this class. In other words, windows of the same class have the same attributes. The most important of these shared attributes is the window process.

Window Process
In the window classCodeDefines the behavior of all windows in the same class. The Window Process processes all notifications and requests sent to the window. These notifications are either sent by the operating system to the window, telling the window that an event occurred, the window must respond, or other windows to query the information in the window.

These notifications are sent in the form of messages. A message is actually a call to the window process, with a parameter indicating the type of notification or query. When an event occurs, such as window moving, size changed, or key pressed, a message is sent. The message value is defined by windows. Applications use predefined constants, such as wm_create and wm_move, to represent messages. Because many messages can be sent, Windows provides a default processing function to process and transmit messages when the window class does not have to process a message.

Message Lifecycle
Let's look back at how Windows coordinates various messages sent to various windows in the system. Windows monitors all input of the system, such as the keyboard, mouse, touch screen, and other hardware that can generate events that affect the window. When an event occurs, the message is formed and directed to a specific window. Windows does not directly call the window process, but adds an intermediate step. The message is put in the message queue of the application that owns the window. When the application is preparing to receive a message, it extracts the message from the queue and tells windows to send the message to the appropriate window of the application.

You may think that this process involves many intermediate steps, so you are right. Let's break down this process.
1. When an event occurs, Windows forms a message and stores it in the message queue of the application with the target window. As in XP, in Windows CE, each application has its own separate Message Queue [1] (different from windows and earlier versions, at that time, there was only one message queue in the system ). Event occurrence and composition of a message are faster than the application processes them. Although it is better for the program to respond quickly or users want to see the application respond quickly, the queue allows the application to process messages at its own rate. Message Queue allows Windows to set a notification during operation and continue to complete other tasks, rather than simply responding to the application that only receives the message.

2. The application removes messages from the message queue and calls back windows to dispatch messages. It seems strange that the application receives a message from the queue, but simply calls back windows to process the message. For this method, the application obtains the message from the queue, this allows the application to preprocess messages before requesting windows to distribute messages to the corresponding window. In many cases, applications call different functions in Windows to process specific messages.

3. Send messages in windows. To be more precise, Windows calls the corresponding window process. It does not allow the application to call the window process directly, but indirectly, which allows Windows to coordinate the call of the window process with other events in the system. Although the message is not in another queue at the moment, some preprocessing may be required before Windows calls the window process. However, in any case, this scheduling method reduces the application's responsibilities and does not require the program to determine the appropriate destination window, but is the responsibility of windows.

4. process messages in the window. All window procedures have the same call parameters: the handle, message parameters, and two common parameters of the called Window instance, including message-related data. The window process uses a window handle to differentiate each instance of the window. Message Parameter, indicating the event that the window must respond. Two common items include message-related data. For example, the wm_move message indicates that the window will be moved, and a common parameter points to a structure containing the new coordinates of the window.

Note: Technically, each thread of a Windows CE application has a message queue. I will discuss threads in this book later.