JDK-6182651 : Need to identify any key pressed/released with a unique code
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0,5.0u9
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_10,windows_xp
  • CPU: x86
  • Submitted: 2004-10-21
  • Updated: 2011-05-17
  • Resolved: 2011-05-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
7 b55Fixed
Related Reports
Duplicate :  
Relates :  
Many national standard keys on various international keyboards are actually mapped to VK_UNDEFINED because there is no VK_xxx code defined for them. This in true for example for "��" and "��" keys on standard french keyboard, "��", "��", "��", "��" and "��" keys on canadian keyboard and "��", "��", "��", "��" keys on swiss french keyboard.
On most keyboard, the keys affected are (positions given in US-international keyboard) the key left to "1", the two or three keys right to "0", the two keys right to "P", the three keys right to "L", the key left to "Z", the three or four keys right to "M". Microsoft uses identifiers OEM1..OEM102 for those keys when they are not assigned to a common US keyboard key (ie. comma, period, semicolon, minus, equals, dollar, ...).

Most of the time in Java one could distinguish between them by looking at the character, but sometimes no character in associated with the key. This is especially true when using AltGr modifier and no character is mapped to this combination or it is a dead key for some less used combining accent character. This is also true for special function keys on multimedia keyboards since fonction keys have no character.

In those cases we need a way to identify unequivocally the key being pressed.

Any unique key on the keyboard should be given a unique identifier.
VK_UNDEFINED should be used only for event not associated with any particular key (for example robot generated keys, meta-sequence input, etc...).
It is unacceptable to have a dozen keys being mapped to the same code when the underlying system can differentiate them.

Each and every key should have its own KeyCode.
Any of the following behaviors could be acceptable (the first is preferred)
- a set of generic purpose keycodes could be added to KeyEvent (for exemple VK_UNKNOWN1..VK_UNKNOWN256). When there is no specific VK_xxx code, the JVM maps each key to a different VK_UNKNOWNx code in a cross platform way (given a keyboard layout, the KeyCode is the same on every platform, possibly reflecting the most common physical position of the key)
- an extended keyCode could be given for unknown keys (this could be the underlying scancode, but has not to be so in every implementation as far as it is unique). The code is not the same on every platform but is guaranted to be unique for each key on a given platform/layout

Most uncommon keys maps to VK_UNDEFINED, and there is no way to tell which one is pressed.

The only workaround so far is to use native code to get the scan code directly from the underlying system.
There is no workaround for a "pure java" solution.
###@###.### 10/21/04 17:30 GMT

EVALUATION In the fix to 6680988 a new KeyEvent method getExtendedKeyCode introduced. It could remedy _some_ of the problems described in this RFE as it does produce a unique (extended) key code for most unicode-generating keys on Latin and non-Latin keyboards such as Hebrew, Arabic, Russian, etc. Unfortunately, this API cannot cover so called command keys, unknown keys producing no unicode. It is especially hard to fix in system-independent fashion as we usually have no access to the low-level keyboard information on X-Window systems. As a workaround, we do provide a scancode under MS Windows; certain special keyboard systems used i.e. in telephony already use this option. For X Window, a rawCode is available, however neither of these codes is consistent between the systems.

PUBLIC COMMENTS [SQE] New API introduced to provide a unique ID for every unicode-producing key. To verify it, one should make a non-English keyboard layout active, receive KeyEvents and check values returned by getExtendedKeyCode(). [/SQE]