I want to keep track of which keys are pressed at a given time, like so:
var keys = {};
$(document.body).on('keydown', function(e) {
keys[e.keyCode] = true;
});
$(document.body).on('keyup', function(e) {
delete keys[e.keyCode];
});
However, from MDN it looks like keyCode is deprecated, and suggests key. From testing on Chrome, it looks like key is undefined. The documentation also describes which but I am unsure as to what the differences are.
Is keyCode the right thing to use here? I don't care which keys are down, only that I know that some keys are pressed. I also can't use the input event.
I would suggest to use a fallback mechanism which handles the advise from MDN first and than falls back to the older solutions.
But if you are using jQuery you should use the provided methods to get the key-code
// jquery
$(document.body).on('keyup', function(e) {
delete keys[e.which];
});
// vanilla
document.body.addEventListener('keyup', function (e) {
delete keys[(e.key && e.keyCode.charCodeAt(0)) || e.which || e.keyCode];
}, true);
However this will only be true for printable characters and needs a deeper investigation of the problem usually.
Related
I am new to Javascript, though i have used JQuery well. But i cant find a better documentation for doing this . The click event need to be triggered only if i press enter key. so i need to write test case for this scenario.
function btnRepeatKeyDownEvent(e){
if (e.keyCode === 13) {
this.trigger('click', e);
}
}
so far i have found this solution.
let keyboardEvent: KeyboardEvent = new KeyboardEvent('keypress', {'key': 'Enter'});
document.dispatchEvent(keyboardEvent);
but the above code always give keycode value as 0. i am more tired for finding the solution. As per MDN most of the functionalities are deprecated.
i need to made this test case workable in chrome, firefox and IE11+ only not for old browsers.Please help me.
The keyCode and other properties are Read Only. So, you can fake it, taking advantage of JavaScript's Object.defineProperties function that does overwrite values:
function makeKeyPressEvent(keyName, keyCode, charCode){
var event = new KeyboardEvent('keypress');
Object.defineProperties(event, {
charCode: {value: charCode},
keyCode: {value: keyCode},
keyIdentifier: {value: keyName},
which: {value: keyCode}
});
return event;
}
here is how to use it:
window.addEventListener('keypress', function(event){console.log('key pressed!', event.keyIdentifier, event.keyCode, event.charCode, event)}, true);
var enterKeyEvent = makeKeyPressEvent('Enter', 13, 13);
window.dispatchEvent(enterKeyEvent);
Is there a way to detect a shift-mouseclick on a polygon when using the google maps V3(.16) javascript API?
https://developers.google.com/maps/documentation/javascript/reference#MouseEvent
I do receive the mouse event, and I can see that the original event is wrapped in a google event class, which is just what's needed (Access the event.Ua.shiftKey property).
I found however that last month, google may have updated their api and now the property is renamed to event.Pa.shiftKey.
For reference, see http://i.stack.imgur.com/80npD.png for a screenshot of the event structure in the webinspector.
Is there any way to detect whether the shift key is pressed during a click on a google maps polygon using the event, and without having to rely on google-not-updating-their-api? What am I missing?
Thx!
Using undocumented properties is almost always a bad idea. If you can possibly avoid it, avoid it. In this case, the API is probably being compressed with the Closure Compiler, and so the next time they update, it may not be Pa anymore either.
Is there any way to detect whether the shift key is pressed during a click on a google maps polygon using the event, and without having to rely on google-not-updating-their-api?
If just Ua vs. Pa:
You could feature detect:
var shiftKey = (event.Ua || event.Pa).shiftKey;
That uses JavaScript's curiously powerful || operator to reference the Ua property's value, if there is one and it's truthy, or the Pa property's value otherwise.
This assumes that when they change it from Ua to Pa, they don't use Ua for something else. If there's a chance of that, this more thorough version would do it:
var shiftKey = ((event.Ua && 'shiftKey' in event.Ua) ? event.Ua : event.Pa).shiftKey;
That specifically checks for a Ua object with a shiftKey property, falling back to Pa if not found.
If it could be anything
...you can search for it:
var shiftKey;
if (Object.keys(event).some(function(key) {
if (event[key] && 'shiftKey' in event[key]) {
shiftKey = event[key].shiftKey;
return true;
}
return false;
})) {
// We found it, `shiftKey` has the value
} else {
// We didn't find it
}
Side note: Object.keys is an ES5 feature present on all modern browsers. If you need to support older browsers like IE8, it can be polyfilled.
I've just come across this problem (after noticing I couldn't just use window.event because Firefox doesn't support it)
google.maps.mouseEvent has, as T.J. Crowder said, a property which contains keys such as shiftKey, altKey, etc. In the current release of google maps api, said property is va. So of course we can't use it because its name will change in the next release of so.
So my solution has been to iterate over the google.maps.mouseEvent parameter, checking its values so see which one of them is a valid window.MouseEvent.
var newcircle= new google.maps.Circle({map:map, position:map.getCenter(), radius:1000});
google.maps.event.addListener(newcircle,'click',function(mouseEvent) {
var event = Object.values(mouseEvent)
.filter(function (property) {
return property instanceof window.MouseEvent;
});
if (event.length) {
event = event[0];
} else {
event = {};
}
var shiftKey = event.shiftKey || false;
});
Funny enough, when I tried to use a marker for this example, there wasn't an instance of window.MouseEvent in the google.maps.mouseEvent.
I ended up with a solution close to amenadiel's answer. I thought it would be better not to relay on all the possible uglified variable names, but to look for the one being a MouseEvent and use that one to check for the shiftKey property, like this:
function polygonListener(polygonEvent) {
var shiftKey = false;
for(var i in polygonEvent){
if(polygonEvent[i] instanceof window.MouseEvent){
shiftKey = polygonEvent[i].shiftKey;
break;
}
}
// Rest of the code
}
In case anyone is still looking how to get the MouseEvent from a google maps event, this is the method I've been using.
const mouseEvent = Object.values(event).find(p => p instanceof window.MouseEvent);
// then do whatever with the MouseEvent
const shiftKey = mouseEvent.shiftKey;
In the code below, instead of using on keydown, is there a way I can use on e.which === 13 where the keydown is? This was it wont have to check each time a key is pressed, and will work only when enter is pressed.
Current Code
$('.search').on('keydown', function(e) {
if(e.which === 13) {
// enter key pressed
var value = this.value; // this is the inputs value
console.log(value);
}
});
What I hope to do (pseudo code)
$('.search').(when key === 13 is pressed) { // Only if the enter key pressed
// enter key pressed
var value = this.value; // this is the inputs value
console.log(value);
}
});
Can something like this be done?
You could use a higher-order function to extract that logic for you:
function onlyOnEnter(fn) {
return function(e) {
if(e.which === 13) {
fn.apply(this, arguments);
}
}
}
Usage:
$('.search').on('keydown', onlyOnEnter(function(e) {
var value = this.value; // this is the inputs value
console.log(value);
})
);
That way, your callback function will only be called when the key pressed is an enter.
Not really.
The best you can do is capturing events (you are using on but it could be any other event capturing method). There are many different kind of events (mouse events, keyboard events, control specific events, etc.), you have to look at the event, since each event type will have different properties.
For key pressing, there are some events available for capturing such as keypress, keydown and keyup. You can't expect that one specific key will have an event on its own because you want so save one line of code.
No, this isn't really possible (at least not for the purposes of your code) nor does it make a lot of sense. The keydown event is fired whenever a key is pressed.
Whether you are manually checking to see if it's the enter key or whether the browser or jQuery is doing it internally isn't tremendously relevant - regardless the browser will need to check which key was pressed any time any key is pressed to test whether it was the enter key.
Essentially you're wasting your time. There isn't going to be any measurable performance optimization by trying to do this. No matter how you try to detect the enter key being pressed, it will be tested for every keydown or keypress event regardless of which key is pressed.
I want to know if ctrl,space,alt,capslock,shift like keys are pressed in my keyboard.
When i do
String.fromCharCode(e.keyCode)
,it returns blank value for these keys but when I do
alert($.trim(String.fromCharCode(e.keyCode))=='')
Then it return false for all keys except space bar.So it would be great if someone may tell me to get the keydown event of these keys
Vanilla JavaScript:
For other constants, see https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent
window.onkeydown = function (e) {
switch (e.keyCode) {
case KeyboardEvent.DOM_VK_SPACE:
alert('space bar!');
break;
case KeyboardEvent.DOM_VK_CAPS_LOCK:
alert('CAPS LOCK!');
break;
case KeyboardEvent.DOM_VK_CONTROL:
alert('control!');
break;
case KeyboardEvent.DOM_VK_SHIFT:
alert('shift!');
break;
case KeyboardEvent.DOM_VK_ALT:
alert('alt!');
break;
}
};
UPDATED FOR REQUIREMENT TO AVOID CASES:
Per the following test, the only numeric values that will, after trimming (and not including numbers not corresponding to the average keyboard), be reduced to an empty string are 9,10,11,12,13,32. Looking at https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent#Virtual_key_codes , the only ones that correspond are tab, clear, return, and space .
// Run in Firefox where trim() is supported (without need for jQuery):
var arr = [];
for (var i=0; i < 0xFFFF; i++) {
if (String.fromCharCode(i).trim() == '') {
arr.push(i);
}
}
In other words, your own test is not going to catch all cases.
So you have to use numeric comparisons based on the info at https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent#Virtual_key_codes and BASED ON EXACTLY WHAT CHARACTERS YOU NEED TO INCLUDE (or exclude).
For example, if you consider the cancel key, help key, back space, tab, etc. all to be of the type you mentioned, you can do:
window.onkeydown = function (e) {
if (e.keyCode < 0x30) {
alert('Special key pressed!');
}
};
As you can see, this allows for us to find a whole group of characters within a short amount of code (e.g., without using case). (But if we don't know exactly which characters you want to include or exclude, we can't give you a more precise answer.)
NOTE:
charCode is never set in the keydown and keyup events. In these cases, keyCode is set instead.
you can try
$(window).keydown(function (e){
if (e.ctrlKey) { there are e.altKey & e.shiftKey also.
for other keys use hardcoded integer values.
alert("control");
}
});
I'm not sure about the support of keyIdentifier but if you are using the keyup, keydown or keypress events, but you could possibly do the following. However there are no cross-browser guarantees where charcode is not defined or is zero. Not using jquery to keep things as small as possible, and only detecting the keys that you specified. See article.
Javascript
/*jslint maxerr: 50, indent: 4, browser: true */
(function () {
"use strict";
function addEvent(elem, event, fn) {
if (typeof elem === "string") {
elem = document.getElementById(elem);
}
function listenHandler(e) {
var ret = fn.apply(null, arguments);
if (ret === false) {
e.stopPropagation();
e.preventDefault();
}
return ret;
}
function attachHandler() {
window.event.target = window.event.srcElement;
var ret = fn.call(elem, window.event);
if (ret === false) {
window.event.returnValue = false;
window.event.cancelBubble = true;
}
return ret;
}
if (elem.addEventListener) {
elem.addEventListener(event, listenHandler, false);
} else {
elem.attachEvent("on" + event, attachHandler);
}
}
function checkKeys(e) {
if ("Alt,Shift,Control,CapsLock,U+0020".indexOf(e.keyIdentifier) !== -1) {
alert(e.keyIdentifier);
}
console.log(e.keyIdentifier);
}
addEvent(window, "keydown", checkKeys);
}());
On jsfiddle
Update: reading a bit furter, keyIdentifier is not supported by all browsers and so is not fullly cross-browser friendly.
3.4. New Standard Key and Character Events
The DOM3 standard abandons all hope of creating order among
event.keyCode, event.which and event.charCode, and instead defines new
values for keydown and keyup events. For a while it deprecated the
keypress event and replaced it with the textInput event, but that was
undone. Only a few browsers implemented the first version, and, so
far, no browsers have implemented the newest version. Earlier versions
of the specification defined attributes named event.keyIdentifier and
event.keyLocation. The keyIdentifier was a string that in most cases
looked like "U+0041" where the "0041" part is the unicode value of the
character sent by the key when it is typed without modifiers, in this
case the letter "A". For keys that didn't send unicode characters, or
where the unicode value is not standardized, it was a string like
"Enter", "Shift", "Left" or "F9". The keyLocation attribute gave
values to distinguish among multiple keys that had the same
identifier, like the left and right shift keys, or the keypad number
keys. It was 0 for standard keys, 1 or 2 for left or right versions of
a keys like Shift which appear twice on the keyboard, and 3 for keys
on the numeric keypad.
WebKit implemented support for keyIdentifier and got it mostly right.
Older versions conformed to an older version of the standard and
returned two extra zeros (eg, "U+000041") but this was corrected in
version 525. Windows versions of Safari and Linux versions of Chrome
return bad keyIdentifier values for all of the non-number symbol keys
(WebKit Bug 19906 reported in July 2008). The keyLocation attribute is
always 0 or 3, so it does not distinguish between left and right
modifier keys.
Konqueror returns keyIdentifier values like "Shift" and "Enter"
correctly, but instead of returning the Unicode values, it returns the
typed character itself, "a" or "A" instead of "U+0041". All
keyLocation values are zero, except for modifiers key, which are
always one, regardless of whether the left or right one was pressed.
We cannot, however expect any more browsers to implement that
standard, since it has now changed. The DOM 3 standard no longer
mentions event.keyIdentifier or event.keyLocation. Instead we have
event.key, event.char, event.location.. So far as I know, no browser
has yet implemented this new version of the DOM 3 standard.
In this standard event.char is defined only when you type a printable
character, or another character with a defined code (like tab or
backspace). It's basically like event.charCode except that it is the
character, not the character code and can be any unicode character not
just an ASCII code. Event.key is the same as event.char for printable
keys. For other keys, even ones like tab or backspace that have
character encodings, it is a string like 'Tab', 'Left' or 'F9'. These
values are supposed to be the same on keypress events as they are on
keyup and keydown events, though keypress would not be fired for those
cases where event.char is null.
Note that neither of these pretends to be a keycode identifying a
particular physical key on the keyboard. If you press the /? key on a
US keyboard while shift is off, but press the shift key before
releasing the /? key, then then on keydown you'll get event.key=='/'
and on keyup you'll get event.key=='?'. The only way your Javascript
program will know that those two events go together is if it happens
to know that those two characters are on the same key. There is an
event.locale value that is supposed to give you some clue on what type
of keyboard is being used, but figuring out what keys go with what on
a particular keyboard is up to you.
Clearly this abandonment of the idea of keycodes is going to cause
problems, but is still probably justified. In many (most?) operating
systems, I don't think the browser can actually tell which key was
pressed. In the browser source code I've seen, the keycodes are
generated from the the character codes, not vice versa, by simply
assuming that the character came from a US keyboard. So the keycode
values never really worked for non-US keyboards.
So while the keycode concept was a handly one, it isn't really
practically extensible in the real world. If you want a keycode in the
DOM 3 universe, you'll have to go on using the legacy event.keyCode
value, which, standards or no standards, isn't going away. The DOM 3
standard seems to recognize this, and reluctantly provides an appendix
with some standards for event.keyCode and the like. It casts a rather
weak vote for what I called "IE keycodes" above.
How to capture key press, e.g., Ctrl+Z, without placing an input element on the page in JavaScript? Seems that in IE, keypress and keyup events can only be bound to input elements (input boxes, textareas, etc)
For non-printable keys such as arrow keys and shortcut keys such as Ctrl-z, Ctrl-x, Ctrl-c that may trigger some action in the browser (for instance, inside editable documents or elements), you may not get a keypress event in all browsers. For this reason you have to use keydown instead, if you're interested in suppressing the browser's default action. If not, keyup will do just as well.
Attaching a keydown event to document works in all the major browsers:
document.onkeydown = function(evt) {
evt = evt || window.event;
if (evt.ctrlKey && evt.keyCode == 90) {
alert("Ctrl-Z");
}
};
For a complete reference, I strongly recommend Jan Wolter's article on JavaScript key handling.
jQuery also has an excellent implementation that's incredibly easy to use. Here's how you could implement this functionality across browsers:
$(document).keypress(function(e){
var checkWebkitandIE=(e.which==26 ? 1 : 0);
var checkMoz=(e.which==122 && e.ctrlKey ? 1 : 0);
if (checkWebkitandIE || checkMoz) $("body").append("<p>ctrl+z detected!</p>");
});
Tested in IE7,Firefox 3.6.3 & Chrome 4.1.249.1064
Another way of doing this is to use the keydown event and track the event.keyCode. However, since jQuery normalizes keyCode and charCode using event.which, their spec recommends using event.which in a variety of situations:
$(document).keydown(function(e){
if (e.keyCode==90 && e.ctrlKey)
$("body").append("<p>ctrl+z detected!</p>");
});
For modern JS, use event.key!
document.addEventListener("keypress", function onPress(event) {
if (event.key === "z" && event.ctrlKey) {
// Do something awesome
}
});
NOTE: The old properties (.keyCode and .which) are Deprecated.
Mozilla Docs
Supported Browsers
Detect key press, including key combinations:
window.addEventListener('keydown', function (e) {
if (e.ctrlKey && e.keyCode == 90) {
// Ctrl + z pressed
}
});
Benefit here is that you are not overwriting any global properties, but instead merely introducing a side effect. Not good, but definitely a whole lot less nefarious than other suggestions on here.
Code & detects ctrl+z
document.onkeyup = function(e) {
if(e.ctrlKey && e.keyCode == 90) {
// ctrl+z pressed
}
}
Attach a listener to the keydown event instead of keypress, since the latter is now deprecated.
window.addEventListener('keydown', keyDownHandler);
The keydown event triggers continuously while the key is pressed. If you wanna have it fire only once, inside the handler use the event.repeat property as so:
keyDownHandler(event) {
if (!event.repeat) {
<code here will only be executed once while the key is pressed>
}
}
Remember to remove the listener when not needed anymore.
window.removeEventListener('keydown', keyDownHandler);