Windows Message Mechanism highlights

The Message mechanism is a core mechanism of Windows, and the best information about the Message mechanism is MSDN: Messages and Message Queues. After reading the Message mechanism, I think it is quite rewarding:

Window Process

Each Window has a callback function (WndProc), which has four parameters: Window Handle, Message ID ), and two message parameters (wParam, lParam). When the window receives a message, the system calls this window to process the message. (So called callback function)

Message Type
System-Defined message)
Messages pre-defined in the SDK, which are not user-defined, fall between [0x0000, 0x03ff] and can be divided into the following three types:

• Windows Message)
  It is related to the internal operation of the window, such as creating a window, drawing a window, and destroying a window. It can be a common window, a Dialog, or a control.
  For example: WM_CREATE, WM_PAINT, WM_MOUSEMOVE, WM_CTLCOLOR, WM_HSCROLL...
• Command Message)
  It is related to processing user requests. For example, when you click a menu item or toolbar or control, a command message is generated.
  WM_COMMAND, LOWORD (wParam) indicates the menu item, toolbar button or control ID. If it is a control, HIWORD (wParam) indicates the Control Message Type
• Notify Message)
  Control notification Message, which is the most flexible Message format. Its Message, wParam, and lParam are respectively WM_NOTIFY, and the Control ID points to the NMHDR pointer. NMHDR contains the control notification content, which can be expanded as needed.

Application-Defined Messages)
The range of custom messages is as follows:
WM_USER: 0x0400-0x7FFF (ex. WM_USER + 10)
WM_APP (winver> 4.0): 0x8000-0xBFFF (ex. WM_APP + 4)
RegisterWindowMessage: 0xC000-0xFFFF

Message Queue)
There are two types of message queues in Windows

• System Message Queue)
  This is the only Queue in the system. The device driver (mouse, keyboard) will convert the operation input into a message in the system Queue, the system then places the message to the queue (thread-specific message queue) of the thread in which the target window is located for medium waiting for processing.
• Thread-specific Message Queue)
  Every GUI thread maintains such a thread message queue. (This queue is created only when the thread calls the GDI function. It is not created by default ). Then the messages in the thread message queue are sent to the corresponding Window Process (WndProc) for processing.
  Note: In the thread message Queue, WM_PAINT and WM_TIMER are processed only when there are no other messages in the Queue, and WM_PAINT messages are merged to improve efficiency. All other messages are processed in FIFO mode.

Queue Messages (Queued Messages) and Non-queue Messages (Non-Queued Messages)

• Queue message (Queued Messages)
  The message is saved in the message queue first, and the message loop will retrieve the message from the queue and distribute it to each window for processing.
  Such as mouse and keyboard messages.
• NonQueued Messages)
  Messages are directly sent to the window without passing through the system message queue and thread message queue.
  Example: WM_ACTIVATE, WM_SETFOCUS, WM_SETCURSOR, WM_WINDOWPOSCHANGED
  Note: The message sent by postMessage is a queue message, which will Post the message to the Message Queue. The message sent by SendMessage is a non-queue message and is directly sent to the window for processing.

PostMessage (PostThreadMessage), SendMessage
PostMessage: place the message in the thread message queue of the specified window and then return immediately. PostThreadMessage: Put the message in the message queue of the specified thread and return immediately.
SendMessage: send the message directly to the window for processing. After processing, the message is returned.

GetMessage, PeekMessage
PeekMessage returns the message that can be retained immediately.
GetMessage: If a message is returned, the message will be deleted.

TranslateMessage, TranslateAccelerator
TranslateMessage: converts a virtual-key message into a character message and stores it in the message queue of the current thread. The message is retrieved and processed in the next cycle.
TranslateAccelerator: maps the shortcut key to the corresponding menu command. It converts WM_KEYDOWN or WM_SYSKEYDOWN to the corresponding WM_COMMAND or WM_SYSCOMMAND message in the shortcut table, and then sends the converted WM_COMMAND or WM_SYSCOMMAND to the window for processing. After processing, the system returns the result.

Message Deadlocks)
Assume there are threads A and B. Now there are the following steps:

• Thread A SendMessage is sent to thread B, and A is returned after the message is processed in thread B.
• Thread B receives A message from thread A and processes it. During the processing process, thread B also sends messgae to thread A and waits for the response from thread.

At this time, thread A is waiting to return from thread B and cannot process messages sent from thread B. This leads to the mutual wait of thread A and thread B, forming A deadlock. Multiple Threads can also form a circular deadlock.
You can use sendpolicymessage or SendMessageTimeout to avoid deadlocks.

 

BroadcastSystemMessage
Generally, all the messages we come into contact with are sent to the window. In fact, the message receiver can be a variety of applications ), installable drivers, network drivers, system-level device drivers, etc,
The BroadcastSystemMessage API can send messages to the above system components.

 (Moved from the previous blog)