PreTranslateMessage
vvf
I am trying to understand how PreTranslateMessage works. I am handling this
method in a CStatic derived class. What I am trying to do is capture the
characters typed and also handle the arrow keys.
I understand that the basic method is to handle WM_KEYDOWN for the the arrow
keys (VK_LEFT, VK_RIGHT, VK_DOWN and VK_UP). However, I am also trying to
handle the WM_CHAR message in the same handler.
I understand that a WM_KEYDOWN message eventually becomes a WM_CHAR when a
character is typed but I can't figure out how to handle both of these in the
same handler.
I have tried this:
if (pMsg->message == WM_KEYDOWN)
{
if (pMsg->wParam == VK_LEFT)
{ // left arrow pressed
}
}
works OK on its own.
Also, for WM_CHAR I have used this:
if (pMsg->message == WM_CHAR)
// and use the char stored in pMsg->wParam.
works OK on its own.
However, I would like to have code for both of these in PreTranslateMessage
and can't figure out how to set up my logic so that both scenarios are
handled because the code would never reach the second "if" statement when
pressing a character key because the first thing that would be generated
would be a WM_KEYDOWN and thus the first "if" would validate.
Thanks.
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4374 (20090827) __________
The message was checked by ESET NOD32 Antivirus.
David Webber
"vvf" <v...@vvf.com> wrote in message
news:u7kT0m0J...@TK2MSFTNGP03.phx.gbl...
> I am trying to understand how PreTranslateMessage works. I am handling
> this method in a CStatic derived class. What I am trying to do is capture
> the characters typed and also handle the arrow keys....
My main window PreTranslateMessage() has evolved over centuries to cope with
this sort of thing. Looking at the source, it's fairly horrible by the
standards I want to live up to but I *think* the main idea is (broadly)
Check for WM_CHAR first.
If it's one of those, then I've got an ASCII character. Handle it.
Then if it's a WM_KEYDOWN
Check to see if its an ASCII character.
If so just let it go to the base class, and I'll get it as WM_CHAR
eventually.
If not, handle it.
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
vvf
> Check for WM_CHAR first.
> If it's one of those, then I've got an ASCII character. Handle it.
>
> Then if it's a WM_KEYDOWN
> Check to see if its an ASCII character.
> If so just let it go to the base class, and I'll get it as WM_CHAR
> eventually.
> If not, handle it.
>
> Dave
Thanks. I got it to work following your method although I'm not sure I
understand why it is working and if I'm doing things right.
Here is what I did:
I wanted to write a test and see if I can distinguish the VK_UP from regular
characters.
Here is the code:
if (pMsg->message == WM_CHAR)
{
// it is a char
return CStatic::PretranslateMessage(pMsg);
}
if (pMsg->messsage == WM_KEYDOWN)
{
// check and see if it is ASCII
if (pMsg->wParam >= 32 && pMsg->wParam <= 126 && pMsg->wParam != VK_UP)
{
// It is ASCII; Note: I noticed that VK_UP is defined as "38" and
somehow '&' in the ASCII table is also 38.
// I don't understand how it can distinguish between the "&" and
VK_UP. It probably finds out later that this 38
// refers to a VK_UP and not a char so it does not synthetise a
char, correct ?
// If I leave out the pMsg->wParam != VK_UP, then my control never
catches VK_UP.
CStatic::PreTranslateMessage(pMsg);
}
else
{
if (pMsg->wParam == VK_UP)
{
// User pressed the arrow up
}
return TRUE;
}
return CStatic::PretranslateMessage(pMsg);
Does it seem right? Thanks.
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4376 (20090828) __________
David Webber
> Thanks. I got it to work following your method although I'm not sure I
> understand why it is working and if I'm doing things right.
>...
> It is ASCII; Note: I noticed that VK_UP is defined as "38" and somehow '&'
> in the ASCII table is also 38.
>...
Don't confuse the virtual key codes (VK_...) with ASCII character numbers!
They are completely different beasts!
The key codes are listed at:
http://msdn.microsoft.com/en-us/library/ms927178.aspx
and defined in winuser.h where a comments tells us that VK_A to VK_Z are
numerically the same as 'A' to 'Z' (but that's just because they've defined
them like that).
At the hardware level there are 'scan codes' which corresponds with keys.
But they are input-device-dependent. These can be converted to 'virtual key
codes' which are advertised as 'device independent'. But related to
keys - not ASCII codes - in a device independent way.
For example if you want to catch punctuation - eg a double quote - then do
it with WM_CHAR and its ASCII value, because it's in a different position
on different keyboards. On mine its SHIFT+2, so I'd probably get VK_2 and
need to check whether shift was pressed. On someone else's, where it's not
SHIFT+F2, then there'll be a different virtual key code. This is why you
need to work with both WM_CHAR and WM_KEYDOWN if you want to handle input
from all the different national keyboards.
I looked into all this a long time ago and forget a lot of the details, butt
I *think* this is right.
vvf
Hi David,
> For example if you want to catch punctuation - eg a double quote - then do
> it with WM_CHAR and its ASCII value, because it's in a different position
> on different keyboards. On mine its SHIFT+2, so I'd probably get VK_2
> and need to check whether shift was pressed. On someone else's, where
> it's not SHIFT+F2, then there'll be a different virtual key code. This
> is why you need to work with both WM_CHAR and WM_KEYDOWN if you want to
> handle input from all the different national keyboards.
>
> I looked into all this a long time ago and forget a lot of the details,
> butt I *think* this is right.
Thanks a lot for all the clarifications. It makes perfect sense what you are
saying and it really helped me a lot in understanding how the input
mechanism works and thus how to write flexible code.
vvf