以下摘自微软MSDN网站：HOWTO: Use Accelerator Keys Within a Modal Dialog Box The information in this article applies to: The Microsoft Foundation Classes (MFC), when used with: Microsoft Visual C++, 32-bit Editions 4.1 Microsoft Visual C++, 32-bit Enterprise Edition 4.2 Microsoft Visual C++, 32-bit Enterprise Edition 5.0 Microsoft Visual C++, 32-bit Enterprise Edition 6.0 Microsoft Visual C++, 32-bit Professional Edition 4.2 Microsoft Visual C++, 32-bit Professional Edition 5.0 Microsoft Visual C++, 32-bit Professional Edition 6.0 Microsoft Visual C++, 32-bit Learning Edition 6.0 Microsoft Visual C++ .NET (2002) This article was previously published under Q222829 SUMMARY Accelerator keys are a common User Interface feature of Windows applications; therefore, why limit them to just the application? This article shows how to add accelerator key functionality to any modal dialog box. MORE INFORMATION Keyboard accelerators are processed by calling the TranslateAccelerator() function in the application's main message loop. However, for a modal dialog box, the dialog box manager message loop (built into Windows) is used to translate and dispatch messages. Of course, because this message loop is not designed to process accelerators, it does not call the TranslateAccelerator() function.To process accelerator keys in a modal dialog box, you must override the dialog box's PreTranslateMessage() function and try to process the message as an accelerator by calling ::TranslateAccelerator(). If this method fails, then processing continues by calling the base class PreTranslateMessage().For the purposes of this article, we add accelerator key functionality to the AboutBox dialog box of an MFC MDI application: Create a new MFC MDI application named Test. Add a button, with resource ID "IDC_BUTTON1", to the AboutBox dialog box resource. Double-click the button to add a handler for this button and insert the following code as an indicator that the accelerator key works: AfxMessageBox("Hello"); Insert a new Accelerator Table to the Resource. Add an Accelerator key to the table by associating the F5 key to the resource ID "IDC_BUTTON1". Add the member variable, m_hAccelTable, to the class CAboutBox: HACCEL m_hAccelTable; Initialize m_hAccelTable in CAboutBox::CAboutBox: m_hAccelTable = LoadAccelerators(AfxGetInstanceHandle(), MAKEINTRESOURCE(IDR_ACCELERATOR1)); Use the Code Wizard (the Class Wizard in Visual C++ 6.0 and earlier) to add an override of the PreTranslateMessage for the CAboutDlg. In the CAboutBox::PreTranslateMessage() method, add the following lines of code: BOOL CAboutDlg::PreTranslateMessage(MSG* pMsg) { if (m_hAccelTable) { if (::TranslateAccelerator(m_hWnd, m_hAccelTable, pMsg)) { return(TRUE); } } return CDialog::PreTranslateMessage(pMsg);} Compile and run CTestApp.RESULTS: Accelerator key F5 now triggers the button1 handler when the CAboutBox is active. REFERENCES For additional information about accelerator key processing within modal dialog boxes, please see the following article in the Microsoft Knowledge Base: 100770 INFO: Using Accelerator Keys with Modal Dialog Box Main Window
Keyboard messages/accelerators handling in MFC dialog based applications By Nishant S This article explains how you can override PreTranslateMessage and ProcessMessageFilter in dialog based apps VC7, VC6, MFC Posted 2 Dec 2001 22,174 views
52 users have rated this article. Result:
Popularity: 6.52. Rating: 3.8 out of 5. Introduction There are a substantial number of Windows programmers who insist, often very vehemently, that a programmer should avoid overriding PreTranslateMessage. They have their reasons for saying so and I believe they are correct. But in this article my intention is not to contemplate on whether PreTranslateMessage is good for you or whether you should avoid it like the plague. I have found that PreTranslateMessage can come in quite handy in dialog-based applications for handling keyboard messages. In addition to using PreTranslateMessage I also show you how you can override ProcessMessageFilter for handling accelerator keys in a dialog based application.Using PreTranslateMessage to handle dialog keystrokes Very often you hear questions from novice programmers asking how they can trap keystrokes in a dialog based application. Presumably they tried to handle WM_KEYDOWN/WM_KEYUP unsuccessfully. The whole problem is that in a dialog based application the focus is always on one of the child controls and not on the main dialog window. So what do you need to do? You need to override PreTranslateMessage. I'll show you a simple example.Suppose that you have a dialog based app with a lot of edit boxes on the dialog. It's basically a data entry program and thus you feel it would make it easier for the end-user if pressing the ENTER key would take the focus to the next edit box, just as if he had pressed TAB. The solution is so very easy and straightforward with PreTranslateMessage as I'll demonstrate below.BOOL CPreTransTestDlg::PreTranslateMessage(MSG* pMsg) { if(pMsg->message==WM_KEYDOWN) { if(pMsg->wParam==VK_RETURN) pMsg->wParam=VK_TAB; } return CDialog::PreTranslateMessage(pMsg); } All I have done is to check whether the message is a WM_KEYDOWN, and if it is so, then I check to see if the wParam is VK_RETURN. If I find it so, I change the wParam to VK_TAB and then the base class implementation is called. Easy huh?Using ProcessMessageFilter to handle dialog-based accelerator keys Let's say you have a menu in your dialog based app. And you have an accelerator key for some particular task. You'll soon be disappointed to find that the hotkey does not work. The problem is that the modal dialog app's message loop does not call TranslateAccelerator. I do not know why this is so. Presumable the Microsoft team decided that people shouldn't use dialog based apps to write complicated applications, with hotkeys and menus.But as usual they have suggested a workaround too. Here's is how you go about implementing it. I'd like to state again, that even though this is a Microsoft recommended technique there will be a good majority of MFC gurus, like Joseph Newcomer for example, who would tell you that you shouldn't be doing this. But then sometimes you have to sacrifice elegance for getting things done quickly and with minimum effort.Add a member variable to your CWinApp derived class. HACCEL m_haccel; Use the resource editor to create a new Accelerator, by default it will be named IDR_ACCELERATOR1. And add a new accelerator key that is a short cut for some menu item. Put the following line in your InitInstance just before the line where the CDialog derived object is declared m_haccel=LoadAccelerators(AfxGetInstanceHandle(), MAKEINTRESOURCE(IDR_ACCELERATOR1)); Now override ProcessMessageFilter and modify the function so that it looks like :- BOOL CPreTransTestApp::ProcessMessageFilter(int code, LPMSG lpMsg) { if(m_haccel) { if (::TranslateAccelerator(m_pMainWnd->m_hWnd, m_haccel, lpMsg)) return(TRUE); }
return CWinApp::ProcessMessageFilter(code, lpMsg); } All we did was to call TranslateAccelerator and if it succeeds then we don't need to call the base class ProcessMessageFilter, as the message has been handled. So we return TRUE.Disclaimer The author wishes to state here that the two methods mentioned above are generally used methods and the author is not in any way endorsing these methods. Users should read more on the usage of PreTranslateMessage and ProcessMessageFilter before they use it in their programs.
The information in this article applies to:
The Microsoft Foundation Classes (MFC), when used with:
Microsoft Visual C++, 32-bit Editions 4.1
Microsoft Visual C++, 32-bit Enterprise Edition 4.2
Microsoft Visual C++, 32-bit Enterprise Edition 5.0
Microsoft Visual C++, 32-bit Enterprise Edition 6.0
Microsoft Visual C++, 32-bit Professional Edition 4.2
Microsoft Visual C++, 32-bit Professional Edition 5.0
Microsoft Visual C++, 32-bit Professional Edition 6.0
Microsoft Visual C++, 32-bit Learning Edition 6.0
Microsoft Visual C++ .NET (2002)
This article was previously published under Q222829
SUMMARY
Accelerator keys are a common User Interface feature of Windows applications; therefore, why limit them to just the application? This article shows how to add accelerator key functionality to any modal dialog box.
MORE INFORMATION
Keyboard accelerators are processed by calling the TranslateAccelerator() function in the application's main message loop. However, for a modal dialog box, the dialog box manager message loop (built into Windows) is used to translate and dispatch messages. Of course, because this message loop is not designed to process accelerators, it does not call the TranslateAccelerator() function.To process accelerator keys in a modal dialog box, you must override the dialog box's PreTranslateMessage() function and try to process the message as an accelerator by calling ::TranslateAccelerator(). If this method fails, then processing continues by calling the base class PreTranslateMessage().For the purposes of this article, we add accelerator key functionality to the AboutBox dialog box of an MFC MDI application:
Create a new MFC MDI application named Test.
Add a button, with resource ID "IDC_BUTTON1", to the AboutBox dialog box resource.
Double-click the button to add a handler for this button and insert the following code as an indicator that the accelerator key works:
AfxMessageBox("Hello");
Insert a new Accelerator Table to the Resource.
Add an Accelerator key to the table by associating the F5 key to the resource ID "IDC_BUTTON1".
Add the member variable, m_hAccelTable, to the class CAboutBox:
HACCEL m_hAccelTable;
Initialize m_hAccelTable in CAboutBox::CAboutBox:
m_hAccelTable = LoadAccelerators(AfxGetInstanceHandle(), MAKEINTRESOURCE(IDR_ACCELERATOR1));
Use the Code Wizard (the Class Wizard in Visual C++ 6.0 and earlier) to add an override of the PreTranslateMessage for the CAboutDlg.
In the CAboutBox::PreTranslateMessage() method, add the following lines of code:
BOOL CAboutDlg::PreTranslateMessage(MSG* pMsg) {
if (m_hAccelTable) {
if (::TranslateAccelerator(m_hWnd, m_hAccelTable, pMsg)) {
return(TRUE);
}
}
return CDialog::PreTranslateMessage(pMsg);}
Compile and run CTestApp.RESULTS: Accelerator key F5 now triggers the button1 handler when the CAboutBox is active.
REFERENCES
For additional information about accelerator key processing within modal dialog boxes, please see the following article in the Microsoft Knowledge Base:
100770 INFO: Using Accelerator Keys with Modal Dialog Box Main Window
By Nishant S This article explains how you can override PreTranslateMessage and ProcessMessageFilter in dialog based apps VC7, VC6, MFC
Posted 2 Dec 2001
22,174 views
52 users have rated this article. Result:
Popularity: 6.52. Rating: 3.8 out of 5. Introduction
There are a substantial number of Windows programmers who insist, often very vehemently, that a programmer should avoid overriding PreTranslateMessage. They have their reasons for saying so and I believe they are correct. But in this article my intention is not to contemplate on whether PreTranslateMessage is good for you or whether you should avoid it like the plague. I have found that PreTranslateMessage can come in quite handy in dialog-based applications for handling keyboard messages. In addition to using PreTranslateMessage I also show you how you can override ProcessMessageFilter for handling accelerator keys in a dialog based application.Using PreTranslateMessage to handle dialog keystrokes
Very often you hear questions from novice programmers asking how they can trap keystrokes in a dialog based application. Presumably they tried to handle WM_KEYDOWN/WM_KEYUP unsuccessfully. The whole problem is that in a dialog based application the focus is always on one of the child controls and not on the main dialog window. So what do you need to do? You need to override PreTranslateMessage. I'll show you a simple example.Suppose that you have a dialog based app with a lot of edit boxes on the dialog. It's basically a data entry program and thus you feel it would make it easier for the end-user if pressing the ENTER key would take the focus to the next edit box, just as if he had pressed TAB. The solution is so very easy and straightforward with PreTranslateMessage as I'll demonstrate below.BOOL CPreTransTestDlg::PreTranslateMessage(MSG* pMsg)
{
if(pMsg->message==WM_KEYDOWN)
{
if(pMsg->wParam==VK_RETURN)
pMsg->wParam=VK_TAB;
}
return CDialog::PreTranslateMessage(pMsg);
}
All I have done is to check whether the message is a WM_KEYDOWN, and if it is so, then I check to see if the wParam is VK_RETURN. If I find it so, I change the wParam to VK_TAB and then the base class implementation is called. Easy huh?Using ProcessMessageFilter to handle dialog-based accelerator keys
Let's say you have a menu in your dialog based app. And you have an accelerator key for some particular task. You'll soon be disappointed to find that the hotkey does not work. The problem is that the modal dialog app's message loop does not call TranslateAccelerator. I do not know why this is so. Presumable the Microsoft team decided that people shouldn't use dialog based apps to write complicated applications, with hotkeys and menus.But as usual they have suggested a workaround too. Here's is how you go about implementing it. I'd like to state again, that even though this is a Microsoft recommended technique there will be a good majority of MFC gurus, like Joseph Newcomer for example, who would tell you that you shouldn't be doing this. But then sometimes you have to sacrifice elegance for getting things done quickly and with minimum effort.Add a member variable to your CWinApp derived class. HACCEL m_haccel;
Use the resource editor to create a new Accelerator, by default it will be named IDR_ACCELERATOR1. And add a new accelerator key that is a short cut for some menu item.
Put the following line in your InitInstance just before the line where the CDialog derived object is declared m_haccel=LoadAccelerators(AfxGetInstanceHandle(),
MAKEINTRESOURCE(IDR_ACCELERATOR1));
Now override ProcessMessageFilter and modify the function so that it looks like :- BOOL CPreTransTestApp::ProcessMessageFilter(int code, LPMSG lpMsg)
{
if(m_haccel)
{
if (::TranslateAccelerator(m_pMainWnd->m_hWnd, m_haccel, lpMsg))
return(TRUE);
}
return CWinApp::ProcessMessageFilter(code, lpMsg);
}
All we did was to call TranslateAccelerator and if it succeeds then we don't need to call the base class ProcessMessageFilter, as the message has been handled. So we return TRUE.Disclaimer
The author wishes to state here that the two methods mentioned above are generally used methods and the author is not in any way endorsing these methods. Users should read more on the usage of PreTranslateMessage and ProcessMessageFilter before they use it in their programs.