Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #12689 > unrolled thread

onkeydown and onkeyup

Back to article view | Back to comp.lang.javascript

Contents

  onkeydown and onkeyup Gene Wirchenko <genew@ocis.net> - 2012-03-13 22:35 -0700
    Re: onkeydown and onkeyup David Mark <dmark.cinsoft@gmail.com> - 2012-03-13 22:40 -0700
    Re: onkeydown and onkeyup Norman Peelman <npeelmandog@cfl.rr.com> - 2012-03-14 17:59 -0400
      Re: onkeydown and onkeyup David Mark <dmark.cinsoft@gmail.com> - 2012-03-14 15:10 -0700
        Re: onkeydown and onkeyup Gene Wirchenko <genew@ocis.net> - 2012-03-14 17:57 -0700
          Re: onkeydown and onkeyup David Mark <dmark.cinsoft@gmail.com> - 2012-03-14 19:39 -0700
    Re: onkeydown and onkeyup "J.R." <groups_jr-1@yahoo.com.br> - 2012-03-14 23:53 -0300
      Re: onkeydown and onkeyup David Mark <dmark.cinsoft@gmail.com> - 2012-03-14 20:26 -0700
      Re: onkeydown and onkeyup Gene Wirchenko <genew@ocis.net> - 2012-03-14 22:13 -0700
        Re: onkeydown and onkeyup David Mark <dmark.cinsoft@gmail.com> - 2012-03-14 22:40 -0700
          Re: onkeydown and onkeyup Gene Wirchenko <genew@ocis.net> - 2012-03-15 08:25 -0700
            Re: onkeydown and onkeyup "J.R." <groups_jr-1@yahoo.com.br> - 2012-03-18 13:07 -0300
              Re: onkeydown and onkeyup David Mark <dmark.cinsoft@gmail.com> - 2012-03-19 00:05 -0700
            Re: onkeydown and onkeyup "Mel Smith" <med_cutout_syntel@aol.com> - 2012-03-19 09:54 -0700
              Re: onkeydown and onkeyup Gene Wirchenko <genew@ocis.net> - 2012-03-19 12:37 -0700
                Re: onkeydown and onkeyup "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-03-19 20:53 +0000
                  Re: onkeydown and onkeyup Gene Wirchenko <genew@ocis.net> - 2012-03-19 16:20 -0700
                    Re: onkeydown and onkeyup Jeff North <jnorthau@yahoo.com.au> - 2012-03-20 12:12 +1100
                      Re: onkeydown and onkeyup Gene Wirchenko <genew@ocis.net> - 2012-03-19 18:45 -0700
                        Re: onkeydown and onkeyup Jeff North <jnorthau@yahoo.com.au> - 2012-03-20 17:17 +1100
                          Re: onkeydown and onkeyup David Mark <dmark.cinsoft@gmail.com> - 2012-03-20 16:37 -0700
                            Re: onkeydown and onkeyup Gene Wirchenko <genew@ocis.net> - 2012-03-20 19:25 -0700
                      Re: onkeydown and onkeyup Dr J R Stockton <reply1212@merlyn.demon.co.uk.not.invalid> - 2012-03-21 19:27 +0000
                        Re: onkeydown and onkeyup Gene Wirchenko <genew@ocis.net> - 2012-03-21 19:19 -0700
                    Re: onkeydown and onkeyup "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-03-22 16:06 +0000
                      Re: onkeydown and onkeyup Gene Wirchenko <genew@ocis.net> - 2012-03-22 09:59 -0700
                        Re: onkeydown and onkeyup "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-03-22 18:10 +0000
                          Re: onkeydown and onkeyup Tim Streater <timstreater@greenbee.net> - 2012-03-22 19:19 +0000
                            Re: onkeydown and onkeyup Mike Duffy <Use_guestbook_page@website.in.sig> - 2012-03-23 01:44 +0000
                          Re: onkeydown and onkeyup Gene Wirchenko <genew@ocis.net> - 2012-03-22 12:36 -0700
                            Re: onkeydown and onkeyup "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-03-23 09:05 +0000
                Re: onkeydown and onkeyup "Mel Smith" <med_cutout_syntel@aol.com> - 2012-03-19 15:49 -0700
        Re: onkeydown and onkeyup Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2012-03-16 12:59 +1100
          Re: onkeydown and onkeyup Gene Wirchenko <genew@ocis.net> - 2012-03-15 21:58 -0700
            Re: onkeydown and onkeyup Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2012-03-16 18:13 +1100
              Re: onkeydown and onkeyup Gene Wirchenko <genew@ocis.net> - 2012-03-16 08:11 -0700
                Re: onkeydown and onkeyup John G Harris <john@nospam.demon.co.uk> - 2012-03-16 16:58 +0000
                  Re: onkeydown and onkeyup Gene Wirchenko <genew@ocis.net> - 2012-03-16 12:05 -0700
          Re: onkeydown and onkeyup Dr J R Stockton <reply1211@merlyn.demon.co.uk.not.invalid> - 2012-03-17 19:13 +0000
            Re: onkeydown and onkeyup Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2012-03-18 12:46 +1100
              Re: onkeydown and onkeyup David Mark <dmark.cinsoft@gmail.com> - 2012-03-17 19:13 -0700
              Re: onkeydown and onkeyup Gene Wirchenko <genew@ocis.net> - 2012-03-17 23:27 -0700

Page 1 of 3  [1] 2 3  Next page →

#12689 — 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

[toc] | [next] | [standalone]

#12691

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.

[toc] | [prev] | [next] | [standalone]

#12732

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

[toc] | [prev] | [next] | [standalone]

#12733

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 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'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

[toc] | [prev] | [next] | [standalone]

#12738

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

[toc] | [prev] | [next] | [standalone]

#12739

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).

[toc] | [prev] | [next] | [standalone]

#12740

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.)

[toc] | [prev] | [next] | [standalone]

#12741

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 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.

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?

[toc] | [prev] | [next] | [standalone]

#12743

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/articles/15/javascript-char-codes-key-codes

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12746

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 form be
> submitted that way.

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

[toc] | [prev] | [next] | [standalone]

#12760

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

[toc] | [prev] | [next] | [standalone]

#12883

On 15/03/2012 12:25, Gene Wirchenko wrote:
> 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.

According to MSDN 
<http://msdn.microsoft.com/en-us/library/ms536939.aspx>, as of MSIE 4 
the onkeypress event fires and can be canceled for the following keys:
  * Letters: A - Z (uppercase and lowercase)
  * Numerals: 0 - 9
  * Symbols: ! @ # $ % ^ & * ( ) _ - + = < [ ] { } , . / ? \ | ' ` " ~
  * System: ESC, SPACEBAR, *ENTER*

So as of MSIE 4+ the onkeypress event doesn't fire for the TAB and 
BACKSPACE keys, unlike Firefox for instance. That's why I prefer 
filtering the whole input value attribute instead of checking each key 
being pressed by the user.

-- 
Joao Rodrigues (J.R.)

[toc] | [prev] | [next] | [standalone]

#12895

On Mar 18, 12:07 pm, "J.R." <groups_j...@yahoo.com.br> wrote:
> On 15/03/2012 12:25, Gene Wirchenko wrote:
>
> > On Wed, 14 Mar 2012 22:40:07 -0700 (PDT), David Mark
> > <dmark.cins...@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.
>
> According to MSDN
> <http://msdn.microsoft.com/en-us/library/ms536939.aspx>, as of MSIE 4
> the onkeypress event fires and can be canceled for the following keys:
>   * Letters: A - Z (uppercase and lowercase)
>   * Numerals: 0 - 9
>   * Symbols: ! @ # $ % ^ & * ( ) _ - + = < [ ] { } , . / ? \ | ' ` " ~
>   * System: ESC, SPACEBAR, *ENTER*

That doesn't sound entirely accurate to me, but I'll have to check my
keyboard code to be sure.  I would expect a keypress event to be fired
for the enter key in a TEXTAREA only.  I would not expect that of the
escape key at all (though some browsers do fire the event for that key
while making it clear that it should be ignored).

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

>
> So as of MSIE 4+ the onkeypress event doesn't fire for the TAB and
> BACKSPACE keys, unlike Firefox for instance.

Some browsers fire keypress for the tab key (which should be ignored),
but they do not indicate that a tab character has been added to the
input (as makes sense).  Backspace should always fire keypress, but
IIRC, it does not in legacy IE browsers.

> That's why I prefer
> filtering the whole input value attribute instead of checking each key
> being pressed by the user.

Yes, trying to piece together the value from a stream of keypress
events would be impossible.

[toc] | [prev] | [next] | [standalone]

#12902

Hi Gene & Mark:

    I've been following your interplay, and hope you don't mind my playing 
Mr. 'Buttinsky' here

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

    and David Mark replied:

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

Hi Gene:

    I have over 50 input fields on my Editing page (most <input type="text"> 
but also <textarea> and a few checkbox elements), and use the following 
statement to capture keystrokes (including the <Enter> key) as follows:

     ... in a big loop of all the <input type="text"> I have

    e.onkeydown = focusOnElement  ; // where e. is the input text object, 
and I examine the input

    // the focusOnElement function is my own and is inserted below:

-Mel Smith

*******************
// note that I use the <enter> key to move thru the input fields as they 
occur,
// but I also use the up/down arrow keys to allow my user to move up and 
down thru
// four rows of very structured columns in a table.
// btw, my main user *wants* it this way.

function focusOnElement(e) {
   if (e == null ) e = window.event ;
   var nkey = e.keyCode ;
   var thistab = this.tabIndex;
   var thisid = inpobjs[thistab] ;  // we may need the current id
   var nexttab = (thistab+1 < maxtab) ? thistab+1 : 0 ; // if last goto top
   var prevtab = (thistab-1 < 0) ? maxtab : thistab-1 ; // if already to, 
goto bottom
   var nextid = inpobjs[nexttab] ; // get the id of the next input text 
field
   var previd = inpobjs[prevtab] ; // get the id of the previous input text 
field

   if (nkey === 13) { // enter key
     document.getElementById(nextid).focus() ;
     return true ;
   }

   if (nkey === 40) { // down arrow key
     if (thistab <= 23) {  // then we are in one of the vertical table 
fields
      nexttab += 7     // this should move us down the table vertically
      nextid = inpobjs[nexttab] ; // get the correct id of the input text 
field
     }
     if (thistab >= 24 && thistab <= 31) {
      document.getElementById("ioccupant-1").focus()
      return true ;
      }
     document.getElementById(nextid).focus() ;
     return true ;
   }

   else if(nkey===38) { // up-arrow key
     if (thistab >= 0 && thistab <= 7) {     // don't go anywhere -- stay 
here
      previd = thisid ;
      }

     if (thistab >= 8 && thistab <= 31) {  // then we are in one of the 
vertical table fields
      prevtab -= 7     // this should move us up the table vertically
      previd = inpobjs[prevtab] ; // get the correct id of the input text 
field
     }
     document.getElementById(previd).focus() ;
     return true ;
   }

   else if(nkey===36) { // Home key -- go left or up (i.e., previous field
     document.getElementById(previd).focus() ;
     return true ;
   }

   else if(nkey===33) { // page-up key
     previd = inpobjs[0] ;
     document.getElementById(previd).focus() ;
     return true ;
   }
   else if(nkey===34) { // page-down key
      nextid = inpobjs[maxtab-1] ;
      document.getElementById(nextid).focus() ;
      return true ;
   }
   return true;
}

[toc] | [prev] | [next] | [standalone]

#12905

On Mon, 19 Mar 2012 09:54:52 -0700, "Mel Smith"
<med_cutout_syntel@aol.com> wrote:

>Hi Gene & Mark:
>
>    I've been following your interplay, and hope you don't mind my playing 
>Mr. 'Buttinsky' here

     Why not instead call it being a valued contributor to the thread?

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

>    and David Mark replied:
>
>>>No you don't (you just think you do). Leave it alone.

     Mr. Mark might consider the possibility that I know my situation
better than he does.  I can make my own decisions thank you.

     The particular use case addressed by my <Enter> filtering is
people accustomed to pressing <Enter> to terminate an input.  I do not
want that to result in a form submit.

>    I have over 50 input fields on my Editing page (most <input type="text"> 
>but also <textarea> and a few checkbox elements), and use the following 
>statement to capture keystrokes (including the <Enter> key) as follows:

[snipped code]

     Your code appears to be just control focus management.  (I could
be missing something.)  I have saved it in case I need to revisit the
area, but I need more than that.  Some of my keyboard event handling
is for control values.  (I have some neat code for date entry.  Well,
I think it is neat.)

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12907

Gene Wirchenko wrote on 19 mrt 2012 in comp.lang.javascript:

>      Mr. Mark might consider the possibility that I know my situation
> better than he does.  I can make my own decisions thank you.
> 
>      The particular use case addressed by my <Enter> filtering is
> people accustomed to pressing <Enter> to terminate an input.  I do not
> want that to result in a form submit.

Gene, perhaps you would be right in an email conversation,
but here we post to the whole group.

In this group, your personal "needs" are not as important as the 
ways this discussion influences the thoughts of oldbee and newbee
programmers that follow the thread, or will follow it in years to come, 
Google willing. And even you yourself should, in my eyes, be influensed 
by the logic of compliance to general habits.

In this group, advice to comply with web-user behavour is a 
responsability of the regulars.

The people you programme for, your users, surely are not a constant non-
refreshing group, living totally outside the normal use of the browsers 
normally used on the web. So their behavour will be influenced by web-
useage and it's evolution.

In my eyse, there only two distinct groups you should programme for:

Group 1: You yourself as a single user, having manipulation pages that, 
for instance, heavily affect the integrety of a database to correct for 
errors that have not been forseen and should not reoccur. I sometimes use 
rightclick actions to view the unviewable in a 4th generation database-
view, hover-titles for reading record-numbers,  

Group 2: The total of other users, present users and furure users.

Only group 1 should, at your peril, be allowed to bypass the common 
habits of web-browser use.

Even then, If I access my "group 1" page, say after a year, I have to 
reread the code to understand what I ment to be the effect in when I 
wrote the code.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#12910

On 19 Mar 2012 20:53:19 GMT, "Evertjan."
<exjxw.hannivoort@interxnl.net> wrote:

Evertjan:

     Thank you very much for giving me yet another opportunity to
write about why one might do things a different way.  If you did not
keep trying to stomp me down to doing it your way, I would not keep
posting my view.

     I believe that it is important to consider more than one way of
doing things.  Questioning comfortable things can be the start to
getting something better, or it can provide reasoned argument for why
the extant way is good.

>Gene Wirchenko wrote on 19 mrt 2012 in comp.lang.javascript:
>
>>      Mr. Mark might consider the possibility that I know my situation
>> better than he does.  I can make my own decisions thank you.
>> 
>>      The particular use case addressed by my <Enter> filtering is
>> people accustomed to pressing <Enter> to terminate an input.  I do not
>> want that to result in a form submit.
>
>Gene, perhaps you would be right in an email conversation,
>but here we post to the whole group.

     Which I am doing.  Do I need to explain how it is possible to
write for two audiences at once?

>In this group, your personal "needs" are not as important as the 
>ways this discussion influences the thoughts of oldbee and newbee
>programmers that follow the thread, or will follow it in years to come, 
>Google willing. And even you yourself should, in my eyes, be influensed 
>by the logic of compliance to general habits.

     Your personal need to stomp on someone doing things differently
is not terribly important.  If general usage does not fit my use
cases, I feel free to disregard it.  I think that others should do the
same.  I will use something if it lokos to be a good idea.  I am not
likely to do so simply because it the so-called thing to do.

>In this group, advice to comply with web-user behavour is a 
>responsability of the regulars.

     As is to ensure that what one does fits the needs and wants of
the people who will be using, regardless of whether those needs and
wants are in agreement with common practice.

     Such changes might even improve the situation for others.

>The people you programme for, your users, surely are not a constant non-
>refreshing group, living totally outside the normal use of the browsers 
>normally used on the web. So their behavour will be influenced by web-
>useage and it's evolution.

     And also by any other programs they use.  I figure that they are
bright enough to learn, and I have not been disappointed.

>In my eyse, there only two distinct groups you should programme for:
>
>Group 1: You yourself as a single user, having manipulation pages that, 
>for instance, heavily affect the integrety of a database to correct for 
>errors that have not been forseen and should not reoccur. I sometimes use 
>rightclick actions to view the unviewable in a 4th generation database-
>view, hover-titles for reading record-numbers,  
>
>Group 2: The total of other users, present users and furure users.
>
>Only group 1 should, at your peril, be allowed to bypass the common 
>habits of web-browser use.

     Things can change for group 2 as well.  Pad systems are an
example of this.

>Even then, If I access my "group 1" page, say after a year, I have to 
>reread the code to understand what I ment to be the effect in when I 
>wrote the code.

     Possibly, that is, as has been the case for me more than once,
you have not had to look at the code for quite some time, because it
has just worked and there has been no need to change it during that
time.  That suggests that the original design worked quite well.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12915

On Mon, 19 Mar 2012 16:20:42 -0700, in comp.lang.javascript Gene
Wirchenko <genew@ocis.net>
<l3ffm75n19ptorsof3jjr257t1vomb09ut@4ax.com> wrote:

>| On 19 Mar 2012 20:53:19 GMT, "Evertjan."
>| <exjxw.hannivoort@interxnl.net> wrote:
 
[snip]

>| >Only group 1 should, at your peril, be allowed to bypass the common 
>| >habits of web-browser use.
>| 
>|      Things can change for group 2 as well.  Pad systems are an
>| example of this.
>| 
>| >Even then, If I access my "group 1" page, say after a year, I have to 
>| >reread the code to understand what I ment to be the effect in when I 
>| >wrote the code.
>| 
>|      Possibly, that is, as has been the case for me more than once,
>| you have not had to look at the code for quite some time, because it
>| has just worked and there has been no need to change it during that
>| time.  That suggests that the original design worked quite well.

I think that you are missing the point.

Say, for example, there is a security threat identified within
javascript. The IT department disables javascript in the browsers.

Now when the users visit your page(s) they will be forced to use the
browsers default behaviour - not your well-crafted scripting.

This will cause more confusion with the users because it doesn't work.

Remember, javascript is there to enhance the user experience. If
javascript is disabled then the user shouldn't see too much of a
difference with the web page(s).

[toc] | [prev] | [next] | [standalone]

#12917

On Tue, 20 Mar 2012 12:12:10 +1100, Jeff North <jnorthau@yahoo.com.au>
wrote:

>On Mon, 19 Mar 2012 16:20:42 -0700, in comp.lang.javascript Gene
>Wirchenko <genew@ocis.net>
><l3ffm75n19ptorsof3jjr257t1vomb09ut@4ax.com> wrote:
>
>>| On 19 Mar 2012 20:53:19 GMT, "Evertjan."
>>| <exjxw.hannivoort@interxnl.net> wrote:
> 
>[snip]
>
>>| >Only group 1 should, at your peril, be allowed to bypass the common 
>>| >habits of web-browser use.
>>| 
>>|      Things can change for group 2 as well.  Pad systems are an
>>| example of this.
>>| 
>>| >Even then, If I access my "group 1" page, say after a year, I have to 
>>| >reread the code to understand what I ment to be the effect in when I 
>>| >wrote the code.
>>| 
>>|      Possibly, that is, as has been the case for me more than once,
>>| you have not had to look at the code for quite some time, because it
>>| has just worked and there has been no need to change it during that
>>| time.  That suggests that the original design worked quite well.
>
>I think that you are missing the point.

     No.

>Say, for example, there is a security threat identified within
>javascript. The IT department disables javascript in the browsers.
                 ^^^^^^^^^^^^^
     L'état, c'est moi.  Part of it anyway.

>Now when the users visit your page(s) they will be forced to use the
>browsers default behaviour - not your well-crafted scripting.

     Not going to happen.

>This will cause more confusion with the users because it doesn't work.
>
>Remember, javascript is there to enhance the user experience. If
>javascript is disabled then the user shouldn't see too much of a
>difference with the web page(s).

     Unless the scripting is required.  We need frontend editing, so
we need JavaScript (or some other scripting language).  The app will
be hitting a backend database as well.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12924

On Mon, 19 Mar 2012 18:45:51 -0700, in comp.lang.javascript Gene
Wirchenko <genew@ocis.net>
<42ofm75m7ebka6m94r2f455q1msr8e3op2@4ax.com> wrote:

>| On Tue, 20 Mar 2012 12:12:10 +1100, Jeff North <jnorthau@yahoo.com.au>
>| wrote:
>| 
>| >On Mon, 19 Mar 2012 16:20:42 -0700, in comp.lang.javascript Gene
>| >Wirchenko <genew@ocis.net>
>| ><l3ffm75n19ptorsof3jjr257t1vomb09ut@4ax.com> wrote:
>| >
>| >>| On 19 Mar 2012 20:53:19 GMT, "Evertjan."
>| >>| <exjxw.hannivoort@interxnl.net> wrote:
>| > 
>| >[snip]
>| >
>| >>| >Only group 1 should, at your peril, be allowed to bypass the common 
>| >>| >habits of web-browser use.
>| >>| 
>| >>|      Things can change for group 2 as well.  Pad systems are an
>| >>| example of this.
>| >>| 
>| >>| >Even then, If I access my "group 1" page, say after a year, I have to 
>| >>| >reread the code to understand what I ment to be the effect in when I 
>| >>| >wrote the code.
>| >>| 
>| >>|      Possibly, that is, as has been the case for me more than once,
>| >>| you have not had to look at the code for quite some time, because it
>| >>| has just worked and there has been no need to change it during that
>| >>| time.  That suggests that the original design worked quite well.
>| >
>| >I think that you are missing the point.
>| 
>|      No.
>| 
>| >Say, for example, there is a security threat identified within
>| >javascript. The IT department disables javascript in the browsers.
>|                  ^^^^^^^^^^^^^
>|      L'état, c'est moi.  Part of it anyway.
>| 
>| >Now when the users visit your page(s) they will be forced to use the
>| >browsers default behaviour - not your well-crafted scripting.
>| 
>|      Not going to happen.

Hmmm famous last words...

>| >This will cause more confusion with the users because it doesn't work.
>| >
>| >Remember, javascript is there to enhance the user experience. If
>| >javascript is disabled then the user shouldn't see too much of a
>| >difference with the web page(s).
>| 
>|      Unless the scripting is required.  

Any sort of script is never mandatory! Unless you are a control freak
in which case the browser will cause you limitless nightmares.

>| We need frontend editing, so
>| we need JavaScript (or some other scripting language).  The app will
>| be hitting a backend database as well.

Wow, I'm impressed - not.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web