Message and Message Queue

Message and Message Queue

About messages and message queues

 

Windows-based applicationsProgramIt is event-driven. They do not make explicit function calls (such as calling the C Runtime Library) to obtain input. Instead, they wait for the operating system to pass the input to them.

The operating system transmits all input to various applications. Each window has a function called a window process, which is called as long as there is an input operating system. After the window processing input, the control is returned to the operating system. For more information, see the window process.

 

Microsoft? Windows? XP: if the top-level window stops responding for several seconds, the system considers the window suspended. In this case, the system will hide the window and replace it with a ghost window in the same zcoordinate with the same size and visual attributes. To allow users to move the window, change the window size, and close the window. However, only these actions are operable because the application has been suspended. In Debugger Mode, the system does not generate a ghost window.

 

This section discusses the following topics:

? Windows messages

? Message Types

? Message routing

? Message Handling

? Message Filtering

? Posting and sending messages

? Message deadlocks

? Broadcasting messages

? Query messages

 

Windows messages

The system passes the input to the window in the form of messages. Messages can be generated by systems and applications. The system generates a message when each input event occurs, for example, when you press the keyboard, move the mouse, or click the scroll bar. The system also uses messages to respond to system changes caused by applications. For example, an application changes the system Font Resource or a window of the system. The application generates messages to allow its window to execute some tasks or communicate with other applications.

 

The system sends a message to the window and passes four parameters, Windows handle, message identifier, and two message parameters. The system uses the form handle to determine the window process to receive messages.

 

The message identifier indicates the meaning of a message in the name of a constant. When a message is received during the window, the message identifier is used to determine how to process the message. For example, wm_paint tells the window that the form customer area needs to be re-painted when it is changed.

 

The message parameter specifies the data and data location used by the window process. The meaning and value depend on the message type. A Message Parameter can contain an integer, a flag, a pointer, and so on. When messages do not use message parameters, they are set to null. In a window, the message parameters must be interpreted based on the message identifier.

 

Message Types

This section describes the two types of messages:

? System-defined messages

? Application-defined messages

System-defined messages

When the system communicates with the application, the system post and send systems define messages. It uses messages to control application operations and provides input and other information for the application to process. The application can also post or send a system to define a message.

 

Each system defines a message with a unique identifier and a constant to declare the meaning of the message. For example, wm_paint requires the window to draw its content.

 

The symbol constant specifies the type of the system-defined message, and the prefix of the constant specifies the type of the form for processing the interpreted message. The following table lists the message categories associated with the prefix.

 

Prefix message category

ABM application desktop Toolbar

BM button control

CB combo box Control

Cbem extended combo box Control

CDM Common Dialog Box

DBT Device

DL drag list box

DM default push button control

DTM Date and Time picker Control

Em Edit Control

HDM header Control

Hkm Hot Key Control

Ipm ip address control

LB list box Control

LVM List View Control

MCM month calendar Control

PBM progress bar

PGM pager Control

PSM property sheet

RB rebar Control

SB status bar window

SBM scroll bar Control

STM Static Control

TB Toolbar

TBM trackbar

TCM tab Control

TTM tooltip Control

TVM tree-View Control

UDM up-down control

WM General window

 

Common form Messages cover a large range of information and requests, including mouse and keyboard messages, menu dialog box input, form generation and management, and Dynamic Data Exchange (DDE ).

 

Application-defined messages

 

Applications can generate their own messages or communicate with forms in other processes. If the application generates its own message, the window process accepts and must provide appropriate processing.

 

The system retains the message Identifier value in the 0x0000 range in 0x03ff (WM_USER-1. These values are used by system-defined messages. Applications cannot use these values for their own messages.

 

Private window classes uses 0x0400 (wm_user) to 0x7fff message identifier

 

? If your application is marked version 4.0, you can use message-identifier values in the range 0x8000 (wm_app) through 0 xbfff for private messages.

 

The system uses registerwindowmessage to register a message. A message identifier ranging from 0xc000 to 0 xFFFF is returned. This function is used to ensure that the entire system is unique.

 

Message routing

The system has two methods to pass messages to the window. Post a message to a first-in-first-out message queue. Temporary memory object defined by the system. And send messages directly to the window.

A message sent to a message queue is a queue message, which is input by the mouse or keyboard, such as wm_mousemove, wm_lbuttondown, wm_keydown, and wm_char messages. It also includes the timer, refresh, and exit: wm_timer, wm_paint, and wm_quit. Other messages sent directly to the window are called non-queue messages.

 

Queued messages

 

The system can display any number of forms at the same time. In order to pass the mouse and keyboard messages to the appropriate window, the system uses message queue.

 

The system maintains a system message queue and a message queue for each GUI thread. To avoid creating a message queue for non-Gui, no message queue is generated for all threads. Only when the thread calls the GDI function for the first time, the system creates a message queue for the thread. As long as the user moves the mouse, clicks and clicks, the driver converts it to a message and places them in the system message queue. The system moves them from the system message queue, checks their target window, and sends them to the Message Queue of the thread that created the target window. The thread Message Queue receives mouse and keyboard messages for all windows created by this thread. The thread deletes the message system call window for processing.

Wm_paint is an exception. The system always posts messages to the end of the message queue. This ensures that the window receives messages in the FIFO order. However, wm_paint is passed only when no other message exists. Multiple wm_paint messages in the same window are merged into one wm_paint message, and all invalid regions are merged into one invalid region. Merging wm_pain reduces the number of refresh windows.

 

The system sends messages to the thread queue by filling in the MSG structure and copying it to the message queue. The MSG structure includes the window handle, message identifier, and two message parameters. The time when the message is posted, and the cursor position. The thread can use postmessage and postthreadmessage to send messages to its own message queue or to another queue.

 

Applications can use getmessage to delete messages from a message queue. You can use peekmessage to check a message without deleting it. This function fills messages in the message queue into the MSG structure.

 

When a message is deleted from the message queue, the application can use dispatchmessage to send the message to the window for processing. Dispatchmessage has a pointer to the MSG structure filled by getmessage or peekmessage, passing the window handle, message identifier, and message parameters to the window process. However, it does not pass the message sending time and the mouse position. The application can obtain this information through getmessagetime and getmessagepos.

The thread can use waitmessage to send control to other threads. When the Message Queue does not have a strong message queue, this function suspends the thread and does not return until new messages are placed in the message queue.

 

You can call the setmessageextrainfo function to associate a value to the Message Queue of the current thread. Call getmessageextrainfo to obtain the value associated with the last message obtained through getmessage or peekmessaage.

 

Nonqueued messages

 

Messages that are sent directly to the window without being queued Bypass System queues and thread message queues. The system sends a non-queued message to notify a window event. For example, when a user activates a new application window, the system sends wm_activate, wm_setfocus, and wm_setcursor. These Message notification windows are activated, keyboard input is passed directly to the window, and the mouse moves in the current window. Non-queued messages can also be generated when the application calls system functions. For example, when the program calls the setwindowpos system to send the wm_windowposchanged message.

 

Some functions also send unqueued messages such as broadcastsystemmessage, broadcastsystemmessageex, sendmessage, sendmessagetimeout, and sendpolicymessage.

 

Message Handling

 

The application must remove and process messages sent to the message queue. A single-threaded application usually uses a message loop in winmain to remove and split messages to the window processing time. Multi-threaded applications can contain message loops in the thread of each creation window.

 

Message Loop

A simple message loop consists of one function call to each of these three functions: getmessage, translatemessage, and dispatchmessage. note that if there is an error, getmessage returns-1 -- thus the need for the special testing.

Show example

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 message queue and copies it to the MSG structure. It returns a non-zero value unless a wm_quit message is encountered. Otherwise, it returns 0 and ends the loop. In a single-threaded application, ending the message loop is often the first step in closing the application. The application can use postquitmessage to end its own message loop. It is usually called in the wm_destroy message in the main window.

 

If you pass a window handle as the second parameter to getmessage, only messages in the specified window can be obtained from the queue. Getmessage can also filter messages from the message queue to only accept messages that fall within the range of the message queue. For details, see message filtering. A thread loop must contain translatemessage if the thread accepts character input from the keyboard. Each time a user presses a key, the system generates a virtual key message. A virtual key message contains a virtual key to indicate that the key is pressed, which is not its character value, to obtain this value, the message loop must call translatemessage to convert the virtual key to the character message wm_char and then return it to the application message queue. By forwarding it to a window, the character message is deleted.

 

The dispatchmessage function distributes messages to the window handle associated with the MSG structure. If the window handle is hwnd_topmost, dispatchmessage is used to distribute messages to all top-level windows in the system. If the handle is null, dispatchmessage does not do anything.

The application winner thread starts its message loop after creating at least one window during initialization. Once the message loop is started, messages are continuously obtained from the thread queue and then distributed to the appropriate window. The message loop ends after wm_quit is obtained through getmessage and deleted from the queue.

 

A message column only requires one message loop, even if the program contains many windows. Dispatchmessage always sends messages to the appropriate window because the MSG structure contains the handle of the window to which the message belongs.

 

You can modify the message loop in various ways. For example, you can obtain a message from a message queue without distributing it to a window. It is useful when an application sends a message without specifying a window. You can use getmessage to obtain a specific message, while retaining other messages in the message queue. It is useful when you need to change the FIFO order.

 

The application must convert keyboard messages to wm_command messages by using the acceleration key. Therefore, the message loop must include the translateaccelerator function. For more information, see the acceleration key.

 

If the thread uses a non-modal dialog box, the message loop must include isdialogmessage so that the non-modal dialog box can obtain keyboard input.

 

Window procedure

 

The Window Process is a function used to process all messages sent to this window. Any window class has a window process. A window of the same class uses the same window process to respond to messages.

 

When the system sends a message to a window, it passes the message data as a parameter. The window process uses parameters to generate appropriate behavior.

 

A window usually does not ignore messages. If the messages are not processed, the messages will be sent back to the default processing. In the window process, call defwindowproc to handle this problem. The Window Process must return a value as its message processing result. Most windows process only a small part of messages and pass other messages to the system through defwindowproc for default processing.

 

Because the window process is shared by windows of the same class, it can process messages for different windows. Check the window handle in the message to find the window affected by the message. For more information, see window procedures.

 

Message Filtering

 

The application can select a specific message from the message queue. Use getmessage or peekmessage and specify a message filter. This filter is a range of message identifiers, a form handle, or both. Getmessage and peekmessage use a filter to obtain the messages from the message queue. It is useful when an application is looking for a message in the message queue.

 

When an application filters messages, it must ensure that messages that meet the filtering conditions can be sent. For example, if the application filters wm_char in the window and cannot obtain keyboard input, getmessage does not return. This suspends the application.

 

Posting and sending messages

 

The application can send and post messages. By copying messages to the message queue, that is, post messages, the send message directly transmits the message data to the window as a parameter.

You can use postmessage to post messages, sendmessage, broadcastsystemmessage, sendmessagecallback, sendmessagetimeout, sendpolicymessage, or senddlgitemmessage to send messages.

 

Posting messages

 

The application post message notifies the specified form to execute the task. Postmessage can create a MSG structure and copy it to the message queue. The message loop finally captures the message and delivers it to the appropriate window.

 

When a null handle is passed to postmessage without specifying a window, the message is sent to the Message Queue of the current thread. The application must process the message in message processing. This is a method for sending messages to the entire application.

 

Occasionally, you can use the hwnd_topmost parameter as the handle parameter to send messages to all top-level windows.

 

When the message queue is full, the postmessage does not send the message. The application needs to check the return value of the postmessage function to determine whether the message is sent or not.

 

Sending messages

 

Send a message to notify the window to immediately execute the task. Sendmessage sends a message to a specified window. The function returns a message only after the window process is complete. Parent and Child windows usually use send messages to communicate with each other. For example, a parent window has a text box as its child window. It can set text for the text box by sending messages to the Child Window. The subwindow can also send messages with text changed to the parent window.

 

Sendmessagecallback also sends messages to the window of the specified window, but he returns immediately. After the message is processed in the window process, the system calls the specified callback function. For details about the callback function, see sendasyncproc.

 

Occasionally, you can send messages to all top-level windows in the message system. For example, the application changes the system time. It must use hwnd_topmost as the handle parameter to send a wm_timechange message to notify all top-level windows. You can also specify lpdwrecipients as bsm_applications and broadcast it to all applications using the broadcastsystemmessage function.

 

You can use the insendmessage or insendmessageex function to determine whether the message it processes is sent by other threads by calling sendmessage. This capability is useful when message processing depends on the origin of the message.

 

Message deadlocks

 

A thread can call sendmessage to send messages to other threads. This thread cannot continue to execute until the message receiving window is returned. If the yields control is enabled when the thread that receives the message processes the message, the message in the sending thread will never be executed because it is waiting for sendmessage to return. If the receiving thread and the sending line idiom are associated with the same message queue, it may cause a message deadlock.

Note that the processing thread need not yield control explicitly; calling any of the following funwing can cause a thread to yield control implicitly.

The accept thread does not require explicit yield control. Any of the following functions causes a thread to define yield control.

 

? Dialogbox

? Dialogboxindirect

? Dialogboxindirectparam

? Dialogboxparam

? Getmessage

? MessageBox

? Peekmessage

? Sendmessage

To avoid potential deadlocks, you can use sendpolicymessage or sendmessagetimeout. Otherwise, insendmessage or insendmessageex will be used in the window process to determine whether the message is sent by another thread. When any previous function window is called, insendmessage or insendmessagex will be called first. If the function returns true, the window process must call replymessage before the thread yeild control is triggered.

 

Broadcasting messages

 

Each message includes a message identifier and two parameters, wparam and lparam. The message identifier uniquely represents the meaning of the message. The parameter provides additional message-related information, but the wparam parameter is usually a type value that provides more message information.

 

Message broadcasting simply sends messages to multiple receivers in the system. To use the broadcastsystemmessage function to broadcast messages, you must specify one or more receiver types, which can be applications, installable drivers, network drivers, and system-level device drivers. The system sends messages to all members of the specified type.

 

The system broadcasts messages to respond to changes in system device drivers or components. Drivers or related components broadcast messages to applications and other components to notify them of these changes. For example, components responsible for disk response broadcast messages as long as the floppy drive detects media changes, such as when a user inserts a disk into a drive.

 

The system broadcasts messages to the receiver in the following sequence: system-level device drivers, network drivers, installable drivers, and applications. This means that if the system-level device driver is always the first receiver to have the opportunity to respond to messages. In the receiver type, no driver can accept a message before other drivers. That is, a message to a specific driver must have a globally unique identifier so that other drivers that do not care about the message do not process it.

 

You can also broadcast messages to all top-level windows by specifying hwnd_broadcast in functions such as sendmessage.

The application receives messages through the window process in the top-level window. Messages are not sent to subwindows. The service can receive messages through the window process or their service control functions.

 

Query messages

 

You can create custom messages and use them to adjust the behavior between your application and other components. This is very useful if you have created your own installable drivers and system device drivers. Your driver and the application using this driver can transmit information to each other through custom messages.

 

To poll recipients for permission to carry out a given action, use a query message. You can call broadcastsystemmessage by setting bsf_query in the dwflags parameter. The receiver of each query message must return true to send the message to the next receiver. If either receiver returns broadcast_query_deny, the broadcast immediately stops function and returns 0.

 

Windows 95/98/me: you can create installable drivers for broadcasting and message processing. An installable drivers is a DLL for exporting the driverproc function. The driver receives messages through its driverproc. Installable drivers is typically used to support multimedia devices, such as sound boards. It can also be used for other devices and purposes.

 

Windows 95/98/me: The Network Driver provides applications with the following supported DLLs. System-level device drivers are system-specific executable components that provide direct access to and management of computer hardware. How these components process system messages exceeds thisArticle.