Windows message and Message Queue details

Windows message and Message Queue

 

Unlike MS-dos-based applications, Windows applications are event-driven (Message-driven. They do not explicitly call functions (such as C Runtime Library calls) to obtain input, but wait for Windows to pass the input to them. In Windows, input events of an application are transmitted to various windows. Each window has a function called window message processing function. The window message processing function processes various user input. After processing, the control is returned to the system. Window message processing functions are generally specified when a window is registered. You can declare and implement window message processing functions in typical SDK programs.

 

For Windows XP: if the top-level window stops responding to a message for more than a few seconds, the system determines that the window does not respond. In this case, the system will hide the window and generate a shadow (ghost) window to overwrite it. The Shadow window has the same Z axis sequence, position, size, and display attributes. The Shadow window allows you to move, resize, or even close it (close the window that stops responding ). At this time, only these actions are allowed. In debugging mode, the system does not generate a shadow window.

 

This section discusses the following topics:

Windows messages

1. Message Type

2. message transmission

3. Message Processing

4. Message Filtering

5. Post message and send message

6. Message deadlock

7. Broadcast messages

8. query messages

 

1. Windows messages

Windows transmits user input to the window in the form of messages. Messages can be generated by systems and applications. The system generates a message for each input event,

For example, a user clicks the mouse, moves the mouse or scroll bar, or the application changes certain attributes of the system. For example, the system changes the Font Resource and changes

Size. In addition, the application can generate a message, send a notification to specify its form to execute certain tasks or interact with other applications.

When a Windows system sends a message to a window message processing function, four parameters are passed: Window handle, message identifier, and two DWORD values (Message parameters ).

The window handle identifies the target window of the message. Windows uses it to determine which window message processing function receives the message.

 

A message identifier is a constant with a name to indicate the meaning of a message. When a window handler receives a message, it determines how to process the message based on the message identifier. For example, the message identifier wm_paint indicates that the client area of the window has changed, must be repainted. The Message Parameter (DWORD Value) specifies the address of the transmitted data or data. The message parameter can be an integer value and a pointer value. It can also be null.

A window process must determine how to interpret the message Parameters Based on the message identifier.

2. Windows Message Type

This section describes two types of messages:

(1) system-defined messages

(2) application-defined messages

System-defined message

The operating system sends a message to the application to communicate with the application. The operating system controls the running of applications through messages, and transmits user input and other useful information to the applications.

An application can also send system-defined messages through which the application controls the operation of windows created using the registration window class.

Each system-defined message has a unique message identifier and a corresponding symbolic constant (defined in the Windows SDK header file ). A symbolic constant usually indicates the category of a message defined by the system. Different prefixes indicate different classes. The following is a common classification:

Prefixmessage category

 

WM General window (General window)

ABM application desktop toolbar (Application desktop toolbar)

BM button control)

CB combo box control (combo Control)

Cbemextended combo box control (Extended combo box Control)

CDM Common Dialog Box (Common Dialog Box)

DBT Device)

DL drag list box (drop-down list)

DM default push button control (default button control)

DTM Date and Time picker control (Date and Time Selection Control)

Em Edit Control)

HDM header Control)

Hkm Hot Key Control)

Ipm ip address control (IP address control)

LB list box control (list box Control)

LVM List View Control (List View Control)

MCM month calendar control (mathematical calendar Control)

PBM progress bar (progress bar Control)

PGM pager control ()

PSM property sheet (property page)

RB rebar Control)

SB status bar window (status bar Control)

SBM scroll bar Control)

STM Static Control)

TB toolbar (toolbar)

TBM trackbar (tracking bar)

TCM tab control (Tab Control)

TTM tooltip control ()

TVM tree-View Control ()

UDM up-down control ()

(2) application-defined messages

Applications can create custom messages to communicate with their own windows and other processes. If an application creates its own message, the window handler can parse the information and process it accordingly.

Value Range of the message Identifier value:

The system retains a message range from 0x0000 to 0x03ff (0x03ff is equal to wm_user-1). The value in this range is a system-defined message. Applications cannot use these values as their own custom messages.

The value from 0x0400 (wm_user) to 0x7fff is reserved for the application. Applications can use values in this range to define their own messages.

If the main version of your operating system (Windows version) is version 4.0, you can use the value between 0x8000 (wm_app) and 0xbff to define your own message.

In addition, when the application can call the registerwindowmessage function to register a message, the operating system returns a message identifier between 0xc000 and 0xffff. Make sure that the returned value is unique in the system. Therefore, it can avoid conflicts with messages used by other applications.

3. Message Distribution

In Windows, two methods are used to distribute messages to one window. The function is used to process messages. One is to put messages in a Message Queue (first-in-first-out queue), and the other is not in a message queue, send messages directly to the window message processing function to allow the window processing function to process messages.

A message sent to a message queue is called a queue message (queued messages ). They are mainly user input events, such as the mouse or Keyboard Message disk, which contains wm_mousemove messages, wm_lbuttondown, wm_keydown, and wm_char messages. There are also some others, including wm_timer, wm_paint, and wm_quit. Most other messages, which are directly sent to the window, are called non-queued messages ).

(1) Queue (queued) messages

Windows displays any number of windows at the same time. In this case, the system uses message queue to correctly distribute keyboard and mouse events to the correct window.

Windows maintains a system message queue and maintains a separate thread message queue for each GUI thread. To avoid the overhead of creating thread message queues for non-Gui threads, no message queue is created for all threads during initialization. The system creates a message queue for a thread only when the thread calls the GDI function for the first time. Therefore, non-Gui threads do not have message queues.

Whenever you move the mouse and click a button or keyboard, the device driver of the mouse or keyboard converts the input to a message and places the message in the system message queue. When you delete windows, you will check your message queue. If the message queue is not empty, a message is taken out and deleted each time, and the target window of the message is determined, put the message in the thread message queue of the thread that created the window. The thread Message Queue receives all the mouse and keyboard messages in the window created by the thread. The thread then deletes the information from the queue and tells the system to dispatch the information to the corresponding window message processing function.

In addition to wm_paint, wm_timer, and wm_quit messages, the system always distributes messages placed at the end of the message queue. This ensures that a window receives messages in the order of first-in and first-out. Wm_paint, wm_timer, and wm_quit messages will be stored in the queue all the time, and will be distributed to the window message processing function only when there are no other messages in the queue. In addition, multiple wm_paint messages in the same window are merged into one wm_paint message, and all invalid parts in the customer zone are also merged. This is to reduce the number of times the customer area is repainted in the window.

When Windows transmits a message to a thread message queue, it first fills in a MSG structure and then copies the MSG structure to the message queue. The message in MSG includes the target window, message identifier, two message parameters, the time when the message is distributed, and the cursor position. A thread can use the postmessage or postthreadmessage function to send messages to its own message queue or message queues of other threads.

Applications can use the getmessage function to delete messages from their own message queues. The peekmessage function is used to view messages without deleting them.

The peekmessage function returns a MSG structure with message information.

After a message is deleted from a message queue, the application can use the dispatchmessage function to instruct the system to send the message to a window message processing function. The dispatchmessage parameter is a pointer to the MSG structure obtained by calling getmessage or peekmessage. Dispatchmessage transmits the window handle and message identifier to the window message processing function, which does not transmit the message distribution time and the cursor position. The application can call getmessagetime and getmessagepos when processing a message to obtain the information.

A thread can use the waitmessage function to surrender its control. When there is no message in its message queue, calling the waitmessage function suspends the thread until there is a message in its message queue.

You can call the setmessageextrainfo function to associate a value with the message queue of the current thread. Call the getmessageextrainfo function to obtain the value associated with the last message obtained by the getmessage or peekmessage function. You can go to msdn to view more information about these functions.

(2) Non-queue (nonqueued) messages

The window message processing function for sending nonqueued messages to the destination immediately bypasses the system message queue and thread message queue. The system usually sends a nonqueued message to notify events that will affect the window. For example, when a user activates a new application window, the system will send some column messages to the window, including wm_activate, wm_setfocus, and wm_setcursor. These Message notification windows are activated, keyboard input is directed to the window, and the mouse cursor is also moved to the window boundary.

Nonqueued messages may also come from application calls to system functions. For example, a wm_windowposchanged message is sent after the system calls the setwindowpos function to move a window. Some functions also send nonqueued messages, including broadcastsystemmessage, broadcastsystemmessageex, sendmessage, sendmessagetimeout, and sendpolicymessage. For more information about these functions, see msdn.

Message Processing

The application must delete and process the messages sent to its thread message queue. A single-threaded application usually processes messages in the winmain function in a proper window by deleting and distributing messages. Multi-threaded applications can create a window message loop in each thread. The following section describes a message

How the cycle works and describes the functions of the window message processing function:

(1) message loop

(2) window processing functions

Message Loop

A simple message loop includes calling the following functions: getmessage, translatemessage, and dispatchmessage. Please note that if there is an error, getmessage returns-1-. Therefore, you need to test its return value to determine if it is-1.

Code snippet:

...

MSG;

Bool Bret;

 

While (Bret = getmessage (& MSG, null, 0, 0 ))! = 0)

{

If (Bret =-1)

{

// Handle the error and possibly exit

}

Else

{

Translatemessage (& MSG );

Dispatchmessage (& MSG );

}

}

 

The getmessage function obtains a message from the queue and copies the message content to a MSG structure. It returns a non-zero value. Unless a wm_quit message is encountered, this type returns false and ends the message loop. In a single-threaded application, ending a message loop is often the first step in closing the application. The application can call the postquitmessage function to respond to wm_destroy and end the message loop.

If you specify a window handle as the second parameter of getmessage, getmessage only obtains messages related to this window in the message queue. Getmessage can also filter messages in the queue and only get messages within the specified range. For more information about message filtering, see message filtering.

The message loop of the thread must include the translatemessage. If the thread needs to accept the input of keyboard characters. Each time you press a key, the system generates the corresponding virtual key messages (wm_keydown and wm_keyup ). A virtual key message contains a virtual key code that identifies the pressed key, rather than its related character values. To obtain this value, the message loop must contain the translatemessage, which is used to translate a virtual key message into a character message (wm_char) and put it in the message queue of the application. After several cycles, the wm_char message is sent to a window.

The dispatchmessage function sends messages to the window associated with the window handle in the MSG structure. If the window handle is hwnd_topmost and dispatchmessage, the message is sent to all top-level windows of the operating system. If the window handle is null, dispatchmessage does not do anything.

After the main thread of an application is initialized, the system starts the message loop of the application and creates at least one window. Once started, the message loop continuously deletes messages from the message queue of the thread and distributes them to the corresponding window. When the getmessage function obtains the wm_quit message from the message list, the message loop ends.

A message queue only requires one message loop, even if an application package contains multiple windows. Dispatchmessage always schedules messages to the correct window because messages in each queue are in the MSG structure and contain the handle of the window to which the message belongs.

You can modify the message loop in multiple ways. For example, you can delete messages from the queue but do not distribute them. This is useful when sending messages that do not have a destination window. You can also use getmessage to retrieve only the specified message, which is useful if you must temporarily bypass the normal FIFO order of the message queue.

When an application uses a shortcut key, it must be able to convert keyboard messages to command messages. Therefore, the message loop of an application must include the translateaccelerator function call. For more information about shortcut keys, see keyboard accelerators.

If a thread uses a mode-free dialog box, the message loop must include the isdialogmessage function so that the dialog box can receive keyboard input.

(2) window message processing functions

The window message function receives and processes all messages sent to the window. Each window class has a window message processing function. Each window created by this class uses the same window message processing function.

The system sends the message to a window program and transmits the message information to the window message processing function. The window message processing function checks the message identifier, identify and process different messages based on the passed parameters,

A window process usually does not ignore a message. If the message is not processed, it must be sent to the system's default window message processing function. Whether to call the defwindowproc function to execute a default processing and return a processing result. The window program must then return this value as the result of message processing. Most window message processing functions process only a small number of messages and return others to the system's default window message processing function.

Because the window message processing function is shared by all windows belonging to the same window class, it can process messages of several different windows. To determine a specific window message, the window message processing function can check the window handle in the message structure.