onkeydown and onkeyup

Dear JavaScripters:

I am working on a proof-of-concept for date entry (as noted in
the thread "Fancy Date Entry").

1) Using just onkeydown or just onkeyup, I have the problem that
backspace is echoed despite my returning false from the event
handling. If I just return false from the onkeydown handling and
process in the onkeyup handling including return false, then the
backspace is not echoed.

So I have something that works, but I would like to know why it
is that way.

2) I also need to figure out what cursor control keys I need to deal
with. <left arrow> returns 37 for its value. That is the same as
percent. Obviously, I am missing a bit here that I need to figure
out.

Sincerely,

Gene Wirchenko

On Mar 14, 1:35*am, Gene Wirchenko <ge...@ocis.net> wrote:
> Dear JavaScripters:
>
> * * *I am working on a proof-of-concept for date entry (as noted in
> the thread "Fancy Date Entry").
>
> * 1) Using just onkeydown or just onkeyup, I have the problem that
> backspace is echoed despite my returning false from the event
> handling.

Returning false from a keyup listener isn't going to do anything. As
for backspace on keydown, perhaps the browser developers didn't want
to allow that operation to be blocked. You don't need to prevent
backspaces to write a date picker. If your design calls for that, you
should change it.

On 03/14/2012 01:35 AM, Gene Wirchenko wrote:
> Dear JavaScripters:
>
> I am working on a proof-of-concept for date entry (as noted in
> the thread "Fancy Date Entry").
>
> 1) Using just onkeydown or just onkeyup, I have the problem that
> backspace is echoed despite my returning false from the event
> handling. If I just return false from the onkeydown handling and
> process in the onkeyup handling including return false, then the
> backspace is not echoed.
>
> So I have something that works, but I would like to know why it
> is that way.
>
> 2) I also need to figure out what cursor control keys I need to deal
> with.<left arrow> returns 37 for its value. That is the same as
> percent. Obviously, I am missing a bit here that I need to figure
> out.
>
> Sincerely,
>
> Gene Wirchenko

I believe you will find that some keys actually return more than one
code.


--
Norman
Registered Linux user #461062
AMD64X2 6400+ Ubuntu 10.04 64bit

On Mar 14, 5:59*pm, Norman Peelman <npeelman...@cfl.rr.com> wrote:
> On 03/14/2012 01:35 AM, Gene Wirchenko wrote:
>
>
>
>
>
>
>
>
>
> > Dear JavaScripters:
>
> > * * * I am working on a proof-of-concept for date entry (as notedin
> > the thread "Fancy Date Entry").
>
> > * *1) Using just onkeydown or just onkeyup, I have the problem that
> > backspace is echoed despite my returning false from the event
> > handling. *If I just return false from the onkeydown handling and
> > process in the onkeyup handling including return false, then the
> > backspace is not echoed.
>
> > * * * So I have something that works, but I would like to know why it
> > is that way.
>
> > * *2) I also need to figure out what cursor control keys I need to deal
> > with.<left arrow> *returns 37 for its value.

That's the key code.

> That is the same as
> > percent.

No it isn't. You are confusing character codes with key codes.

> Obviously, I am missing a bit here that I need to figure
> > out.

I explained to you the difference between keydown/up and keypress.
The former are for keys, the latter is for characters.

>
> * *I believe you will find that some keys actually return more than one
> code.
>

No.

http://www.cinsoft.net/keyboard.html

On Wed, 14 Mar 2012 15:10:10 -0700 (PDT), David Mark
<dmark.cinsoft@gmail.com> wrote:

>On Mar 14, 5:59*pm, Norman Peelman <npeelman...@cfl.rr.com> wrote:
>> On 03/14/2012 01:35 AM, Gene Wirchenko wrote:

[snip]

>No it isn't. You are confusing character codes with key codes.

Yup. I worked that out myself earlier today.

>> Obviously, I am missing a bit here that I need to figure
>> > out.
>
>I explained to you the difference between keydown/up and keypress.
>The former are for keys, the latter is for characters.

There is a problem, at least in IE 9, where keypress does not
pick up tab. That is why I had to go with keydown/keyup. I ended up
going with up.

[snip]

Sincerely,

Gene Wirchenko

On Mar 14, 8:57*pm, Gene Wirchenko <ge...@ocis.net> wrote:
> On Wed, 14 Mar 2012 15:10:10 -0700 (PDT), David Mark
>
> <dmark.cins...@gmail.com> wrote:
> >On Mar 14, 5:59*pm, Norman Peelman <npeelman...@cfl.rr.com> wrote:
> >> On 03/14/2012 01:35 AM, Gene Wirchenko wrote:
>
> [snip]
>
> >No it isn't. *You are confusing character codes with key codes.
>
> * * *Yup. *I worked that out myself earlier today.
>
> >> Obviously, I am missing a bit here that I need to figure
> >> > out.
>
> >I explained to you the difference between keydown/up and keypress.
> >The former are for keys, the latter is for characters.
>
> * * *There is a problem, at least in IE 9, where keypress does not
> pick up tab. *That is why I had to go with keydown/keyup. *I ended up
> going with up.
>

Again, pressing the tab *key* does not inserts a tab *character*, so
it doesn't make any sense to expect keypress events to fire on tabbing
(though they do in some browsers). This is not a problem (not even in
IE).

On 14/03/2012 02:35, Gene Wirchenko wrote:
> Dear JavaScripters:
>
> I am working on a proof-of-concept for date entry (as noted in
> the thread "Fancy Date Entry").
>
> 1) Using just onkeydown or just onkeyup, I have the problem that
> backspace is echoed despite my returning false from the event
> handling. If I just return false from the onkeydown handling and
> process in the onkeyup handling including return false, then the
> backspace is not echoed.
>

* It seems to be useless to filter tab or enter keys in an input
element using any of the onkey* events. You may succeed in Firefox but
not in IE.
* onkeyup/down events are the only case in which all modern browsers
return the key code.
* onkeydown/onkeypress can be cancelled whereas onkeup cannot (see
MSDN and MDN for documentation)
* To retrieve the charCode, use the onkeypress event in IE/Opera -
other browsers will do (see http://www.quirksmode.org/js/keys.html)

> So I have something that works, but I would like to know why it
> is that way.
>
> 2) I also need to figure out what cursor control keys I need to deal
> with.<left arrow> returns 37 for its value. That is the same as
> percent. Obviously, I am missing a bit here that I need to figure
> out.
>

some key codes: 8 = backspace; 9 = tab; 13 = carriage return (enter
or shift enter); 32 = space; 37 = left arrow; 38 = up
arrow; 39 = right arrow; 40 = down arrow.

--
Joao Rodrigues (J.R.)

On Mar 14, 10:53*pm, "J.R." <groups_j...@yahoo.com.br> wrote:
> On 14/03/2012 02:35, Gene Wirchenko wrote:
>
> > Dear JavaScripters:
>
> > * * * I am working on a proof-of-concept for date entry (as notedin
> > the thread "Fancy Date Entry").
>
> > * *1) Using just onkeydown or just onkeyup, I have the problem that
> > backspace is echoed despite my returning false from the event
> > handling. *If I just return false from the onkeydown handling and
> > process in the onkeyup handling including return false, then the
> > backspace is not echoed.
>
> * ** *It seems to be useless to filter tab or enter keys in an input
> element using any of the onkey* events. You may succeed in Firefox but
> not in IE.

It is, even if all browsers allowed it.

> * ** *onkeyup/down events are the only case in which all modern browsers
> return the key code.

Right, though some will provide it in keypress events in addition to
the character code.

> * ** *onkeydown/onkeypress can be cancelled whereas onkeup cannot (see
> MSDN and MDN for documentation)

Right, because keyup events have no behavior to prevent.

> * ** *To retrieve the charCode, use the onkeypress event in IE/Opera -
> other browsers will do (seehttp://www.quirksmode.org/js/keys.html)

Use the keypress event in all browsers as that is the event that
relates to characters. I'm curious as to what sort of conclusions PPK
drew from his observations, but not enough to look. Does he recommend
using some other event to find the character code?

On Wed, 14 Mar 2012 23:53:22 -0300, "J.R." <groups_jr-1@yahoo.com.br>
wrote:

>On 14/03/2012 02:35, Gene Wirchenko wrote:

>> I am working on a proof-of-concept for date entry (as noted in
>> the thread "Fancy Date Entry").
>>
>> 1) Using just onkeydown or just onkeyup, I have the problem that
>> backspace is echoed despite my returning false from the event
>> handling. If I just return false from the onkeydown handling and
>> process in the onkeyup handling including return false, then the
>> backspace is not echoed.

> * It seems to be useless to filter tab or enter keys in an input
>element using any of the onkey* events. You may succeed in Firefox but
>not in IE.

I can filter <Enter> in IE 9. I want to avoid having a form be
submitted that way.

> * onkeyup/down events are the only case in which all modern browsers
>return the key code.
> * onkeydown/onkeypress can be cancelled whereas onkeup cannot (see
>MSDN and MDN for documentation)

Ah, that different between up and down would explain a bit of
trouble I have been having. Thank you.

> * To retrieve the charCode, use the onkeypress event in IE/Opera -
>other browsers will do (see http://www.quirksmode.org/js/keys.html)
>
>> So I have something that works, but I would like to know why it
>> is that way.
>>
>> 2) I also need to figure out what cursor control keys I need to deal
>> with.<left arrow> returns 37 for its value. That is the same as
>> percent. Obviously, I am missing a bit here that I need to figure
>> out.

>some key codes: 8 = backspace; 9 = tab; 13 = carriage return (enter
> or shift enter); 32 = space; 37 = left arrow; 38 = up
> arrow; 39 = right arrow; 40 = down arrow.

I have since found a fairly complete list of them:
http://www.cambiaresearch.com/articl...odes-key-codes

Sincerely,

Gene Wirchenko

On Mar 15, 1:13*am, Gene Wirchenko <ge...@ocis.net> wrote:
> On Wed, 14 Mar 2012 23:53:22 -0300, "J.R." <groups_j...@yahoo.com.br>
> wrote:
>
> >On 14/03/2012 02:35, Gene Wirchenko wrote:
> >> * * * I am working on a proof-of-concept for date entry (as noted in
> >> the thread "Fancy Date Entry").
>
> >> * *1) Using just onkeydown or just onkeyup, I have the problem that
> >> backspace is echoed despite my returning false from the event
> >> handling. *If I just return false from the onkeydown handling and
> >> process in the onkeyup handling including return false, then the
> >> backspace is not echoed.
> > * * *It seems to be useless to filter tab or enter keys in an input
> >element using any of the onkey* events. You may succeed in Firefox but
> >not in IE.
>
> * * *I can filter <Enter> in IE 9. *I want to avoid having a formbe
> submitted that way.

No you don't (you just think you do). Leave it alone.

On Wed, 14 Mar 2012 22:40:07 -0700 (PDT), David Mark
<dmark.cinsoft@gmail.com> wrote:

>On Mar 15, 1:13*am, Gene Wirchenko <ge...@ocis.net> wrote:

[snip]

>> * * *I can filter <Enter> in IE 9. *I want to avoid having a form be
>> submitted that way.
>
>No you don't (you just think you do). Leave it alone.

Since my code can pick up the character, I think I can filter it.
Since I do not actually submit at this point, I could be erring there,
but not on the filtering.

Sincerely,

Gene Wirchenko

On Wed, 14 Mar 2012 22:13:55 -0700, Gene Wirchenko wrote:

> I can filter <Enter> in IE 9. I want to avoid having a form be
>submitted that way.
>[...]

Gene, it sounds a lot like you are enforcing non-web data entry on web
browsers. This means that anyone used to using web applications that
behave in the standard way will have problems with your data entry
restrictions.

As a simple example, relating to trapping the enter key, any user who
knows that they can enter just the required fields (correctly) and then
press enter to submit the form will be frustrated when they discover
that they need to either tab (if allowed!) through to the submit button,
or take their hand off the keyboard and locate the mouse before clicking
on the submit button. I get this on some websites, and it is very
annoying. Annoyed users make mistakes, often ones that data validation
tests cannot pick up.

If you want to prevent users submitting incomplete forms, catch the
submit event on the form and validate the data. You can then prevent the
default action for the event[1][2][3] if the data are invalid /
incomplete.

Regarding focus/blur and trapping users in fields, that has long been
seen as a Bad Idea in web data entry. There are many things that can
cause a field to lose focus, including (off the top of my head):

* the user tabbing away
* the user using the mouse to click in another field
* the user clicking on a non-field part of the page
* the user tapping (accidentally?) on a touch pad
* the user switching to another window (some browsers/OS)
* a bloody annoying "look at me" script/applet/widget stealing focus

Some of those events can put your script into a loop if you're not
careful, where the only escape is closing the browser, and thus losing
the data entered. That can really annoy users. They are then even more
likely to make mistakes.

Realise that the user may have a very legitimate reason for leaving a
field, e.g. to go copy data from elsewhere to paste into that field.
It's bad form to stop them doing that.

As an alternative, look at some other ways that data validation errors
are handled on the web. I like the style of this one (am not suggesting
you give up and use jQuery, just examine the style):

http://jquery.bassistance.de/validate/demo/

Here, the user is given feedback but is not hamstrung by "you can't tab"
or "you can't press enter to submit".

Please realise that none of us here are telling you "you can't do that",
because obviously you can and, to a degree, have. But experience has
shown that there are better ways, and we want you to consider them
before your web-savvy users revolt and come after you with sharp objects


[1] https://developer.mozilla.org/en/DOM...preventDefault
[2] http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx
[3] http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx
--
Ross McKay, Toronto, NSW Australia
"Let the laddie play wi the knife - he'll learn"
- The Wee Book of Calvin

On Fri, 16 Mar 2012 12:59:29 +1100, Ross McKay
<au.org.zeta.at.rosko@invalid.invalid> wrote:

>On Wed, 14 Mar 2012 22:13:55 -0700, Gene Wirchenko wrote:
>
>> I can filter <Enter> in IE 9. I want to avoid having a form be
>>submitted that way.
>>[...]
>
>Gene, it sounds a lot like you are enforcing non-web data entry on web
>browsers. This means that anyone used to using web applications that
>behave in the standard way will have problems with your data entry
>restrictions.

And it means that people used to a non-Web interface get to
continue being comfortable.

>As a simple example, relating to trapping the enter key, any user who
>knows that they can enter just the required fields (correctly) and then
>press enter to submit the form will be frustrated when they discover
>that they need to either tab (if allowed!) through to the submit button,
>or take their hand off the keyboard and locate the mouse before clicking
>on the submit button. I get this on some websites, and it is very
>annoying. Annoyed users make mistakes, often ones that data validation
>tests cannot pick up.

The current system has the equivalent of this and works quite
nicely. Why change and confuse them?

If you suggest that the non-Web users will not be confused by the
change, I will suggest the Web denizens would not be either. If you
then argue that non-Web users are more mentally flexible than Web
users, I will not argue with you, but I might pass the compliment
along. <BEG>

>If you want to prevent users submitting incomplete forms, catch the
>submit event on the form and validate the data. You can then prevent the
>default action for the event[1][2][3] if the data are invalid /
>incomplete.

I do that, too.

>Regarding focus/blur and trapping users in fields, that has long been
>seen as a Bad Idea in web data entry. There are many things that can
>cause a field to lose focus, including (off the top of my head):
>
>* the user tabbing away

Which is when I want to check the field.

>* the user using the mouse to click in another field

Which is when I want to check the first field.

>* the user clicking on a non-field part of the page

I am fine with validation being done then.

>* the user tapping (accidentally?) on a touch pad

No touchpad is being used. Is this like the previous case?

>* the user switching to another window (some browsers/OS)

I am fine with the validation being done then. The other window
does get the focus.

>* a bloody annoying "look at me" script/applet/widget stealing focus

What script/applet/widget? It is just an alert box.

>Some of those events can put your script into a loop if you're not
>careful, where the only escape is closing the browser, and thus losing
>the data entered. That can really annoy users. They are then even more
>likely to make mistakes.

I am quite careful. I have put a lot of effort into figuring it
out so that it works well. A co-worker tried to break my test page in
IE 9 and could not.

>Realise that the user may have a very legitimate reason for leaving a
>field, e.g. to go copy data from elsewhere to paste into that field.
>It's bad form to stop them doing that.

Realise that I may have a very legitimate reason for wanting
things the way I am working on.

>As an alternative, look at some other ways that data validation errors
>are handled on the web. I like the style of this one (am not suggesting
>you give up and use jQuery, just examine the style):
>
>http://jquery.bassistance.de/validate/demo/
>
>Here, the user is given feedback but is not hamstrung by "you can't tab"
>or "you can't press enter to submit".
>
>Please realise that none of us here are telling you "you can't do that",
>because obviously you can and, to a degree, have. But experience has
>shown that there are better ways, and we want you to consider them
>before your web-savvy users revolt and come after you with sharp objects
>

I do not think that that is an issue. If I really had to dike
out the validation, it would be fairly easy. I should experiment with
that in a bit. Thank you for the suggestion. If it works that
easily, I may have the best of both worlds.

>[1] https://developer.mozilla.org/en/DOM...preventDefault
>[2] http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx
>[3] http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

I will have a look. Thank you for the links.

Sincerely,

Gene Wirchenko

On Thu, 15 Mar 2012 21:58:39 -0700, Gene Wirchenko wrote:

>[...]
> If you suggest that the non-Web users will not be confused by the
>change, I will suggest the Web denizens would not be either. If you
>then argue that non-Web users are more mentally flexible than Web
>users, I will not argue with you, but I might pass the compliment
>along. <BEG>

Fair enough. You obviously work with smarter and more tolerant people
than I ever have

>[...]
>>* the user clicking on a non-field part of the page
>
> I am fine with validation being done then.
>
>>* the user tapping (accidentally?) on a touch pad
>
> No touchpad is being used. Is this like the previous case?

Many notebook computers have touchpads for use in place of a mouse, and
it's amazing what can trigger them to place focus somewhere other than
where you want them to.

>[...]
>>* a bloody annoying "look at me" script/applet/widget stealing focus
>
> What script/applet/widget? It is just an alert box.

I've seen cases where the banner or sidebar on a web application has
suddenly had an annoying widget added to it by "corporate" or the
equivalent, and sometimes they do nasty things like steal focus or mess
up your tabindex. Same thing with public-facing sites, but worse because
"marketing" get in on the act too, and they tend to perpetrate all kinds
of evil on web pages.

>[...]
> I am quite careful. I have put a lot of effort into figuring it
>out so that it works well. A co-worker tried to break my test page in
>IE 9 and could not.

Be prepared to test each application with each new version of your
deployed browser (and maybe get ahead of the game by playing with a beta
of IE10). The situation can change. Taking a less interventionist
approach makes for less pain when the event flow in a new browser
differs from previous versions.

I've no doubt that you can be successful with your approach (as I've
been there and done it in the past), for a limited set of browsers. Just
be aware of those limitations.
--
Ross McKay, Toronto, NSW Australia
"The documentation and sample application having failed me,
I resort to thinking. This desperate tactic works, and I
resolve that problem and go on to the next"
- Michael Swaine, "Programming Paradigms", Dr Dobb's Journal

On Fri, 16 Mar 2012 18:13:58 +1100, Ross McKay
<au.org.zeta.at.rosko@invalid.invalid> wrote:

[snip]

>I've no doubt that you can be successful with your approach (as I've
>been there and done it in the past), for a limited set of browsers. Just
>be aware of those limitations.

It seems one has to worry about that with browsers regardless of
what one does if one goes past the basics.

The standard browser for the app-which-will-exist is IE 9. That
is why I am not too worried about the problem with Firefox. I will
deal with it later. (And if I can not, well, it only affects my
to-you-overdone validation.) It might be something simple: I am
hoping it is that.

Sincerely,

Gene Wrichenko