I'm new to dealing with BlackBerry devices. I'm currently running into a JavaScript issue on a 9700 and trapping keypress events and getting a proper keycode.
I have this javascript:
function numbersonly(e) {
var key
if(window.event) {
key = window.event.keyCode; // IE
}else{
key = e.which; // Firefox
}
alert('keycode : ' + key);
}
And it's attached to an input field via an unobtrusive addEvent script.
On a standard desktop browser (Firefox and IE), it does what you'd think it does...pressing a key will show the keycode via the alert.
On a blackberry, however, pressing a key does one of two things:
if the key presses is the numbers 1 through 9, nothing happens.
if it's any other key, the keyCode is 'undefined'.
Any idea what's going on? I assume it's a limitation of the BlackBerry JavaScript support.
UPDATE:
Tested this on a 9800 Simulator as well, which is running OS6. Problem doesn't exist there. So this is either an issue with BlackBerry OS5 or BlackBerry's physical keyboard.
I'm not sure if the event variable is set when you add an inline event handler.
Have you tried setting the event-handler from javascript. So something like
document.getElementById('mytextelement').onkeypress = keytest;
Try using e.keyCode instead of e.which
Related
This is Mac only problem; I've tried this on windows and it works fine.
I have a script that saves which keys are pressed on keydown and deletes them on keyup.
$(function(){
var keys = [];
$(document).keydown(function(event) {
keys[event.which] = true;
});
$(document).keyup(function(event) {
delete keys[event.which];
console.log(keys);
});
});
All I am doing right now is console logging whatever is left after the keyup, which should be nothing. This works as expected when you press any number of keys simultaneously.
HOWEVER, when you press command and any other key, the other key is NOT released! So console.log will show that key to be true. This will remain true until you press that key itself.
This only happens on a Mac, and it only happens when one of the keys pressed is the Command key. Here is a very simple plunker with the above example.
Any ideas?
The Mac is modifying your key whenever you press Command, and thus the normal keyup event never fires.
C = command key and K = non-command key
As you press C and K, they register normally. While they are both simultaneously pressed, the Mac captures K and modifies it. In modifying K, the Mac somehow makes K's keyup event not fire as it is supposed to. C's keyup works as expected, however.
Since K's keyup never actually fires, it won't correctly delete the matching element from keys. Later on when you press K without C, the keydown event overwrites the existing keydown in keys. And when K's keyup correctly fires, it works as expected.
In addition to all the normal keys used to input ASCII characters,
keyboards typically have many special purpose keys that do other
things. These do not necessarily generate the same events as normal
keys, and they show less consistency across browsers.
JavaScript Madness: Keyboard Events. Potentially helpful article for all key-related problems.
I can't fix this Mac issue, but here is my way of getting around it.
This answer will help you if you are trying to have keyboard-shortcut behavior, where the user presses CMD+S to do save, or something like that. This answer does not apply to people who may be building a game or something where their keyboard's keydown states need to be known at each run frame. Sorry!
In the KeyboardEvent returned by keydown, you can do the following
$(document).keydown(function(keyboardEvent) {
if (keyboardEvent.metaKey){
// on Mac, CMD is down ...or Meta key is down on pc
console.log(keyboardEvent.meta + " & command key are down")
switch (keyboardEvent.which) {
...
}
}
});
If your keyboard shortcut overlaps with the browser's, you need to make sure to cancel the propagation of the keyboard event,
keyboardEvent.preventDefault()
I hope this helps people who want keyboard shortcut functionality that is Mac compatible!
I'd like to have Javascript respond to a keypress or keydown event from only the numeric keypad Enter key, not the usual Enter key. They both seem to generate the same event data according to the demo in the jQuery keypress docs, so I'm not sure it's possible.
They do generate the same keystroke data, at the level of abstraction that JavaScript has access to. Remember, JavaScript lives in a sandbox (the browser) and has no direct access to the underlying hardware (there are plenty of platforms that don't have a numeric keypad at all, but do have a browser).
This cannot be done.
EDIT:
Support for this has been added for some browsers but does not seem to be universal (see the other answer).
it is possible to detect the numpad Enter as seperate key nowadays. With the KeyboardEvent.location property. this way you can firstly check the keycode 13 and after if the key is on the numpad which devines the numpad enter.
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/location
example:
window.onkeydown=function(ev)
{
var e= ev || window.event,
key = e.keyCode
if ((key===13) && (e.location===3)) {
console.log("got ya");
console.log(e.location);
}
}
I'm using the following code to detect users' key pressing, in JavaScript:
$(document).bind('keydown', function (event) {
'use strict';
var keyCode = event.keyCode;
switch (keyCode) {
case '{N}':
doSomething();
break;
default:
break;
}
});
Where doSomething is a previously defined function and {N} is any of the JavaScript Char Codes.
It works properly in every major browser, but in Opera even if a key remains pressed, it only calls doSomething once, instead of doing it until the key is released.
What can I do to fix this?
Edit
I solved it using the keypress event instead of keydown (which is not well handled by Opera).
Opera makes a mess, the keydown event does not repeat, and you cannot prevent the default for keydown in opera. For more http://quirksmode.org/dom/events/
this is a known bug which should (finally!) get fixed soon. In short, keydown events are not repeated while keypress events are. Listening to keypress instead if you want repetition (and don't care about keys that do NOT fire keypress in all browsers like most function keys) should be a reasonable cross-browser solution.
$(document).keydown(function (event)
{
alert(event.which);
});
For the semicolon key, ;, this gives 59 in Firefox and 186 in Chrome. However, from the jQuery reference page for the keydown event, it says
"While browsers use differing properties to store this information, jQuery normalizes the .which property so you can reliably use it to retrieve the key code. This code corresponds to a key on the keyboard, including codes for special keys such as arrows."
Am I missing something?
The which property is a "one stop shop" for which key was pressed, allowing you to ignore the differences between the keyCode and charCode properties. That is the "normalization" that jQuery provides.
The difference in the value of which comes down to a difference between the way the various browsers supply the information - so you'll have to write code to handle the different values that come back. There are a few references to this behavior online.
A quick Google search says you will simply have to test for both. This is a consistent inconsistency with Firefox.
I don't know about jQuery but I'd suggest sticking to keypress events for typing keys and only using keydown events for special keys such as arrows.
Here is the entirety of the "normalization" that jQuery does:
if ( event.which == null ) {
event.which = original.charCode != null ? original.charCode : original.keyCode;
}
Looks like it just gets keyCode if charCode doesn't exist. And charCode is only used if event.which doesn't already exist. It doesn't change the numbers around to make them consistent.
This question already has answers here:
ReferenceError: event is not defined error in Firefox
(2 answers)
Closed 6 years ago.
I'm using this code to check for keydown and display the string 'Pressed' while a key is down.
<body onKeyDown="doKey(window.event.keyCode)" onKeyUp="doKey2(window.event.keyCode)">
<script>
function doKey($key) {
document.getElementById('keydown').innerHTML='Pressed';
}
function doKey2($key) {
document.getElementById('keydown').innerHTML='';
}
</script>
<div id="keydown"></div>
The problem is that for some reason it's only working on Chrome. I think the 'window.event.keyCode' doesn't return anything. How do I make it work at least in Firefox too? Thanks
Some browsers have a global event object, other send the event object to the event handler as a parameter. Chrome and Internet Exlporer uses the former, Firefox uses the latter.
Some browsers use keyCode, others use charCode.
Use arguments[0] to pick up the event object sent as a parameter, and if there is no object there, there is a global object instead:
onkeydown="doKey(arguments[0] || window.event)"
In the method you can check for either keyCode or charCode
function doKey(event) {
var key = event.keyCode || event.charCode;
...
}
Note the lowercase name onkeydown. If you are using XHTML event names has to be lowercase, or the browser might ignore it.
<html>
<body onKeyDown="doKey(event)" onKeyUp="doKey2(event)">
<script>
function doKey(e) {
evt = e || window.event; // compliant with ie6
document.getElementById('keydown').innerHTML = evt.keyCode+' Pressed';
}
function doKey2(e) {
document.getElementById('keydown').innerHTML='';
}
</script>
<div id="keydown"></div>
</body>
</html>
If we passed event as parameter, most modern browsers will work well. I have tested with Chrome 12, Firefox 4, IE 7/8/9.
I've run into the same problem, as I'm sure thousands of coders have.
The problem is that the browsers (other than IE) don't like window.event.
I'm poking around trying to find a solution (which is how I stumbled across this), and I found the following (so far):
1) Write JQuery:
$(document).keyup(function(e) {
var GetKey = e.keyCode;
`enter code here`
}
});
2) Redefine the key variable:
var key = (window.event) ? evt.keyCode : evt.which;
I tried the JQuery solution. It seems to be okay in FF, but I ran into an unexpected bug in IE that I'm still trying to solve. I haven't yet tried the second solution; that's next, if I can't get the JQuery to work.