A DESCRIPTION OF THE REQUEST :
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.

JUSTIFICATION :
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.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
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)
or
- 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

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

CUSTOMER SUBMITTED WORKAROUND :
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