We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
Page Index Toggle Pages: 1
keyCode bug (Read 1455 times)
keyCode bug
Jul 21st, 2005, 12:33pm
 
excerpt from the online manual, section: keyCode

"The system variable keyCode is used to detect special keys such as the UP, DOWN, LEFT, or RIGHT keys on the keyboard. Other special key constants are ALT, CONTROL, SHIFT, BACKSPACE, TAB, ENTER, RETURN, ESC, and DELETE. Before testin which coded key is pressed it's necessary to test and see if the key is coded at all. This is done with the conditional "if(key == CODED) {}" as shown in the above example. "

however, key == CODED is a false statement when for example ENTER is pressed on the keyboard.
Re: keyCode bug
Reply #1 - Jul 25th, 2005, 11:03pm
 
It seems to be a case of vague documentation, not a software bug.

If one of backspace, delete, enter, tab, or escape is pressed, both key and keyCode will be set to the appropriate special value (BACKSPACE, DELETE, etc.), and not to CODED.

If one of the arrow keys, alt, control, option, shift, option, or a function key is pressed, key will equal CODED and keyCode will contain the appropriate special value (though I'm not sure if there are predefined constants for the last two).

The difference is that the former set of characters all have ASCII values (e.g. can be considered proper characters), while the latter don't, and are thus key presses which don't correspond to characters.  That is, you can store a TAB character (or BACKSPACE - weird, isn't it? - etc.) in a text file, but not UP, DOWN, SHIFT, etc.
Page Index Toggle Pages: 1