A DESCRIPTION OF THE REQUEST :
Java loses critical information given by the operating system when generating KeyEvent objects. Specifically, the KeyEvent instance generated when CTRL+break (aka CTRL+pause) and others (CTRL+Print Screen) returns a vlaue of UNDEFINED from KeyEvent.getKeyCode().

JUSTIFICATION :
This is presumably because this key combination on the platform this RFE is submitted for- Windows- represents a "process break request".

This information should not be discarded but instead should be kept available to developers who use KeyEvent instances.

The reasons this should be reconsidered are:

1) because this return value from getKeycode is not unique to CTRL+break, the actual keystrokes issued by the end user will always be invisible to the Java application developer. For example, this same return value for getKeyCode() is generated by CTRL+Scroll Lock. Other key combinations may also return this same value in the future.

That's a problem for Java developers for a number of reasons but first, it's important to notice that CTRL+break (and also CTRL+Screen Lock) actually *do nothing* under most circumstances on most Windows computers. This means that, to the naive Windows/Java application consumer, these key combinations are not distinguished in any particular way.

When the Java developer attempts to offer a certain kind of common functionality, for instance a macro-binding fucntion for role playing game or a photo-editing application or word processor, these key events are undistinguishable to the Java programmer. The Java programmer can't tell if CTRL-break was keyed-in by the application user or some other key combination.

As it is, the applcation developer can only treat any KeyEvent which returns UNDEFINED from getKeyCode as a general input error and all such (different) keyEvents as the same; yet the user has no idea why this key-combination should considered an "input error", and really, in these common contexts, it should not.

The information about the actual keystrokes does exist at the level of the OS, but Java removes this information and leaves no way for the programmer to get it back.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The KeyEvent should be made to give programmer's access to the actual keystrokes which generated the keyEvent.
ACTUAL -
The KeyEvent provides no avenue at all for the programmer to reconstruct the actual keystrokes of the user.

---------- BEGIN SOURCE ----------
public void showKeyEventInformation(KeyEvent keyEvent)
{
if (KeyCode.UNDEFINED==keyEvent.getCode())
System.out.println("Keycode is undefined");

String text = keyEvent.getText();
// empty String

keyEvent.getCharacter();
//empty String

keyEvent.toString);
//unhelpful toString() representation with class instance information
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
No workaround