Discussion:
Keyboard keycodes.
(too old to reply)
Gary
2006-09-19 05:19:48 UTC
Permalink
Hello Experts,
I have a question regarding the keyboard codes which get generated on
pressing a particular key in a keyboard.
While debugging in a Korean env , we are seeing that the keycode=229 is
generated. I would like to know, corresponding to which keystroke this
keycode ( 229 ) gets generated ?
Is there a pre-defined mapping already in place which serves as a rule
to generate the keycode, when a key is pressed. If that's the case, how
can I view the pre-defined mapping on a general keyboard in any env.

Regards,
Gary.
Jeffrey Tan[MSFT]
2006-09-20 03:07:36 UTC
Permalink
Hi Gary,

Can you tell me how do you get the key stroke value *229* while debugging?
What does it standard for?

Based on my experience, I assume that you are getting this value while
handling WM_KEYDOWN message, and this *229* value is passed in wParam
parameter of the handler. If I have misunderstood you, please feel free to
tell me, thanks.

Yes, Microsoft tries to abstract all the keyboard hardware layout so that
the developer can write keyboard application uniformly. To achieve this
goal, Microsoft provided a standard keyboard mapping for various keyboards.
This mapping is called Virtual-Key Codes. You may find the Virtual-Key
Codes map in winuser.h file or in the MSDN link below:
"Virtual-Key Codes "
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI
/WindowsUserInterface/UserInput/VirtualKeyCodes.asp

In your scenario, the Virtual Key code for *229*(0xE5) you got is
VK_PROCESSKEY, which is the IME PROCESS key.

So your question lies with how and why VK_PROCESSKEY is generated while
typing keys in your application.

I will spend some time in this issue and collect more information regarding
VK_PROCESSKEY to you ASAP. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Gary
2006-09-20 09:14:32 UTC
Permalink
Jeffrey,
Thanks for your response. The issue is...when our application runs in
an Korean env, we are seeing that on the left-click of a mouse TWO
events get generated. First is the one, which I had talked about i.e.
*229* & the other is the general onClick mouse event. My question is,
why should the *229* will get generated in this scenario on a simple
left-mouse-click in a Korean env ? We were able to see this inside the
debugger.
In case of a machine in US ( a keyboard supporting English env ) we dont
see this issue. There...... on the left-click of a mouse we see only one
event getting generated i.e. the onClick event.

Regards,
Gary.
Post by Jeffrey Tan[MSFT]
Hi Gary,
Can you tell me how do you get the key stroke value *229* while debugging?
What does it standard for?
Based on my experience, I assume that you are getting this value while
handling WM_KEYDOWN message, and this *229* value is passed in wParam
parameter of the handler. If I have misunderstood you, please feel free to
tell me, thanks.
Yes, Microsoft tries to abstract all the keyboard hardware layout so that
the developer can write keyboard application uniformly. To achieve this
goal, Microsoft provided a standard keyboard mapping for various keyboards.
This mapping is called Virtual-Key Codes. You may find the Virtual-Key
"Virtual-Key Codes "
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI
/WindowsUserInterface/UserInput/VirtualKeyCodes.asp
In your scenario, the Virtual Key code for *229*(0xE5) you got is
VK_PROCESSKEY, which is the IME PROCESS key.
So your question lies with how and why VK_PROCESSKEY is generated while
typing keys in your application.
I will spend some time in this issue and collect more information regarding
VK_PROCESSKEY to you ASAP. Thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Jeffrey Tan[MSFT]
2006-09-22 02:43:33 UTC
Permalink
Hi Gary,

Oh, it seems that while I am sending the second reply to you, you posted a
reply to me, so I almost missed your reply in our internal support tool.

Can you be specific in which message do you get *229* value during the
mouse left-click? Since your original post stated that you got the *229*
value during pressing a particular key in a keyboard. So I am not sure
*229* is really generated by mouse click or key stroke.

Also, can you be specific *229* is got from which parameter during the
message handling, wParam or lParam? Or *229* is just the numeric value of
the message?

Without above message context information, it is hard for me to provide an
analysis. Thank you for the information.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Gary
2006-09-22 08:34:39 UTC
Permalink
Jeffrey,
We have the handlers registered for a key down & up events. Now, after
a " left-mouse-click " we see that the browser ( IE ) calls our handler
with a keycode of *229*. Since we dont handle any *229* in our appln, so
it goes to the default case in the switch-case block & bail out with an
error. We debugged inside the switch-case to figure out that the keycode
was *229*.
I hope the above explains clearly the situation.

Now my question is: What are the implications/side-effects of
masking-off that keycode for any application ? Is it safe enough?
Apparently it does not seem that we require any processing for that
keycode. But do you have any idea if thats something a must-to-handle in
a Korean env or that its upto the appln to decide on that, depending on
the appln's logic ?

Thanks for your inputs, Jeffrey.

Regards,
Gary.
Post by Jeffrey Tan[MSFT]
Hi Gary,
Oh, it seems that while I am sending the second reply to you, you posted a
reply to me, so I almost missed your reply in our internal support tool.
Can you be specific in which message do you get *229* value during the
mouse left-click? Since your original post stated that you got the *229*
value during pressing a particular key in a keyboard. So I am not sure
*229* is really generated by mouse click or key stroke.
Also, can you be specific *229* is got from which parameter during the
message handling, wParam or lParam? Or *229* is just the numeric value of
the message?
Without above message context information, it is hard for me to provide an
analysis. Thank you for the information.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Jeffrey Tan[MSFT]
2006-09-22 14:24:35 UTC
Permalink
Hi Gary,

Thanks for your explanation. Yes, your reply makes the problem clearer now.
Yes, *229* is actual the Virtual Key value of the WM_KEYDOWN message. In
this scenario, *229* standards for VK_PROCESSKEY based on the Virtual-Key
Codes map below:
"Virtual-Key Codes "
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/UserInput/VirtualKeyCodes.asp

I am not sure if you have reviewed my second reply to you, I think the
information I provided in the second reply should address your question.

Actually, only when IME is active, the wParam of the WM_KEYDOWN message will
be VK_PROCESSKEY, it means this is the IME PROCESS key. The actual virtual
key code is not posted to the application at this time.

In your scenario, it is likely when you clicked the IE window, the default
focus will be in certain TextBox in the IE page, while at the same time the
Korean IME is active, so the wParam is VK_PROCESSKEY instead of the actual
key.

Below is more detailed background information regarding how IME does the
trick to generate VK_PROCESSKEY:
When the user presses a key, the system generates a keyboard event. USER.EXE
checks to see whether the currently active input language handle (HKL)
points to an IME. If so, USER.EXE passes the keyboard event to the Input
Method Manager, which passes the event to the IME. If the IME intends to
respond to the keyboard event (for example, when the user presses the
Spacebar to activate the candidate window on Japanese Windows), the IME
translates the keyboard event into the virtual key, VK_PROCESSKEY, which it
passes back to the IMM. The IMM then sends this virtual key to the
application. If the application provides a customized IME user interface, it
can trap VK_PROCESSKEY and call the API ImmGetVirtualKey to translate it
into a more specific virtual key value, and then respond accordingly. For
example, if the virtual key is VK_SPACE, the application would respond by
calling code to paint the candidate window.

Please refer to the article below for more information:
"Full IME Support"
http://www.microsoft.com/globaldev/dis_v1/disv1.asp?DID=dis28d&File=S24B6_f3.asp

So there is no need for your application to respond to WM_KEYDOWN with
VK_PROCESSKEY, since this message is used by IME.

If you still have anything unclear, please feel free to feedback, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notifications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support Engineer
within 1 business day is acceptable. Please note that each follow up
response may take approximately 2 business days as the support professional
working with you may need further investigation to reach the most efficient
resolution. The offering is not appropriate for situations that require
urgent, real-time or phone-based interactions or complex project analysis
and dump analysis issues. Issues of this nature are best handled working
with a dedicated Microsoft Support Engineer by contacting Microsoft Customer
Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Gary
2006-09-27 13:39:58 UTC
Permalink
Thanks a lot Jeffrey. Your updates made a lot of sense to us. We have
masked off the *229* keycode in our appln , since that didnt seem to be
of much relevance in a working scenario, given the appln's functionality.

Thanks again,
Gary.
Post by Jeffrey Tan[MSFT]
Hi Gary,
Thanks for your explanation. Yes, your reply makes the problem clearer now.
Yes, *229* is actual the Virtual Key value of the WM_KEYDOWN message. In
this scenario, *229* standards for VK_PROCESSKEY based on the Virtual-Key
"Virtual-Key Codes "
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/UserInput/VirtualKeyCodes.asp
I am not sure if you have reviewed my second reply to you, I think the
information I provided in the second reply should address your question.
Actually, only when IME is active, the wParam of the WM_KEYDOWN message will
be VK_PROCESSKEY, it means this is the IME PROCESS key. The actual virtual
key code is not posted to the application at this time.
In your scenario, it is likely when you clicked the IE window, the default
focus will be in certain TextBox in the IE page, while at the same time the
Korean IME is active, so the wParam is VK_PROCESSKEY instead of the actual
key.
Below is more detailed background information regarding how IME does the
When the user presses a key, the system generates a keyboard event. USER.EXE
checks to see whether the currently active input language handle (HKL)
points to an IME. If so, USER.EXE passes the keyboard event to the Input
Method Manager, which passes the event to the IME. If the IME intends to
respond to the keyboard event (for example, when the user presses the
Spacebar to activate the candidate window on Japanese Windows), the IME
translates the keyboard event into the virtual key, VK_PROCESSKEY, which it
passes back to the IMM. The IMM then sends this virtual key to the
application. If the application provides a customized IME user interface, it
can trap VK_PROCESSKEY and call the API ImmGetVirtualKey to translate it
into a more specific virtual key value, and then respond accordingly. For
example, if the virtual key is VK_SPACE, the application would respond by
calling code to paint the candidate window.
"Full IME Support"
http://www.microsoft.com/globaldev/dis_v1/disv1.asp?DID=dis28d&File=S24B6_f3.asp
So there is no need for your application to respond to WM_KEYDOWN with
VK_PROCESSKEY, since this message is used by IME.
If you still have anything unclear, please feel free to feedback, thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notifications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support Engineer
within 1 business day is acceptable. Please note that each follow up
response may take approximately 2 business days as the support professional
working with you may need further investigation to reach the most efficient
resolution. The offering is not appropriate for situations that require
urgent, real-time or phone-based interactions or complex project analysis
and dump analysis issues. Issues of this nature are best handled working
with a dedicated Microsoft Support Engineer by contacting Microsoft Customer
Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Mihai N.
2006-09-20 08:21:31 UTC
Permalink
Post by Gary
I have a question regarding the keyboard codes which get generated on
pressing a particular key in a keyboard.
What level are we talking about?

Scancode: the old port level
Virtual key: VK_XXX

Both of these you can see as info for WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN,
WM_SYSKEYUP

Then you have the character level, that you can see with WM_CHAR, and
WM_UNICHAR

We can also take a look at IME messages, if this is what you need, but it
would help if you can explain a bit what you want to achieve.
--
Mihai Nita [Microsoft MVP, Windows - SDK]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email
Jeffrey Tan[MSFT]
2006-09-20 10:20:25 UTC
Permalink
Hi Gary,

Sorry for letting you wait.

After performing test, I can reproduce this issue in my Windows with
notepad.exe by using Spyxx. Actually, if the IME is active, when we type in
the notepad, the Windows will send a WM_KEYDOWN message with VK_PROCESSKEY.

When IME is active, the wParam of the WM_KEYDOWN message is VK_PROCESSKEY,
it means this is the IME PROCESS key. The actual virtual key code is not
posted to the application at this time.

Other useful information:
When the user presses a key, the system generates a keyboard event.
USER.EXE checks to see whether the currently active input language handle
(HKL) points to an IME. If so, USER.EXE passes the keyboard event to the
Input Method Manager, which passes the event to the IME. If the IME intends
to respond to the keyboard event (for example, when the user presses the
Spacebar to activate the candidate window on Japanese Windows), the IME
translates the keyboard event into the virtual key,
VK_PROCESSKEY, which it passes back to the IMM. The IMM then sends this
virtual key to the application. If the application provides a customized
IME user interface, it can trap VK_PROCESSKEY and call the API
ImmGetVirtualKey to translate it into a more specific virtual key value,
and then respond accordingly. For example, if the
virtual key is VK_SPACE, the application would respond by calling code to
paint the candidate window.

Please refer to the article below for more information:
"Full IME Support"
http://www.microsoft.com/globaldev/dis_v1/disv1.asp?DID=dis28d&File=S24B6_f3
.asp

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Continue reading on narkive:
Loading...