I guess I didn't really answer your question as far as what kind of key
codes event.keyCode & event.which return. After a little research, here is
the best description I can give (I may be slightly off, and with all the
different browsers and versions, it can be hard to cover it all):
event.keyCode:
In Internet Explorer, event.keyCode is the Unicode value of the
character typed (whether it be a, A, tab, enter, etc). Some keys do not even
trigger this event, such as shift & ctrl, which only trigger the keyup &
keydown events.
In Firefox, event.keyCode returns a key code for keys that do not create
a visible character (this includes tab & enter, but not space). For a good
reference, see
http://www.quirksmode.org/js/keys.html
event.which:
Internet Explorer does not use event.which
In Firefox, event.which is, based on my observations, the same as either
event.keyCode or event.charCode. Since only one of these two properties is
assigned a value (depending on what key is pressed), that same value is
assigned to event.which. I am guessing that the designers of Firefox did not
intend for event.which to be used, and to have you use only event.keyCode &
event.charCode.
--
Nathan Sokalski
(e-mail address removed)
http://www.nathansokalski.com/
You say that the value is "compared to a char value". Would you mind
telling
me where I do this? If you are thinking of typedchar, that is not a char
(actually, it doesn't even exist in the final result). In the last few
lines
of my code, you will notice that I replace the text "typedchar" with
either
event.keyCode or event.which, depending on the browser. If you look at
what
values the event.keyCode and event.which have, you will see why I do not
want the Unicode value.
Can you please clarify what kind of key codes do event.keyCode /
event.which return? When they correspond to characters, what encoding
are they in? You say that they are not Unicode - but then, what are
they? Certainly not just ASCII, otherwise they wouldn't properly
report non-Latin characters.
If they are in the default system encoding, then obviously it is the
default system encoding of the client (since JavaScript runs on the
client). In which case Asc() is actually incorrect, since it would use
the default system encoding of the server, and they need not match.
Anyway, I've wrote a simple test to see what is there:
<html>
<head>
<script type="text/javascript">
function keyPress() {
var div = document.getElementById("keycode");
div.innerText += event.keyCode;
div.innerText += '\n';
div.innerText += event.which;
div.innerText += '\n\n'
}
</script>
</head>
<body>
<textarea onkeypress="keyPress()"></textarea>
<div id="keycode"></div>
</body>
</html>
And on my system, both IE7 and Opera 9.5 display Unicode codepoints
for Russian characters I input, and not codepoints from my default
ANSI encoding (which would be win1251).
)