Receiving and Dispatching Messages

37 篇文章 0 订阅
Receiving and Dispatching Messages

To receive messages, call the GetMessage function. Typically, an application calls GetMessage inside the window message loop.

The following code example shows a message loop that calls GetMessage.

while (GetMessage(&msg, NULL, 0, 0)) 
{
    TranslateMessage(&msg);
    DispatchMessage(&msg);
}

When a thread calls GetMessage, Windows CE examines the thread message queue for incoming messages. Windows CE processes messages in the following order:

  1. Windows CE checks for messages placed on the queue by the SendMessage function. After the system removes the message from the queue, it dispatches the message to the appropriate window procedure from within the GetMessage function. This guarantees that the sending and receiving message queues remain synchronized. The receiver must call GetMessage for the sent messages to be processed.
  2. If no sent message is found, Windows CE checks for messages placed on the queue by a call to the PostMessage function.
  3. If no posted message is found, Windows CE checks the queue for messages posted by the user-input system.

    By processing user-input messages at a lower priority, the system guarantees that each input message and all posted messages that result from it are processed completely before moving on to the next input message.

  4. If no posted input messages are found, Windows CE checks the queue for WM_QUIT messages placed on the queue by a call to the PostQuitMessage function.
  5. If no posted quit messages are found, Windows CE checks the queue for WM_PAINT messages that were placed on the queue by the windowing system.
  6. If no paint messages are found, Windows CE checks the queue for WM_TIMER messages placed on the queue by the timer system.

When GetMessage receives any of the previous messages, it returns the message content. The thread must call the DispatchMessage function to dispatch the message to the correct window procedure. If the message is a WM_QUIT message, the return value of GetMessage is zero, which causes the thread to end its message loop.

The system dispatches messages in the GetMessage call of the message loop, and the application dispatches messages by calling the DispatchMessage function in the message loop.

You might need to process messages that you receive from GetMessage before you send them out by using DispatchMessage. The most common processing functions are the TranslateMessage, TranslateAccelerator, and IsDialogMessage functions. Some of these functions can dispatch messages internally, because the application no longer needs to call DispatchMessage in the main message loop.

You usually call TranslateMessage before DispatchMessage. TranslateMessage determines which characters go with keyboard messages. TranslateMessage also posts the characters to the message queue to be picked up on the next pass of the message loop.

To intercept keyboard messages and generate menu commands, call the TranslateAccelerator function. Call the IsDialogMessage function to ensure the proper operation of modeless dialog boxes.

The following code example shows a message loop that uses DispatchMessage, TranslateMessage, TranslateAccelerator, and IsDialogMessage in addition to GetMessage. The call to IsDialogMessage in the code example uses the HWND for the modeless dialog box that is currently active. The window handle of the modeless dialog box that is currently active should be tracked in a global variable by your application if you are using multiple modeless dialog boxes in your application.

while (GetMessage(&msg, NULL, 0, 0)) 
{
    if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg)) 
    {
        if (hwndDLGCurrent != NULL || !IsDialogMessage(hwndDLGCurrent, 
                                                       &msg)) 
        {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }
    }
}

You can remove a message from its queue by using the GetMessage function. Call the PeekMessage function to examine a message without removing it from its queue. This function fills an MSG structure with information about the message. Use PeekMessage carefully, because it does not block the waiting for a message event, which enables an application to continue running regardless of messages in the queue. In a Windows CE–based application, if an application does not block the waiting for a message or some other event, the kernel cannot shift the CPU into low-power mode, which can drain the device batteries quickly.

When processing messages, Windows CE supports both system-defined messages and application-defined messages. System-defined messages have message identifiers ranging from 0 through 0x3ff. Messages with message identifiers ranging from 0x400 through 0x7fff are available for application-defined messages. Windows CE defines the message number 0x400 as WM_USER. If you want to define a custom message for your application, define the message as an offset from WM_USER. The following code example shows how to define a custom message.

#define WM_MYNEWMESSAGE       (WM_USER 999)

There are two types of system-defined messages: general window messages, which are used for all windows, and special-purpose messages, which apply to a particular class of windows. General window messages cover a wide range of information and requests, including messages for input device and keyboard input, as well as window creation and management.

The prefix of the symbolic constant for the message generally identifies the category to which the message belongs. For example, all general window messages start with WM, whereas messages that apply only to button controls start with BM.

The following table shows Windows CE message types.

Message typeDescription
BMButton message
BNButton notification
CBCombo box message
CBNCombo box notification
CDMCommon dialog box message
CDNCommon dialog box notification
CPLControl panel message
DBObject store message
DMDialog box default command button message
DTMDate and time picker and Hypertext Markup Language (HTML) viewer messages
DTNDate and time picker notification
EMEdit control message
ENEdit control notification
HDMHeader control message
HDNHeader control notification
IMNInput context message
LBList box control message
LBNList box notification
LINELine device message
LVMList view message
LVNList view notification
MCMMonth calendar message
MCNMonth calendar notification
NMMessages sent by a variety of controls
PBMProgress bar message
PSMProperty sheet message
PSNProperty sheet notification
RBRebar message
RBNRebar notification
SBStatus bar window message
SBMScroll bar message
STMStatic bar message
STNStatic bar notification
TBToolbar message
TBMTrackbar message
TBNTrackbar notification
TCMTab control message
TCNTab control notification
TVMTree-view message
TVNTree-view notification
UDMUp-down control message
UDNUp-down control notification
WMGeneral window messages

You can define messages for use by the window of your application. If you create messages, be sure that the window procedure that receives them interprets and processes them correctly. The OS does not interpret application-defined messages.

Occasionally, you need to use messages to communicate with windows that are controlled by other processes. In such a situation, call the RegisterWindowMessage function to register a message identifier. The message number that is returned is guaranteed to be unique throughout the system. By using this function, you prevent the conflicts that can arise if different applications use the same message identifier for different purposes.

Windows CE does not support hooking messages, because the extra processing that is required by hooks can impair the performance of Windows CE–based devices.

When handling messages in your application, be aware of the WM_HIBERNATE message. Windows CE defines a WM_HIBERNATE message to notify an application when system resources run low. When an application receives this message, it should attempt to release as many resources as possible. The system checks memory status at five-second intervals. Every Windows CE–based application that uses even moderate amounts of system resources should implement a handler for the WM_HIBERNATE message. If an application window is not visible, the application cannot receive a WM_HIBERNATE message. The application cannot receive the WM_HIBERNATE message because the WM_HIBERNATE message is sent only to applications that have a button on the taskbar, which is the case for visible windows only. A hidden window will not get this message, even if it is a top-level, overlapped window.


 Last updated on Tuesday, July 13, 2004

© 1992-2000 Microsoft Corporation. All rights reserved.

 

引用:http://msdn.microsoft.com/en-us/library/ms927938.aspx

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值