I spotted that BACKSPACE wasn't working for one of my sketches, if I tested
for key == CODED first. I'm testing on Windows 2000 but I have reason to
believe it's the same on Linux.

Here's some code which demonstrates the problem...

void keyPressed() {
println(key == CODED);
println("key= \"" + key + "\"");
println("CODED= \"" + CODED + "\"")
println(java.lang.Character.getNumericValue(key));
println("keyCode= \"" + keyCode + "\"");
println("BACKSPACE= \"" + BACKSPACE + "\"");
}

Special keys like BACKSPACE and ENTER are working, but key is not being
assigned as CODED. In PApplet.java CODED is only mentioned in comments, so
it wasn't clear where the bug might have crept in.

I should add that I'm pretty sure it worked in 0091 - at least, it worked
in this sketch I built in July:

http://www.tom-carden.co.uk/p5/osm_lines_text/applet/index.html

Also, I've been testing with 0095 Standard, so it shouldn't be a Java 1.5
problem or anything.

With further testing, I find it's only ENTER, TAB and BACKSPACE that don't
assign keyCode as expected. Arrow keys, function keys, ALT, SHIFT and CTRL
all work correctly.

With this testing code:

void keyPressed() {
println("key == CODED: " + (key == CODED));
println("key == KeyEvent.CHAR_UNDEFINED: " + (key ==
KeyEvent.CHAR_UNDEFINED));
println("CODED == KeyEvent.CHAR_UNDEFINED: " + (CODED ==
KeyEvent.CHAR_UNDEFINED));
println("KeyEvent.CHAR_UNDEFINED: " + KeyEvent.CHAR_UNDEFINED);
println("Character.getNumericValue(key): " +
Character.getNumericValue(key));
println("key= \"" + key + "\"");
println("keyCode= \"" + keyCode + "\"");
println("BACKSPACE= \"" + BACKSPACE + "\"");
println("CODED= \"" + CODED + "\"");
println();
}

Output for BACKSPACE is:

key == CODED: false
key == KeyEvent.CHAR_UNDEFINED: false
CODED == KeyEvent.CHAR_UNDEFINED: true
KeyEvent.CHAR_UNDEFINED: ?
Character.getNumericValue(key): -1
key= ""
keyCode= "8"
BACKSPACE= "8"
CODED= "65535"

Output for the ENTER key is:

key == CODED: false
key == KeyEvent.CHAR_UNDEFINED: false
CODED == KeyEvent.CHAR_UNDEFINED: true
KeyEvent.CHAR_UNDEFINED: ?
Character.getNumericValue(key): -1
key= "
"
keyCode= "10"
BACKSPACE= "8"
CODED= "65535"

Output for the TAB key is:

key == CODED: false
key == KeyEvent.CHAR_UNDEFINED: false
CODED == KeyEvent.CHAR_UNDEFINED: true
KeyEvent.CHAR_UNDEFINED: ?
Character.getNumericValue(key): -1
key= " "
keyCode= "9"
BACKSPACE= "8"
CODED= "65535"

---------

For the moment, I'm just catching Character.getNumericValue(key) == -1
instead but I don't know if that's sensible.

this would be the fault of sun's awt implementation of how key events are handled. i'm not
doing anything additional to manipulate what comes back from getKeyChar() and
getKeyCode(), and i'm hesitant to start redefining how it works. presumably sun has some
reason that they're doing things this way... (or maybe not and it's filed somewhere in their
bugs db... let me know if you find anything). i suspect that perhaps if keys are part of the
ascii charset then they never show up as what we call CODED?

OK fair enough. I think I was just surprised that it had changed behaviour
for me, but I can't work out why.

For the record, Character.getNumericValue(key) == -1 was a bad way to test
it because it means you lose punctuation characters which don't have a
numerical value. Now we're just testing explicitly for
ENTER/TAB/BACKSPACE, which works fine.

I think you're right that in those three cases key can been assigned
something meaningful - it's a shame that when you add whatever the
backspace character is to a String it doesn't automatically delete the last
character :)

yeah, i've never quite understood why/how they implemented the api the way
they did with regards to the control keys. unfortunately they're even
handled differently based on whether it's keyPressed() or keyTyped()..
which sort of makes sense, but makes things a mess to document (lots of
notes in the javadoc about this).