About Messages and Message Queues
Windows-based applications are event-driven. They do not make a clear function call (such as calling C running) to get the input. Instead, they wait for the operating system to pass the input to them. The operating system passes all input to various applications. Each Window has a function called window process, as long as you have an input operating system, call them. After the window process is handled, the control is returned to the operating system. Please see the window process for details.
Microsoft? Windows? XP: If the top-level window stops responding for a few seconds, the system will consider that the window is hang. In this case, the system will hide this window and use a ghost window on the same Z coordinate, the same size, the same size, the same visual properties to replace him. To allow the user to move the window, change the window size, turn off the window. However, only these behaviors are operable because the application has hang. In Debugger mode, the system does not produce 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 process in the form of Messages. The message can be generated by the system and application. The system generates a message When each input event occurs, if the user knocks the keyboard, the mouse, or click the scroll bar. The system also uses messages to respond to system changes due to application. If the application changes system font resources or change its window. The application generates a message to let his window perform some tasks or communicate with the window of other applications.
The system sends a message to the window process and passes 4 parameters, Windows handles, message identifiers, and 2 message parameters. The system uses the form handle to determine the window process to accept the message.
The message identifier indicates the meaning of the message with a constant naming. When the window procedure receives the message, use the message identifier to determine how to handle the message. For example, WM_Paint tells the window Process Form Customer Area to be changed.
The message parameter specifies the location of the data and data used by the window process. The meaning and value depend on the message type. The message parameter can contain an integer, a flag, a pointer, and the like. When the message does not use message parameters, they are set to NULL. A Window window process must determine how message parameters are explained based on the message identifier.
Message TypeS Section Describes The Two Types of Messages: · System-Defined Messages · Application-Defined Messagessystem-Defined Messages
When the system is communicated with the application, the system POST and SEND system define messages. He uses messages to control the operations of the application, providing inputs and other information to processes the application. The application can also define a message in POST or SEND system.
Each system defines a message consistent with a unique identifier and a consistent constant to declare the meaning of the message. For example, the WM_Paint requires a window to draw its content.
Symbol constant Specifies the category belonging to the system definition message, the prefix of the constant specifies the type of the form that explains the message. The following make some prefixes and their relevant message categories.
Prefix Message categoryABM Application desktop toolbar BM Button control CB Combo box control CBEM Extended combo box controlCDM Common dialog box DBT Device DL Drag list box DM Default push button control DTM Date and time picker controlEM Edit control HDM Header control HKM Hot key controlIPM IP address controlLB List box control LVM List view control MCM Month calendar controlPBM Progress bar PGM Pager controlPSM Property sheet RB Rebar controlSB 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 The ControlWM General WINDOW Universal Form message covers a wide range of information and requests, including the mouse keyboard message, input, Form generation and management, Dynamic Data Exchange (DDE).
Application-Defined Messages
Applications can generate their own messages or communicate with other processes. If the application generates its own message, the window process is accepted and must provide appropriate processing.
The value of the system retains the message identifier at 0x0000 in the range of 0x03FF (WM_USER-1). These values are used by the system definition message. Applications cannot use these values to give their own messages.
Private window classes with 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_AP) THROUGH 0XBFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF for Private Messages.
The system uses REGISTERWINDOWMESSAGE to register the message, returns a message identifier ranges in 0xc000 to 0xFFFF, using this function to ensure that the entire system is unique.
Message routing
There are two ways to pass messages to window procedures. POST a message to the advanced message queue. The system defined temporary memory object. And Direct Send messages to the window process.
The message sent to the message queue called the team message, mainly by the mouse keyboard, such as WM_MOUSEMOVE, WM_LBUTTONDOWN, WM_KEYDOWN, AND WM_CHAR MESSAGES. Also included with timers, refresh, exit: WM_TIMER, WM_PAINT, AND WM_QUIT. Other messages sent directly to the window process are called non-entry messages.
Queued Messages
The system can display any number of forms at the same time. In order to pass mouse keyboard messages to the appropriate window, the system uses a message queue.
The system maintains a system message queue and a message queue of each GUI thread, to avoid the creating message queue to the Non-GUI, and there is no message queue when all threads occur. The system creates a message queue for the thread only when the thread calls the GDI function. As long as the user moves the mouse, click the mouse, knock the keys, the driver converts it to the message to place them in the system message queue. The system removes them from the system message queue and checks their target window, and then sends them to the message queue of the thread that creates the target window. The thread message queue receives the mouse keyboard message for all windows created by this thread. Thread Delete Message System Call Window Process is processed. WM_PAINT is an exception, the system always puts the message POST at the end of the message queue. This ensures that the window accepts the message in advanced first. However, WM_PAINT is only passed when there is no other message. Multiple WM_PAINT of the same window is merged into a WM_Paint message, merge all invalid areas to an invalid area. Merge WM_PAIN reduces the number of refresh windows.
The system sends a message to the thread queue by populating the MSG structure and copy it to the message queue. The MSG structure includes: window handle, message identifier, two message parameters. The message is passed by the Posted, and the position of the mouse. Threads can use PostMessage and PostthreadMessage to send messages to your message queue or another message queue.
The application can delete messages from the message queue using getMessage. You can use PeekMessage to check a message without removing it. This function fills messages of message queues to the MSG structure.
Deleting a message from the message queue, the application can use DispatchMessage to send the system to the window process. DispatchMessage has a pointer to the MSG structure fills by GetMessage or PeekMessage, pass window handle, message identifier, message parameter to the window process. However, it does not pass the time of the message and the location of the mouse, and the application can get this information via GetMessageTime and GetMessagePos.
Threads can be handed over to other threads when there is no message queue in the message queue, and the new message is not returned until the new message is placed in the message queue.
You can call the SetMessageExtrainfo function to associate a message queue to the current thread. Calling GetMessageExtrainfo to get this associated value with the last time passed through GetMessage or PeekMessaage.
NonQueued Messages
Non-entry messages are sent directly to the window process, bypass the system queue and thread message queue. The system sends a non-entry message to notify one window event, for example, when the user activates a new application window, the system sends WM_Activate, WM_SETFOCUS, and WM_SETCURSOR. These message notification windows are activated, the keyboard input is passed directly to the window, and the mouse moves within the current window. Non-entry messages can also be generated by the application call system function. For example, when the program calls the SETWINDOWPOS system sends a WM_WINDOWPOSCHANGED message.
Some functions also send a non-into team message such as BroadcastsystemMessage, BroadcastsystemMessageEx, SendMessage, SendMessageTimeout, And SendNotifyMessage.
Message handling
The application must remove and process messages that were sent to message queues. Single-threaded applications typically use messages loops to remove and distribute messages to when the message loop is processed by WinMain. Multi-threaded applications can include a message loop in the thread of each creation window.
Message LoopA 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 ExampleMSG 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 gets a message from the message queue and copies it to the MSG structure. He returns a non-0 value unless it encounters a WM_Quit message. Otherwise it returns 0 and then ends the loop. IN A Single-Threaded Application, Ending The Message Loop Is Offen The First Step in Closing The Application. Application You can use postquitMessage to end your own message loop. Usually call in the WM_DESTROY message of the main window.
If you pass a window handle as the second parameter, then only the message with the specified window can be obtained from the queue. GetMessage can also filter messages from the message queue only accept messages in the message queue. See the message filtering in detail. A thread cycle must include TranslateMessage if the thread accepts the character input of the keyboard. Every time the user button system generates a virtual key message, a virtual key message contains a virtual key to log that the key is pressed, not his character value, to get this value message loop must call TranslateMessage, to convert the virtual key to Character message WM_CHAR then put it back into the application message queue. The character message is deleted by forwarding it to the window process.
DispatchMessage function Distributes the window handle associated with the window handle in the MSG structure. If the window handle is HWND_TOPMOST, DispatchMessage distributes the window process of all Top-Level windows in the system. If the handle is NULL, DispatchMessage does not do anything.
Application Master thread In initialization, start its message loop after creating at least one window, once the start message loop continues from the thread queue, then distributes them to the appropriate window. The message is looped to get WM_QUIT via GetMessage and end him from the queue.
A message is column only a message loop, even if the program contains a lot of windows. DispatchMessage always distributes messages to the right window because the MSG structure contains the handle of the window to which the message belongs.
You can modify the message loop in a variety of ways. For example, get a message message from a message queue but does not distribute them into the window. Useful when the application sends a message but does not specify a window. You can get a specific message with GetMessage, and keep other messages in the message queue. It is useful when you need to change the order of advanced first out.
The application uses acceleration keys to convert keyboard messages to WM_COMMAND messages. So the message loop must include the TranslateAccelerator function. See the acceleration key for details.
If the thread uses a non-modular dialog, the message loop must include IsDialogMessage to enable the Non-Modular Dialog to get the keyboard input.
Window procedure
The window process is a function for processing all messages sent to this window. Any window class has a window process. The same class window uses the same window process to respond to the message. The system sends a message to the window process to pass the message data as a parameter to him, and the window process uses the parameters to generate appropriate behavior.
One window process usually does not ignore the message if he does not process, it will transfer the message to the execution of the default. The window process does this by calling DEFWINDOWPROC. The window process must return a value as its message processing result. Most windows only handle small parties and passing other DEFWINDOWPROCs to the system to do default processing.
Because the window process is shared by the window of the same class, it can process messages for different windows. The window affects the message is found by checking the window handle in the message. See Window Procedures for more information.
Message filtering
Applications can select specific messages from the message queue. Use GetMessage or PeekMessage and specify a message filter. This filter is the range of a message identifier or a form handle, or both at the same time. GetMessage and PeekMessage use filters to select those messages from the message queue. It is useful when the application is looking for a subsequent message queue.
An application filtering message must ensure that messages that match the filter can be sent. For example, the application is filtered in the window and does not get the keyboard input, and the getMessage does not return. This will hang the application.
Posting and sending messages
The application can post and send messages by copying the message to the message queue, the Send message passes the message data as a parameter to the window process. You can use PostMessage to Post Message, SendMessage, BroadcastsystemMessage, SendMessageCallback, SendMessagetimeout, Sendnotify, or SenddlgItemMessage to Send message.
Posting Messages
Application POST message Notification Specifies the form execution task. PostMessage can create an MSG structure and copy it to the message queue. The message loop finally captures the message and distributes to the appropriate window process.
Passing a NULL handle for PostMessage does not specify which window, this message is sent to the current thread message queue, and the application must handle this message in the message processing. This is a method for sending messages throughout the application.
Occasionally you can use the hwnd_topmost parameter as the handle parameter to send a message to all top-level windows.
When the message queue is full, PostMessage does not send a message, the application needs to check the return value of the PostMessage function to determine if the message is sent, or there is no need to be reissued.
Sending Messages
Notify the window process to perform the task immediately by the send message. SendMessage sends the message to the window process of the specified window. The function will wait for the window process to return a message result. The parent window and the sub-window typically use the Send message to communicate with each other. For example, a parent window has a sub-window as a text box, which can set text boxes to the text box by sending a message to the sub-window. The sub-window can also send text to the parent window by a message changed by the user.
SendMessageCallback also sends a message to the window process of the specified window, but he returns immediately. After processing the message in the window process, the system calls the specified callback function, and the details of the callback function see SendasyncProc
Occasionally, you can send a message system to all top-level windows, for example, the application changes system time. It must send a WM_TIMECHANGE message to all top-level window as a handle parameter, you can also specify lpdwrecipients to BSM_Applications with the BroadcastsystemMessage function to broadcast all application broadcasts.
You can use the InsendMessage or InsendMessageEx function, the window process can determine if the message it processes is sent by other threads to send SendMessage. THIS CAPABILITY IS USEFUL WHEN Message Processing Depends on The Origin of The Message.Message Deadlocks
A thread can call SendMessage to want other threads to send messages, this thread cannot continue to perform until the message is obtained, the window is returned. If the message is accepted by the message, Yields control, the message to send the thread will never be executed because he is waiting for SendMessage to return. If you accept the thread and the sender idiom to the same message queue, it may cause a message deadlock. Note that the receiving thread need not yield control explicitly; calling any of the following functions can cause a thread to yield control implicitly accept the threads do not need to explicitly yield control, any function following a thread back to lead a definite yield control.
DialogBox DialogBox Indirect · DialogBox IndirectParam · DialogboxParam · GetMessage · MessageBox · PeekMessage · SendMessage
To avoid potential deadlocks, you can use SendNotifyMessage or SendMessAgetimeout, otherwise the window process will use the InsendMessage or InsendMessageEx to determine whether the message is sent by another thread. When calling the previous function window process will first call InsendMessage or InsendMessagex, if the function returns the True window process, you must call replyMessage before the thread Yeild control.
Broadcasting Messages
Each message includes a message identifier and two parameters, WPARAM, and LPARAM, and message identifiers are the only meaning representing this message. Parameters provide additional information related to messages, but WPARAM parameters are usually a type value to provide more message information.
Message Broadcasting is simple to send messages to multiple recipients in the system. With the BroadcastSystemMessage function to broadcast messages, you must specify one or more recipient 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 broadcast message responds to the change of the system device driver or component. Drivers or related component broadcast messages to applications and other components to inform them. For example, a component broadcast message responsible for disk response As long as the floppy disk driver discovers the changes of the media, if the user plugs the disk into the drive.
The system is in order to broadcast messages to the recipient: system-level device drivers, network drivers, installable drivers, and applications. It means that if the system-level device driver is always the first to respond to the message as the recipient. In the recipient type, no driver ensures a message before other drivers. That is, a message given to a particular driver must have a global unique logo to make the driver that does not care about this message does not process it.
You can also broadcast messages to all top windows by specifying hwnd_broadcast in a function such as SendMessage. The application receives the message through the window process of the top window. The message is not sent to the sub-window. The service can receive messages through a window process or their service control function.
Query Messages
You can create custom messages use them to adjust your application and other components. This is very useful if you have created your own installable drivers and system machine drivers. Your driver and application using this driver can pass information through custom messages. To Poll Recipients for Permission To Carry Out A Given Action. You can set BROADCastSystemMessage by setting BSF_Query in the dwflags parameter. The recipient of each Query Message must return True to send the message to the next recipient. If any recipient returns Broadcast_Query_deny, the broadcast immediately stops the function to return 0.
Windows 95/98 / ME: You can create installable drivers for broadcasting and processing messages. An Installable Drivers is a DLL that exports the driverproc function. The driver receives the message through its DRiverProc. Installable Drivers typically used to support multimedia devices, such as Sound Boards, or other devices and purposes.
Windows 95/98 / ME: The network driver provides the application with the following supported DLLs. The system-level device driver is an executable component that provides direct access and managing computer hardware. How these components handle the system message beyond the scope of this article.
Orbout messages and message queues in the original Platform SDK document, if you have any problems, please indicate.
my home page
