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


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

Teh onkey*= Clause, Take 2

Started byGene Wirchenko <genew@ocis.net>
First post2012-02-28 14:01 -0800
Last post2012-03-12 18:59 -0700
Articles 8 — 3 participants

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


Contents

  Teh onkey*= Clause, Take 2 Gene Wirchenko <genew@ocis.net> - 2012-02-28 14:01 -0800
    Re: Teh onkey*= Clause, Take 2 Gene Wirchenko <genew@ocis.net> - 2012-03-01 13:25 -0800
      Re: Teh onkey*= Clause, Take 2 David Mark <dmark.cinsoft@gmail.com> - 2012-03-02 20:02 -0800
    Re: Teh onkey*= Clause, Take 2 David Mark <dmark.cinsoft@gmail.com> - 2012-03-02 20:00 -0800
      Re: Teh onkey*= Clause, Take 2 Mike Duffy <Use_guestbook_page@website.in.sig> - 2012-03-03 05:18 +0000
        Re: Teh onkey*= Clause, Take 2 David Mark <dmark.cinsoft@gmail.com> - 2012-03-12 18:56 -0700
      Re: Teh onkey*= Clause, Take 2 Gene Wirchenko <genew@ocis.net> - 2012-03-04 21:00 -0800
        Re: Teh onkey*= Clause, Take 2 David Mark <dmark.cinsoft@gmail.com> - 2012-03-12 18:59 -0700

#12256 — Teh onkey*= Clause, Take 2

FromGene Wirchenko <genew@ocis.net>
Date2012-02-28 14:01 -0800
SubjectTeh onkey*= Clause, Take 2
Message-ID<u5hqk7d961j23a2cl5gfbi8clm8ml4qpqu@4ax.com>
Dear JavaScripters:

     I am still trying to make sense of the onkey* clause.  I have
tried my test page below with both onkeypress and onkeydown.  (It is
safe to change all "press" to "down" and vice versa.


     The behavior for <Enter> is just what I want, but I am having
trouble with <Esc> which Mike Duffy said resets a page.  I am getting
different behaviour.  How do I override the behaviour?

     What I want -- with either onkeypress or onkeydown -- is if the
confirm() dialog box is answered Cancel, then nothing happens, but if
it is answered OK, *ALL* of the controls reset.

     With the onkeypress version, start the form, enter "one", <tab>,
"two", <tab> "three", <Esc>.  Control Three will reset before the
confirm() dialog box is displayed.  Regardless of which of OK or
Cancel is selected, on the next <Esc>, all controls will be reset
before the confirm() dialog box is displayed.  This is not what I
want.

     With the onkeydown version, start the form, enter "one", <tab>,
"two", <tab> "three", <Esc>.  The dialog will appear.  If Cancel is
selected, nothing happens (Good).  If OK is selected, then only
Control Three will be reset.  If <Esc> is entered again immediately
after and OK chosen, then the rest of the controls will reset.  Not
good enough.

     With the onkeydown version, if I replace the <Esc> true branch
with code to reset the value and then select and focus the first
control, that works *except* that the select and focus do not happen.
(Select and focus code in another test form (my big one) does work in
the reset button.  I am trying to cover reset within input controls as
a functionality to add to that big form.)

     If I break out the select and focus code, I can get it to work. I
set a global flag indicating whether to reset the select and focus.
The on clause is then the somewhat awkward:
          onkeydown="var RetVal=DoKeydown(); ResetSelectFocus();
return RetVal;"
You can probably imagine the other code easily enough.  Why this
breakout works, I do not know.  It also makes the control's code a lot
more cluttered.

     The end result of this post is that I do have something that
works, but I have the horrible feeling that I am missing the point.  I
think that implementing <Esc> in a control resetting a page should not
be so difficult.  What am I missing?

***** Start of Test Page *****
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>

<head>
  <meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
  <title>2012-02-28: onkey*</title>
</head>

<body>

<script type="text/javascript">

function DoKeypress(e)
  {
  var theKey=e.which;
  if (theKey==13)     // <Enter>
    {
	alert("Use the button instead to submit the form.");
	return false;
	}
  if (theKey==27)     // <Esc>
    {
    fEscape=confirm("Reset form?");
	if (fEscape)
	  return true;
	else
	  return false;
	}
  return true;
  }

</script>

<form name=theForm>
  One: <input name=One value="Start One" onkeypress="return
DoKeypress(event);">
  <br>
  Two: <input name=Two value="Start Two" onkeypress="return
DoKeypress(event);">
  <br>
  Three: <input name=Three value="Start Three" onkeypress="return
DoKeypress(event);">
</form>

<script type="text/javascript">
theForm.One.select();
theForm.One.focus();
</script>

</body>

</html>
***** End of Test Page *****

Sincerely,

Gene Wirchenko

[toc] | [next] | [standalone]


#12331

FromGene Wirchenko <genew@ocis.net>
Date2012-03-01 13:25 -0800
Message-ID<s2qvk71do2v5b1n30ln6fme2f3fkbcqv8v@4ax.com>
In reply to#12256
On Tue, 28 Feb 2012 14:01:06 -0800, Gene Wirchenko <genew@ocis.net>
wrote:

>     I am still trying to make sense of the onkey* clause.  I have
>tried my test page below with both onkeypress and onkeydown.  (It is
>safe to change all "press" to "down" and vice versa.
>
>
>     The behavior for <Enter> is just what I want, but I am having
>trouble with <Esc> which Mike Duffy said resets a page.  I am getting
>different behaviour.  How do I override the behaviour?
>
>     What I want -- with either onkeypress or onkeydown -- is if the
>confirm() dialog box is answered Cancel, then nothing happens, but if
>it is answered OK, *ALL* of the controls reset.

     I have solved this.

[snip]

>     With the onkeydown version, if I replace the <Esc> true branch
>with code to reset the value and then select and focus the first
>control, that works *except* that the select and focus do not happen.

     It works if I return false.

[snip]

>function DoKeypress(e)
>  {
>  var theKey=e.which;
>  if (theKey==13)     // <Enter>
>    {
>	alert("Use the button instead to submit the form.");
>	return false;
>	}
>  if (theKey==27)     // <Esc>
>    {
>    fEscape=confirm("Reset form?");
>	if (fEscape)

     Open a block, put in the control resetting code, then...

>	  return true;
                 ^^^^
     ...return false instead, and close the block.

>	else
>	  return false;
>	}
>  return true;
>  }

[snip]

Sincerely,

Gene Wirchenko

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


#12355

FromDavid Mark <dmark.cinsoft@gmail.com>
Date2012-03-02 20:02 -0800
Message-ID<c98f7a38-7d09-499b-aafd-ed89d045fd0a@c21g2000yqi.googlegroups.com>
In reply to#12331
On Mar 1, 4:25 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> On Tue, 28 Feb 2012 14:01:06 -0800, Gene Wirchenko <ge...@ocis.net>
> wrote:
>
> >     I am still trying to make sense of the onkey* clause.  I have
> >tried my test page below with both onkeypress and onkeydown.  (It is
> >safe to change all "press" to "down" and vice versa.
>
> >     The behavior for <Enter> is just what I want, but I am having
> >trouble with <Esc> which Mike Duffy said resets a page.  I am getting
> >different behaviour.  How do I override the behaviour?
>
> >     What I want -- with either onkeypress or onkeydown -- is if the
> >confirm() dialog box is answered Cancel, then nothing happens, but if
> >it is answered OK, *ALL* of the controls reset.
>
>      I have solved this.
>
> [snip]
>
> >     With the onkeydown version, if I replace the <Esc> true branch
> >with code to reset the value and then select and focus the first
> >control, that works *except* that the select and focus do not happen.
>
>      It works if I return false.
>

There you go. :)

Should have read this one from the bottom up.

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


#12354

FromDavid Mark <dmark.cinsoft@gmail.com>
Date2012-03-02 20:00 -0800
Message-ID<eba1be2c-d819-447b-8efd-1f9698d3142e@f5g2000yqm.googlegroups.com>
In reply to#12256
On Feb 28, 5:01 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> Dear JavaScripters:
>
>      I am still trying to make sense of the onkey* clause.

The onkey* event handlers?

> I have
> tried my test page below with both onkeypress and onkeydown.  (It is
> safe to change all "press" to "down" and vice versa.

As those events are quite different, it seems you are using trial and
error.

>
>      The behavior for <Enter> is just what I want, but I am having
> trouble with <Esc> which Mike Duffy said resets a page.

The handling of the Esc key is up to the browser developers. Not
unsurprisingly, the behavior varies according to what has the focus.
Not sure what you mean by "resets a page". (?)

> I am getting
> different behaviour.  How do I override the behaviour?

What behavior?

>
>      What I want -- with either onkeypress or onkeydown -- is if the
> confirm() dialog box is answered Cancel, then nothing happens, but if
> it is answered OK, *ALL* of the controls reset.

You mean you want to react to Esc and pop up a confirm and then act
accordingly to reset or not. Doesn't sound like a good idea to me.

>
>      With the onkeypress version, start the form, enter "one", <tab>,
> "two", <tab> "three", <Esc>.
> Control Three will reset before the
> confirm() dialog box is displayed.

When an INPUT has the focus, some browsers will undo your changes for
that control, setting value to the defaultValue, which is what a form
reset will do. Other browsers blur the control. It's really up to them
and I wouldn't get in the middle of it.

And as you waited until the keypress event, it was too late to prevent
the default action (reset in your case). It doesn't make any sense to
look for the Esc *key* in the keypress event as that is for dealing
with *characters*. Pressing the Esc key does not insert an ASCII 27
(or whatever) into the field, nor does it remove any characters (as
with backspace), so you can't even expect it to cause a keypress
event.  I know IE 8- doesn't fire it.  Oddly enough, it skips that
event for Enter (which does insert characters) as well.

Was going to cite documentation, but this is best I could find:

https://developer.mozilla.org/en/DOM/element.onkeypress

"The keypress event is raised when the user presses a key on the
keyboard."

You can learn more by reading through the code in my Keyboard primer:

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

> Regardless of which of OK or
> Cancel is selected, on the next <Esc>, all controls will be reset
> before the confirm() dialog box is displayed.  This is not what I
> want.

Sounds like a problem in your code (as opposed to DOM variations).

>
>      With the onkeydown version, start the form, enter "one", <tab>,
> "two", <tab> "three", <Esc>.  The dialog will appear.  If Cancel is
> selected, nothing happens (Good).  If OK is selected, then only
> Control Three will be reset.

Also a problem in your code.

> If <Esc> is entered again immediately
> after and OK chosen, then the rest of the controls will reset.  Not
> good enough.

Clearly not, but I don't think the DOM is the culprit.

>
>      With the onkeydown version, if I replace the <Esc> true branch
> with code to reset the value and then select and focus the first
> control, that works *except* that the select and focus do not happen.

Well you can't go with that. :)

> (Select and focus code in another test form (my big one) does work in
> the reset button.  I am trying to cover reset within input controls as
> a functionality to add to that big form.)

I should state again that this is probably best avoided.

>
>      If I break out the select and focus code, I can get it to work. I
> set a global flag indicating whether to reset the select and focus.
> The on clause is then the somewhat awkward:
>           onkeydown="var RetVal=DoKeydown(); ResetSelectFocus();
> return RetVal;"
> You can probably imagine the other code easily enough.  Why this
> breakout works, I do not know.  It also makes the control's code a lot
> more cluttered.
>
>      The end result of this post is that I do have something that
> works, but I have the horrible feeling that I am missing the point.  I
> think that implementing <Esc> in a control resetting a page should not
> be so difficult.  What am I missing?
>
> ***** Start of Test Page *****
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> "http://www.w3.org/TR/html4/strict.dtd">
> <html>
>
> <head>
>   <meta http-equiv="Content-Type" content="text/html;
> charset=iso-8859-1">
>   <title>2012-02-28: onkey*</title>
> </head>
>
> <body>
>
> <script type="text/javascript">
>
> function DoKeypress(e)
>   {
>   var theKey=e.which;

Won't work in IE 8-.

>   if (theKey==13)     // <Enter>
>     {
>         alert("Use the button instead to submit the form.");
>         return false;
>         }

I'd lose that.  What are you trying to accomplish by preventing the
use of the Enter key in the form?

>   if (theKey==27)     // <Esc>
>     {
>     fEscape=confirm("Reset form?");
>         if (fEscape)
>           return true;
>         else
>           return false;
>         }
>   return true;

Here's one of your problems. You are assuming that the Esc key means
"reset the control" (and you can't assume that). The only way to make
this work reliably (in more than one browser) is to prevent the
default action on Esc (in keydown events) and handle the reset like
this:-

this.value = this.defaultValue;

>   }
>
> </script>
>
> <form name=theForm>

Quotes.

>   One: <input name=One value="Start One" onkeypress="return
> DoKeypress(event);">
>   <br>
>   Two: <input name=Two value="Start Two" onkeypress="return
> DoKeypress(event);">
>   <br>
>   Three: <input name=Three value="Start Three" onkeypress="return
> DoKeypress(event);">
> </form>
>
> <script type="text/javascript">
> theForm.One.select();
> theForm.One.focus();

Never reference form controls like that. See the FAQ.

> </script>
>
> </body>
>
> </html>

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


#12358

FromMike Duffy <Use_guestbook_page@website.in.sig>
Date2012-03-03 05:18 +0000
Message-ID<XnsA00B326A7B9Einvalidcom@94.75.214.39>
In reply to#12354
David Mark <dmark.cinsoft@gmail.com> wrote in news:eba1be2c-d819-447b-8efd-
1f9698d3142e@f5g2000yqm.googlegroups.com:

>>      The behavior for <Enter> is just what I want, but I am having
>> trouble with <Esc> which Mike Duffy said resets a page.

What I meant was, that a user might *expect* that he is able to press 
"Esc" to get out of a page without anything happening.

This is consistent with the manner in which most GUIs operate. In windows 
programs, (as in HTML forms), Enter means you have finished putting data 
into all fields, (analagous to the Submit action), Tab moves you cyclicly 
to the next field (both in GUIs and in HTML forms). In GUIs, the Escape key 
kills the current data entry page, usually bringing you back to the 
previous page, or upwards in a hierarchical menu system. Thus to make your 
HTML form function as the user might probably expect, the Escape key should 
cause a form reset action. I did not mean to imply that it happens 
automatically.


-- 
http://pages.videotron.ca/duffym/index.htm

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


#12630

FromDavid Mark <dmark.cinsoft@gmail.com>
Date2012-03-12 18:56 -0700
Message-ID<951e732b-a0e8-44e0-8b55-e0c9334230a7@r21g2000yqa.googlegroups.com>
In reply to#12358
On Mar 3, 1:18 am, Mike Duffy <Use_guestbook_p...@website.in.sig>
wrote:
> David Mark <dmark.cins...@gmail.com> wrote in news:eba1be2c-d819-447b-8efd-
> 1f9698d31...@f5g2000yqm.googlegroups.com:
>
> >>      The behavior for <Enter> is just what I want, but I am having
> >> trouble with <Esc> which Mike Duffy said resets a page.
>
> What I meant was, that a user might *expect* that he is able to press
> "Esc" to get out of a page without anything happening.
>
> This is consistent with the manner in which most GUIs operate. In windows
> programs, (as in HTML forms), Enter means you have finished putting data
> into all fields, (analagous to the Submit action), Tab moves you cyclicly
> to the next field (both in GUIs and in HTML forms). In GUIs, the Escape key
> kills the current data entry page, usually bringing you back to the
> previous page, or upwards in a hierarchical menu system. Thus to make your
> HTML form function as the user might probably expect, the Escape key should
> cause a form reset action. I did not mean to imply that it happens
> automatically.
>

I understand, but not sure I see the exact relationship between
closing a dialog and resetting the form. Granted, they both abandon
the data (though a proper UI should ask before closing a data entry
dialog).

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


#12407

FromGene Wirchenko <genew@ocis.net>
Date2012-03-04 21:00 -0800
Message-ID<7uh8l7t0efd4606dga720sebmaabslbj5v@4ax.com>
In reply to#12354
On Fri, 2 Mar 2012 20:00:55 -0800 (PST), David Mark
<dmark.cinsoft@gmail.com> wrote:

>On Feb 28, 5:01 pm, Gene Wirchenko <ge...@ocis.net> wrote:
>> Dear JavaScripters:
>>
>>      I am still trying to make sense of the onkey* clause.
>
>The onkey* event handlers?

     onkeypress=, onkeydown=, onkeyup=.

>> I have
>> tried my test page below with both onkeypress and onkeydown.  (It is
>> safe to change all "press" to "down" and vice versa.
>
>As those events are quite different, it seems you are using trial and
>error.

     I was trying to determine which one to use.

[snip]

>Was going to cite documentation, but this is best I could find:

     This is why I was reduced to trial and error.

>https://developer.mozilla.org/en/DOM/element.onkeypress
>
>"The keypress event is raised when the user presses a key on the
>keyboard."

     On my system (Windows 7, IE 9), it is not raised when <tab> is
pressed.

[snip]

Sincerely,

Gene Wirchenko

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


#12631

FromDavid Mark <dmark.cinsoft@gmail.com>
Date2012-03-12 18:59 -0700
Message-ID<51142d01-2489-4ca2-bf2e-7d2a60807a21@db5g2000vbb.googlegroups.com>
In reply to#12407
On Mar 5, 1:00 am, Gene Wirchenko <ge...@ocis.net> wrote:
> On Fri, 2 Mar 2012 20:00:55 -0800 (PST), David Mark
>
> <dmark.cins...@gmail.com> wrote:
> >On Feb 28, 5:01 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> >> Dear JavaScripters:
>
> >>      I am still trying to make sense of the onkey* clause.
>
> >The onkey* event handlers?
>
>      onkeypress=, onkeydown=, onkeyup=.
>
> >> I have
> >> tried my test page below with both onkeypress and onkeydown.  (It is
> >> safe to change all "press" to "down" and vice versa.
>
> >As those events are quite different, it seems you are using trial and
> >error.
>
>      I was trying to determine which one to use.

Right, but that's not the best way to go about it. It would be very
easy to make an incorrect inference. Granted, the documentation in the
MDC wiki is horrible. You'd be better off reading the DOM specs.

>
> [snip]
>
> >Was going to cite documentation, but this is best I could find:
>
>      This is why I was reduced to trial and error.
>
> >https://developer.mozilla.org/en/DOM/element.onkeypress
>
> >"The keypress event is raised when the user presses a key on the
> >keyboard."
>
>      On my system (Windows 7, IE 9), it is not raised when <tab> is
> pressed.

I'm sure I mentioned that.  Really no reason it should be raised as
keypress is for *characters*.  Browsers don't insert tab characters on
pressing the tab *key*.  Granted, some browsers will fire the keypress
event on any key (but you don't have to pay attention). ;)

[toc] | [prev] | [standalone]


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


csiph-web