2

Based on the properties of the keydown event I would like to ascertain what the current charCode are?

Example.

For the keydown event when the NumPad0, D0, and Colon key is pressed I would like to know what the associated charcode is. Currently I have a map that contains the charcode associated with that keyCode or use the current if charCode is not specified.

keyCode = {
  Colon: 186,
  D0: 48,
  NumPad0: 96,
};
charCodes = {
  186: 59,
  96: 48,
};
shiftCharCodes = {
  186: 58,
  48: 41
};

Also in certain cases the keyCodes are different accross browsers?

Example.

The keydown event has different keyCode values across browsers. Colon Key (:/;) - keyCode is 59 on firefox - keyCode is 186 on IE/safari

For more information

http://www.quirksmode.org/js/keys.html

Drew Turner
  • 870
  • 8
  • 12
  • I don't know if it's relevant to your project but if it's for a game and that you use for example WASD keys, please think that I'd use ZQSD on my french AZERTY keyboard, that germans use QWERTZ, etc And I must press the shift key for numbers on the main keyboard (first one is &/1 key when qwerty has a 1/sth key). Webapps should be safe, as are up/left/down/right keys. – FelipeAls May 26 '10 at 22:25

2 Answers2

1

If you're interested in the character code associated with a keypress, you're going to get nowhere with the keydown event. The keypress event is the only place this information is available, and is not too problematic for most printable keys.

document.onkeypress = function(evt) {
    evt = evt || window.event;
    var charCode = evt.which || evt.keyCode;
    alert("Character: " + String.fromCharCode(charCode));
};

There are differences between browser behaviour around "special" non-printable keypresses such as function keys. For more information I consider this article by Jan Wolter to be the definitive reference for JavaScript key handling.

Tim Down
  • 318,141
  • 75
  • 454
  • 536
  • I too have spent much time referencing Jan's treatise on the current state of js key handling. And came to the same conclusion that he does: It is a nightmare. That is where a tightly focused and finely crafted javascript abstraction shines. – Sky Sanders May 26 '10 at 22:37
  • 1
    It's a complicated and maybe impossible job to create a complete abstraction that will fully handle thorny problems like preventing default behaviour and handling auto-repeated key events. I tend to write only as much of an abstraction as I need for the current task. – Tim Down May 26 '10 at 23:20
  • Another reason to use `keypress` is that there is not necessarily a one-to-one correspondence between keystroke and character. Some input methods have complex interactions, including deleting previous characters (often by synthesizing backspace) and inserting new ones, and it's safer not to assume any knowledge of what character a given keystroke produces. This is particularly true for non-European languages. – Marc Durdin Nov 24 '15 at 08:13
-1

Although I generally loath answers like the one I am about to give, I feel it is appropriate:

This is a perfect use case for a library like jQuery, Prototype, Dojo or MooTools.

You don't want to burden yourself with this work, it has already been done.

Sky Sanders
  • 36,396
  • 8
  • 69
  • 90
  • 2
    Not really - jQuery for one doesn't really concern itself with identifying keys. – Tim Down May 26 '10 at 22:24
  • @Tim - ok, let me be specific - so the hotkeys plugin which is *exquisite*. http://code.google.com/p/js-hotkeys/ – Sky Sanders May 26 '10 at 22:28
  • 1
    I almost feel like we need a shorthand for the loathing-but-appropriate-here case. http://stackoverflow.com/questions/423823/whats-your-favorite-programmer-ignorance-pet-peeve/2657095#2657095 – harpo May 26 '10 at 22:39
  • 1
    code poet: The hotkeys plugin looks fine for identifying keys. Once you get to things like preventing default behaviour and the different events browsers fire for repeated keypresses, you're going to need a bigger abstraction. – Tim Down May 26 '10 at 23:17