About message and Message Queuing
Unlike MS-DOS-based applications, Windows-based programs are event-driven. They do not make any display calls to get input. But by waiting for the system to pass to them.
The system passes all the different windows that are entered into the program for the application. Each window has a function called a window procedure that handles all input to that window. The window processing process processes the input and returns control to the system.
If a top-level window stops responding for more than two seconds, the system will consider the window to be non-responsive. In this case, the system hides the window and replaces it with a ghost window that has the same z-order, position, size, and visual properties. In this case, allow the user to move it, or change his size, or even close the application. Then, this is the only action that can be done, because the application is now unresponsive. When in the debug state, the system does not produce a ghost window.
This paragraph discusses the following topics:
Windows messages
The system passes the input-to-window processing in the form of a message. Both systems and applications can generate messages. Each time the system enters an event, a message is generated, for example, when used for tapping, moving the mouse, or clicking on a control of the scroll bar. Application-induced system changes can also result in the system generating messages, such as an application that changes the system's font resource pool or changes the size of his own window. An application can produce a message that directs his window to perform tasks directly or interact with other applications ' windows.
Message classification:
System-defined messages
When the system interacts with the application, the system sends system messages to control the operation of the application and to pass input or other messages to the program. Applications can also send system messages, which are typically used by applications to control the behavior of Windows created through pre-registered window classes.
The message constant token specifies the kind of predefined message to which the system belongs. The prefix determines the kind of message that can be translated or processed. 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 Ex Change notifications Hook Notifications Keyboard Accelerator Messages Keyboard Accelerator notifications Keyboard Input Me Ssages Keyboard Input Notifications Menu notifications Mouse input notifications multiple Document Interface Messages Raw Input Notifications Scroll Bar Notifications Timer Notifications window Messages window notifications
}
In general, Windows messages cover a wide range including mouse Keyboard, menu, dialog input, window creation management, DDE Dynamic data exchange
Application-defined messages
An application can create a message, its own window can be used, or it can be used to interact with other processes.
The value of the message marker is applied as follows:
1. The system retains 0x0000-0x03ff (that is, wm_user-1), and applications cannot use these values for private messages
2.0x0400 (Wm_user) -0X7FFF can be used for private messages
3. If the application is on a 4.0 system, you can use 0x8000 (Wm_app) to -0xbfff the private message
The value returned by 4.RegisterWindowMessage is between 0xc000-0xffff. The return value of this function prevents conflicts caused by other processes using the same value
Message routing
Use the route that uses two ways to window procedure messages: Post class messages are through FIFO Message Queuing, Message Queuing is a system-defined memory object that temporarily stores messages, and the sending class message directly arrives at the window procedure.
Queue Message 1
The system can display any number of windows at the same time. In order to route the mouse keyboard input to the correct window, the system uses Message Queuing.
The system maintains a system message queue and maintains a thread-specific message queue for each GUI thread. To avoid creating message queues too much for non-GUI threads, all threads do not have Message Queuing when they are created. A thread message queue is created when the system only initiates a dedicated user function for the first time, and no GUI function calls will cause the creation of the message queue.
Not understood:
The system creates a THREAD-SPECIFIC message queue only if the thread makes its first call to one of the specific user F unctions; No GUI function calls result in the creation of a message queue.
Queue Message 2
At any time, the user moves the mouse, clicks the button or taps the keyboard, the mouse or keyboard driver converts these inputs into messages and places them in the system message queue. When the system detects their window, they are removed from the system message queue at the same time. They are then sent to the window of the message related window to create the thread. Threads receive all mouse and keyboard messages from their message queues. Threads remove messages from their queues and instruct the system to send them to the correct window process for processing.
In addition to the Wm_patin,wm_timer,wm_quit messages, the system always sends them to the end of the message queue to ensure that the input message is in a FIFO sequence, only if there are no other messages in the message pair, wm_patin,wm_timer,wm_ Quit is pushed forward to the window processing process. Again, multiple WM_PAINT messages will be merged into one, identifying all client invalid zones to a single zone. Merging Wm_patint is to reduce the number of times the window rushes back to the client area.
After a message is removed from the message queue, the application sends the message to the window processing process to compact processing with the DispatchMessage function direct system. DispatchMessage does not send message locations and time-to-window procedures, applications can pass Getmessagetime and Getmessagepos functions.
When there is no message in the message queue, the thread can use the WaitMessage function to give the controller to another thread, which pauses the thread and knows that a new message arrives and the function returns.
You can also call Setmessageextrainfo to append a value to the current message queue and get the value by Getmessageextrainfo.
Non-queue messages
bypassing system and thread Message Queuing, non-queue messages are sent directly to the window procedure. The system typically sends a non-queue message to notify a window that an event has affected it. For example, when a user activates a new window, the system sends the message to the window wm_activate, Wm_setfocus, and Wm_setcursor. The Message Notification window has been activated, the keyboard input is pointing to the window, and the mouse cursor has moved to the window border. When an application calls some system functions, the window is also non-queue, for example, when an application calls SetWindowPos, the system sends a wm_windowposchanged message.
Some messages send non-queue messages: Broadcastsystemmessage, Broadcastsystemmessageex, SendMessage, SendMessageTimeout, and SendNotifyMessage.
Message processing
A multithreaded application that contains 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);
}
}
It is typical for an application to call PostQuitMessage to end its own message loop and respond to the WM_DESTROY message of the application's main window.
PostMessage sends a message with a null window handle that will be placed in the current thread's 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 has been able to successfully send messages, usually a false assumption, such as that the message queue is full. An application should check the return value of the PostMessage. If it fails, you need to resend the message.
SendMessage the interaction between the user's parent and child windows typically.
The Sendmessagecallback function sends a message and returns immediately, and the window procedure invokes the specified callback function after the message is processed. For the specific callback function, see Sendasyncproc
Occasionally, you may want to send messages to all top-level windows. For example, the application changes the time, can pass SendMessage, and develop Hwnd_topmost, send wm_ Timechange. You can also pass the Broadcastsystemmessage function and make the lpdwrecipients parameter bsn_applications
Message deadlock
1.SendMessage will wait until the window process is finished before returning, if the window process at this time the thread of the control to give up, then the zombie morning deadlock.
2. If the receiving thread is attached to the same message queue as the sending thread, it will also cause the application deadlock to be sent
Note that the thread that is receiving the message should not display a waiver of control; Calling the following function will cause thread privacy to relinquish control.
DialogBox
? Dialogboxindirect
? Dialogboxindirectparam
? Dialogboxparam
? GetMessage
? MessageBox
? PeekMessage
? SendMessage
To avoid potential deadlocks, consider using SendNotifyMessage or sendmessagetimeout. Otherwise, the window procedure can detect whether the message received by Insendmessage or Insendmessageex is from another thread. When processing a message, the window procedure should call Insendmessage (ex) before invoking any of the functions in the list above. If true, the window procedure must call the Replymessage function before yeild.
System broadcast Message-slightly
Summarize:
1. Messages are divided into system-defined messages and user-defined messages with their own range of ID values.
2. Each thread does not have a message queue by default, and the thread only creates a message queue for it when it first invokes the user interface, such as creating a window.
3. The system maintains a system message queue itself, and then maintains a thread-specific message queue for each GUI thread thread.
4. Mouse, keyboard and other drivers, first convert the event into a message placed in the system message queue, and then the system through the window to determine which thread to put into the message queue.
5. The thread message loops out the message, processes it, sends the message back to the system, and the system invokes the window procedure for the message.
6.PostMessage is not necessarily successful, such as the queue is full.
7. Avoid message deadlocks, such as window procedures that receive messages, and before you abstain, you need to detect whether messages are originating from other threads. Otherwise, other threads will wait for a long time. In fact, I feel that this can not be a deadlock, after all, it is possible to carry out, only the length of time.
8. Need to pay attention to special messages such as Wm_paint,wm_timer,wm_quit
9. System pre-defined messages are mostly those control messages, notification messages, system broadcast messages, and so on.
Message-related functions:
---
DispatchMessage
LONG DispatchMessage (
Const msg* LPMSG
);
1. The function sends the message through the system to the window procedure
2. If it is a timer message, the lparam parameter is not empty, lparam points to a function address, which is called the function, not the window procedure
---
GetMessage
The application uses this function to return a value to decide whether to terminate the message loop and exit the program.
The function gets the message associated with the HWND or its child window.
---
DWORD getmessagepos (void);
The function returns the x, y coordinates of the message, which may have negative values under multiple monitor.
---
Getmessagequeuereadytimestamp
Gets the system time that the thread was last prepared to process a message (GetTickCount)
---
Getmessagesource
Msgsrc_software_post surface keyboard messages are from software (postmessage labeled Software). Msgsrc_hardware_keyboard surface messages from KEYBOARD. Msgsrc_unknown Message Source Unknown
---
DWORD Getqueuestatus (
UINT Flags
);
The type of message in Message Queuing
Flags is the type of message to be detected.
Returns the type of message that is worth the high byte that is currently in Message Queuing. The low byte represents the type of message that was joined to the queue since the last Getqueuestatus,getmessage or PeekMessage.
---
Insendmessage
Used to determine whether the message processed by the current window procedure is a SendMessage call from another thread.
---
PeekMessage
1. The function verifies that there is a message in the thread message queue and places the message in the parameter structure body
2. If the HWND parameter is =-1, only the hwnd=null message is returned, and the message is from PostThreadMessage
3. Parameter wremovemsg need attention
4. Calling PeekMessage when the application is creating a top-level window will cause the window window to be created at the end of Z-order. You need to explicitly call SetForegroundWindow after PeekMessage. If the application and has a front window, then the new window will be pre-placed.
---
PostMessage
Applications use Hwnd_broadcast for inter-program interaction, and messages should be obtained from registerwindowmessage ()
If the sending message is below the Wm_user range, to the asynchronous Message Queuing function (PostMessage, sendnotifymessage), the message parameter should not contain a pointer, otherwise the operation will fail. The function will return before the receiving thread has the opportunity to process the message, and the sender will release the memory that was just used.
---
PostQuitMessage
The function simply indicates that the thread that was requested to terminate will be terminated. The thread that receives the WM_QUIT should terminate the message loop and give control over to the system. The exit value returned to the system must be the wparam parameter of the Wm_quit
---
BOOL PostThreadMessage (
DWORD Idthread,
UINT MSG,
WPARAM WPARAM,
LPARAM LPARAM
);
The thread that receives the message, gets the message through Getmessage/peekmessage, and the HWND member will be empty
---
RegisterWindowMessage
The same string, the registered value, is unique throughout the system
---
SendMessage
Non-Message Queuing method that calls the window procedure directly, the system immediately switches to the receive thread execution, the sending thread locks, knowing that the receiving thread has finished processing
----
SendMessageTimeout
The function sends a message by invoking a window procedure, and if the window is of a different thread, sendmessagetimerout will know that the message has been processed before returning or the specified timeout has passed, and if the window is on the current thread, call the window procedure directly and ignore the time-out timeout
---
SendNotifyMessage
If the window is created in a thread that belongs to the sending message, the window procedure is called and waits for the window procedure to finish processing the message. If it is a different thread, the message is passed to the window procedure and is immediately returned without waiting for the message processing of the window procedure.
--
TranslateMessage
1. Convert the virtual key message to a character message and then send the character message to the calling thread's message queue, which will be acquired the next time the GetMessage or PeekMessage message is called.
2.WM_ (SYS) keydown/up--->wm_ (SYS) _char
3. If the application processes virtual key messages for other purposes, then translatemessage should not be called. With an instance, the application should not be called when the TranslateAccelerator function returns a value other than 0 TranslateMessage
About the Windows operating system message and Message Queuing
