KeyPress Events in IE

Is there any way in JavaScript to determine which key has been pressed
during any of the key-press, key-down, key-up events in IE6+? It
appears the "which" property only works for Netscape.

I can help you with this!

In netscape, it is evt.which. In IE, it's event.keyCode. Here's a snippet
of code I use:

function onlyNumbersXB(obj, e, mask) {

var keyCode;
var returnVal = false;

if (window.event) {
e = window.event;
keyCode = e.keyCode;
} else {
// a key, such as delete, was pressed; let it pass through
if (e.keyCode == e.which) keyCode = null;
// else if not a char we don't know what this is; let it pass through
else if (e.charCode != e.which) keyCode = void 0;
// else a char - set it
else keyCode = e.which;
}

// do whatever you want based on keyCode...

// now for the return
if (window.event) {
e.returnValue = returnVal;
return returnVal; // not really necessary but I'm trying to get
Safari to work
} else
return returnVal;
}

}

This method is invoked on a text field, onKeyPress='return
onlyNumbersXB(this, event, mask)'

My problem, as posted elsewhere, is getting Safari to behave itself. It has
window.event and behaves that way. It sets e.returnValue appropriately. It
still doesn't recognize "false" and let's the key pass.

Anyone?

Julia

"Ron Brooks" <ronbrooks (AT) dendress (DOT) com> wrote

Is there any way in JavaScript to determine which key has been pressed
during any of the key-press, key-down, key-up events in IE6+? It
appears the "which" property only works for Netscape.

"Jules" <jules9514 (AT) yahoo (DOT) com> wrote

<snip>

My problem, as posted elsewhere, is getting Safari to behave itself.
It has window.event and behaves that way. It sets e.returnValue
appropriately. It still doesn't recognize "false" and let's the
key pass.

Did you try the W3C DOM events - preventDefault - method, combined with
checking that the event is cancelable by checking the event's W3C DOM
(boolean) - cancelable - property? Also (assuming that is no-go) have
you considered trying to cancel onkeydown and/or onkeyup instead of (or
in addition to) onkeypress?

Richard.

"Richard Cornford" <Richard (AT) litotes (DOT) demon.co.uk> wrote

"Jules" <jules9514 (AT) yahoo (DOT) com> wrote in message
news:127051ac07a23678f1365bca20fde760 (AT) news (DOT) teranews.com...
snip
My problem, as posted elsewhere, is getting Safari to behave itself.
It has window.event and behaves that way. It sets e.returnValue
appropriately. It still doesn't recognize "false" and let's the
key pass.

Did you try the W3C DOM events - preventDefault - method, combined with
checking that the event is cancelable by checking the event's W3C DOM
(boolean) - cancelable - property?

I did try preventDefault() -- no go. I don't know what you mean by
"combined with if the event is cancelable". What would combining the two
do?

Also (assuming that is no-go) have
you considered trying to cancel onkeydown and/or onkeyup instead of (or
in addition to) onkeypress?

Yea - except we have problems with onKeyDown and Netscape 7. That's why we
went with onKeyPress.

Canceling keystrokes is something that whole documents have been written
about regarding IE and Netscape. I can't believe that I can be the only
person struggling with this with Safari...

Julia

"Jules" <jules9514 (AT) yahoo (DOT) com> wrote

<snip>

I did try preventDefault() -- no go. I don't know what you
mean by "combined with if the event is cancelable". What
would combining the two do?

I mean that if the event object has the W3C DOM events specified
boolean - cancelable - property and it is false then there is not much
point in calling its - preventDefault - method as the event cannot be
cancelled.

Also (assuming that is no-go) have you considered trying to
cancel onkeydown and/or onkeyup instead of (or
in addition to) onkeypress?

Yea - except we have problems with onKeyDown and Netscape 7.
That's why we went with onKeyPress.

Canceling keystrokes is something that whole documents have
been written about regarding IE and Netscape. I can't
believe that I can be the only person struggling with this
with Safari...

Validating user input as they type is problematic at best, clear
instructions often make it unnecessary and you usually won't catch paste
operations so the field would still need to be validated onsubmit
anyway. These days I probably would not bother so I do not know any
currently recommended method.

However, though I don't have access to a Mac at present so I cannot test
Safari, I would expect Konqueror (on which Safari is based) to exhibit
the same problem, so if you could make up a minimal test case page that
does exactly what you require where it is working now (and preferably
nothing else) and post it (or a URL to an online version) then I (and/or
someone else) would probably have a look at it and see if it cannot be
made to do what you want.

Julia

That is not a name you see often these days. You share it with my sister


Richard.