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.
Nish is a real nice guy who has been writing code since 1990 when he first got his hands on an 8088 with 640 KB RAM. Originally from sunny Trivandrum in India, he has been living in various places over the past few years and often thinks it’s time he settled down somewhere.
Nish has been a Microsoft Visual C++ MVP since October, 2002 - awfully nice of Microsoft, he thinks. He maintains an MVP tips and tricks web site -
www.voidnish.com where you can find a consolidated list of his articles, writings and ideas on VC++, MFC, .NET and C++/CLI. Oh, and you might want to check out his blog on C++/CLI, MFC, .NET and a lot of other stuff -
blog.voidnish.com.
Nish loves reading Science Fiction, P G Wodehouse and Agatha Christie, and also fancies himself to be a decent writer of sorts. He has authored a romantic comedy
Summer Love and Some more Cricket as well as a programming book –
Extending MFC applications with the .NET Framework.
Nish's latest book
C++/CLI in Action published by Manning Publications is now available for purchase. You can read more about the book on his blog.
Despite his wife's attempts to get him into cooking, his best effort so far has been a badly done omelette. Some day, he hopes to be a good cook, and to cook a tasty dinner for his wife.