Messages and message queues for windows operating systems, operating system queues

Messages and message queues for windows operating systems, operating system queues
About messages and message queues
Unlike MS-DOS-based applications, Windows-based programs are event-driven. They do not call any display to obtain the input. Instead, wait for the system to pass it to them.


The system passes all input windows to the application. Each window has a function called a window process, which is used to process all input to the window. The window processing process processes the input and returns the control to the system.


If a top-level window stops responding to a message for more than two seconds, the system considers the window as non-responsive. In this case, the system hides the window and replaces the window with a ghost window with the same Z sequence, position, size, and visualization attributes. In this case, the user is allowed to move it, or change its size, or even close the application. Then, this is only the action that can be done, because the application does not respond now. When debugging, the system does not generate a ghost window.


This section discusses the following topics:
Windows messages
The process in which the system sends messages to the window. Both the system and application can generate messages. Each time an event is input, the system generates a message, for example, a control that is used for hitting, moving the mouse, or clicking the scroll bar. System changes caused by applications may also lead to system messages. For example, an application changes the font resource pool of the system or the size of its own window. An application can generate such a message that directs its window to directly execute tasks or interact with other application windows.


Message category:
System-defined message
When the system interacts with the application, the system sends system messages to control the operation of the application and send input or other messages to the program. Applications can also send system messages, which are usually used by applications to control window behaviors created through pre-registered window classes.


The message constant flag specifies the type of the predefined message to which the message belongs. Determine the types of messages that can be translated or processed by prefix. As follows.
AMB/ABN === application desktop toolbar
Acm/acn === animation control
Cb/cbn === combobox control
Ccm === generatl control
Cdm === common dialog box
Dfm === default contex menu
Dl === drag list box
Sb === status bar
Tvm/tvn === tree view contro
Udm/udm === up-down controm
Wm = general
......
Tcm/tcn === tab control
{
Clipboard Messages Clipboard Notifications Common Dialog Box Notifications Cursor Notifications Data Copy Message Desktop Window Manager Messages Device Management Messages Dialog Box Notifications Dynamic Data Exchange Messages Dynamic Data Exchange Notifications Hook Notifications Keyboard Accelerator Messages Keyboard Accelerator Notifications board Keyboard input Messages Keyboard Input configurations Menu configurations Mouse Input configurations Multiple Document Interface Messages Raw Input configurations Scroll Bar configurations Timer configurations Window Messages Window configurations
}


In general, windows messages cover a wide range, including the mouse and keyboard, menu, dialog box input, Window Creation management, and DDE Dynamic Data Exchange.




Messages defined by the application
An application can create a message, and its own window can be used or used to interact with other processes.


The message tag value is applied as follows:
1. The system retains 0x0000-0x03ff (wm_user-1), which cannot be used by applications for private messages
2.0x0400 (WM_USER)-0x7fff can be used for private messages
3. If the application is on the 4.0 system, you can use 0x8000 (wm_app)-0xbfff for private messages.
4. The value returned by RegisterWindowMessage is between 0XC000-0XFFFF. The return value of this function can avoid conflicts caused by other processes using the same value.


Message routing
Two methods are used to display the message route in the window process: post messages are first-in-first-out message queues, and message queues are system-defined memory objects that temporarily store messages, and direct sending messages to the window.


Queue Message 1
The system can display any number of windows at the same time. To route the mouse and keyboard input to the correct window, the system uses message queue.


The system maintains a system message queue and maintains a thread-specific message queue for each GUI thread. To avoid creating too many message queues for non-GUI threads, all threads do not have message queues when they are created. The system only creates a thread message queue when a thread initiates a special user function for the first time. A message queue is created if no GUI function is called.


Not understand:
The system creates a thread-specific message queue only when the thread makes its first call to one of the specific user functions; no GUI function callresult in the creation of a message queue.


Queue Message 2
At any time, the user moves the mouse, clicks the button or clicks the keyboard, and the mouse or keyboard driver converts these inputs into messages and places them in the system message queue. The system also removes them from the system message queue when detecting their object window. Then they are sent to the window creation thread in the message-related window. Threads receive all mouse and keyboard messages from their message queues. Threads delete messages from their queues and instruct the system to send them to the correct window for processing.




Except for WM_PATIN, WM_TIMER, and WM_QUIT messages, the system always sends them to the end of the message queue to ensure the FIFO sequence of the input messages. Only after there are no other messages in the message pair, WM_PATIN, WM_TIMER and WM_QUIT are pushed forward to the window processing process. Then, multiple WM_PAINT messages will be merged into one to determine that all clients are in a separate region. WM_PATINT is merged to reduce the number of times the window is rushed back to the customer area.


After a message is deleted from the message queue, the application uses the DispatchMessage function direct to send the message to the window for compact processing. DispatchMessage does not send the message location and time to the window. The application can use the GetmessageTime and GetMessagePos functions.


When there is no message in the message queue, the thread can use the WaitMessage function to hand over the Controller to other threads. This function suspends the thread and returns only when a new message arrives.


You can also call SetMessageExtraInfo to append a value to the current message queue and get this value through GetMessageExtraInfo.


Non-queue message
The system and thread message queues are bypassed. Non-queue messages are directly sent to the window. The system typically sends a non-queue message to notify a window, and an event affects it. For example, when a user activates a new window, the system sends the WM_ACTIVATE, WM_SETFOCUS, and WM_SETCURSOR messages to the window. These Message notification windows have been activated. The keyboard input points to the window, and the mouse cursor has been moved to the window border. When an application calls certain system functions, non-queue messages are also displayed. For example, when the application calls SetWindowPos, the system sends a WM_WINDOWPOSCHANGED message.


Some messages send non-queue messages: BroadcastSystemMessage, BroadcastSystemMessageEx, SendMessage, SendMessageTimeout, and sendpolicymessage.


Message Processing
Multi-threaded applications include a message queue in each thread that creates a window.




MSG 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 );
}
}
An application can call PostQuitMessage to end its own message loop. It is typical to respond to the WM_DESTROY message in the main window of the application.


PostMessage sends a message with a NULL window handle. The message will be placed in the current thread message queue, and the application must process the message. PostMessage can also send messages to all top-level windows through the HWND_TOPMOST handle.


PostMessage is always able to send messages successfully. It is usually an incorrect assumption. For example, the message queue is full. An application should check the returned value of PostMessage. If the message fails, you need to resend the message.


SendMessage is usually the interaction between the user's parent and child windows.


The SendMessageCallback function sends a message and returns it immediately. After processing the message, the system calls the specified callback function. For details about the callback function, see SendAsyncProc.


Occasionally, you may want to send messages to all top-level windows. For example, if the application changes the time, you can use SendMessage, create HWND_TOPMOST, and send WM_TIMECHANGE. You can also use the BroadcastSystemMessage function and specify BSN_APPLICATIONS for the lpdwRecipients parameter.


Message deadlock
1. SendMessage is returned only after the processing of the window process is completed. If the control of the thread in which the window process is located is abandoned, the deadlock occurs in the morning.
2. If the receiving thread is appended to the same message queue as the sending thread, it will also cause the application to send deadlocks.


Note: The thread that is receiving the message should not show giving up control; calling the following function will cause the thread privacy to give up control.
DialogBox
• DialogBoxIndirect
• DialogBoxIndirectParam
• DialogBoxParam
• GetMessage
• MessageBox
• PeekMessage
• SendMessage


To avoid potential deadlocks, consider using sendpolicymessage or SendMessageTimeout. Otherwise, you can use InSendMessage or InSendMessageEx to check whether the received message is from another thread. when processing a message, before calling any function in the above list, the window process should call InSendMessage (Ex ). if TRUE is returned, the window must call the ReplyMessage function before yeild.


System broadcast message-Omitted






Summary:
1. messages are divided into system-defined messages and user-defined messages. Their IDs have their own ranges.
2. By default, each thread does not have a message queue. The system creates a message queue for a thread only when it calls a user interface for the first time (such as creating a window.
3. The system itself maintains a system message queue, and then maintains a dedicated thread message queue for each GUI thread.
4. The mouse, keyboard, and other drivers first convert the event into a message placed in the system message queue, and then the system uses a window to determine which thread message queue to put it in.
5. The thread cyclically fetches and processes the message, sends the message to the system, and the system calls the corresponding Window Process of the message.
6. PostMessage may fail, for example, the queue is full.
7. Avoid message deadlocks. For example, before receiving a message window, you need to check whether the message is sent from other threads. Otherwise, other threads will wait for a long time. In fact, I don't think it can be a deadlock here. After all, it is possible to execute it again. It's just a short time.
8. Pay attention to special messages such as wm_paint, wm_timer, and wm_quit.
9. system pre-defined messages are mostly control messages, notification messages, system broadcast messages, and so on.




Message functions:
---
DispatchMessage


LONG DispatchMessage (
Const MSG * lpmsg
);
1. This function distributes messages to the window through the system.
2. If it is a timer message, the lParam parameter is not empty, and lParam points to a function address. The called function is not a window process.
---


GetMessage
The application uses the return value of this function to determine whether to terminate the message loop and exit the program.
This function gets messages related to hWnd or its subwindows.
---
DWORD GetMessagePos (void );
This function returns the x and y coordinates of the message. Under Multiple monitors, there may be negative values.
---


GetMessageQueueReadyTimeStamp
GetTickCount)
---
 


GetMessageSource
MSGSRC_SOFTWARE_POST keyboard Message from software (postmessage marked as software). MSGSRC_HARDWARE_KEYBOARD surface message from keyboard. MSGSRC_UNKNOWN message source unknown
---
DWORD GetQueueStatus (
UINT flags
);
Type of the message in the Message Queue
Flags is the type of message to be detected.
The returned value is a byte value indicating the type of the message in the message queue. The low byte indicates the type of message that is added to the queue from the last GetQueueStatus, GetMessage, or PeekMessage.
---
InSendMessage
It is used to determine whether the message processed in the current window is called by SendMessage from other threads.
---
PeekMessage
1. This function checks whether a message exists in the thread message queue and places the message in the parameter struct.
2. If the hWnd parameter is-1, only the message with hWnd = NULL is returned. This message comes from PostThreadMessage.
3. Pay attention to the parameter wRemoveMsg
4. If the application calls PeekMessage when creating the top-level window, the window is created at the end of Z-Order. You need to explicitly call SetForegroundWindow after PeekMessage. If the application and a front window exist, the new window is prefixed.
---
PostMessage
Applications must use HWND_BROADCAST for inter-program interaction. The message should be obtained from RegisterWindowMessage ()
 
If a message is sent below the WM_USER range and to the asynchronous message queue function (PostMessage and sendpolicymessage), the Message Parameter should not contain a pointer. Otherwise, the Operation will fail. This function will be returned before the receiving thread has the opportunity to process the message, and the sender will release the memory just used.
---


PostQuitMessage
This function simply indicates that the thread requested to terminate will terminate. The thread that receives WM_QUIT should terminate the message loop and give control to the system. The exit value returned to the system. It must be the wParam parameter of WM_QUIT.
---
 
BOOL PostThreadMessage (
DWORD idThread,
UINT Msg,
WPARAM wParam,
LPARAM lParam
);
 
The thread that receives the message obtains the message through GetMessage/PeekMessage. The hWnd member will be empty.
 
---
RegisterWindowMessage
The registered value of the same string is unique throughout the system.
 
---
SendMessage
The system directly calls the Window Process in a non-Message Queue mode. The system immediately switches to the receiving thread for execution, and the sending thread is locked.
----


SendMessageTimeout
This function sends messages by calling the window process. If the window belongs to different threads, SendMessageTimerout will know that the message is processed before it returns or the specified Timeout has passed. If the window is in the current thread, the window process is called directly, and the time-out timeout is ignored.
---


Sendpolicymessage
If the window is created in a message sending thread, call the Window Process and wait until the window process finishes processing the message. If it is a different thread, the message is transmitted to the window process and immediately returned without waiting for the message processing process in the window process.
 
--
TranslateMessage
1. Convert the virtual key message to a character message, and then send the character message to the Message Queue of the calling thread. The message will be obtained when GetMessage or PeekMessage is called next time.
2. WM _ (SYS) KEYDOWN/UP ---> WM _ (SYS) _ CHAR
3. If the application processes the virtual key message for other purposes, it should not call TranslateMessage. And an instance. The application should not call TranslateMessage when the TranslateAccelerator function returns a non-0 value.