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

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

The onkey*= Clause et al: Solved

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

Contents

  The onkey*= Clause et al: Solved Gene Wirchenko <genew@ocis.net> - 2012-03-02 15:37 -0800
    Re: The onkey*= Clause et al: Solved David Mark <dmark.cinsoft@gmail.com> - 2012-03-02 20:05 -0800
      Re: The onkey*= Clause et al: Solved Gene Wirchenko <genew@ocis.net> - 2012-03-04 21:02 -0800
        Re: The onkey*= Clause et al: Solved David Mark <dmark.cinsoft@gmail.com> - 2012-03-12 21:51 -0700
          Re: The onkey*= Clause et al: Solved Gene Wirchenko <genew@ocis.net> - 2012-03-12 22:13 -0700
            Re: The onkey*= Clause et al: Solved David Mark <dmark.cinsoft@gmail.com> - 2012-03-12 22:38 -0700
              Re: The onkey*= Clause et al: Solved Gene Wirchenko <genew@ocis.net> - 2012-03-13 19:40 -0700
                Re: The onkey*= Clause et al: Solved David Mark <dmark.cinsoft@gmail.com> - 2012-03-13 20:56 -0700
    Re: The onkey*= Clause et al: Solved Dr J R Stockton <reply1209@merlyn.demon.co.uk> - 2012-03-03 20:35 +0000

#12350 — The onkey*= Clause et al: Solved

Dear JavaScripters:

     I finally got my form reset with <Esc> working.  The event model
of JavaScript controls is definitely not as clear as I would like.
Turning on validation checking after resetting the form was the
problem.  For some reason, that would cause a validation to fire right
away.  I omitted doing that, and it be done by the next character to
be processed, and all is now well.

     Until the next little battle, that is.

     Thank you for various bits of help, but I had to fight most of
this one alone.  There does not seem to be much on the Net about the
JavaScript form event model.  I mean a detailed description.

Sincerely,

Gene Wirchenko

[toc] | [next] | [standalone]

#12356

On Mar 2, 6:37 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> Dear JavaScripters:
>
>      I finally got my form reset with <Esc> working.  The event model
> of JavaScript controls is definitely not as clear as I would like.

See my reply in previous thread. Your problem was related to a bad
assumption, not the DOM event model.

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

#12408

On Fri, 2 Mar 2012 20:05:01 -0800 (PST), David Mark
<dmark.cinsoft@gmail.com> wrote:

>On Mar 2, 6:37 pm, Gene Wirchenko <ge...@ocis.net> wrote:
>> Dear JavaScripters:
>>
>>      I finally got my form reset with <Esc> working.  The event model
>> of JavaScript controls is definitely not as clear as I would like.
>
>See my reply in previous thread. Your problem was related to a bad
>assumption, not the DOM event model.

     Well, given that the event model is not clear, that pretty much
set me up to make wrong assumptions.  You tell me why if a control has
focus, that its onblur would fire as soon as I re-enabled validations.

Sincerely,

Gene Wirchenko

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

#12635

On Mar 5, 1:02 am, Gene Wirchenko <ge...@ocis.net> wrote:
> On Fri, 2 Mar 2012 20:05:01 -0800 (PST), David Mark
>
> <dmark.cins...@gmail.com> wrote:
> >On Mar 2, 6:37 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> >> Dear JavaScripters:
>
> >>      I finally got my form reset with <Esc> working.  The event model
> >> of JavaScript controls is definitely not as clear as I would like.
>
> >See my reply in previous thread. Your problem was related to a bad
> >assumption, not the DOM event model.
>
>      Well, given that the event model is not clear, that pretty much
> set me up to make wrong assumptions.  You tell me why if a control has
> focus, that its onblur would fire as soon as I re-enabled validations.
>

Re-enabled validations?  ISTM that there were several problems with
the code, but I don't follow what you are talking about with respect
to "validations".

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

#12636

On Mon, 12 Mar 2012 21:51:42 -0700 (PDT), David Mark
<dmark.cinsoft@gmail.com> wrote:

>On Mar 5, 1:02 am, Gene Wirchenko <ge...@ocis.net> wrote:
>> On Fri, 2 Mar 2012 20:05:01 -0800 (PST), David Mark
>>
>> <dmark.cins...@gmail.com> wrote:
>> >On Mar 2, 6:37 pm, Gene Wirchenko <ge...@ocis.net> wrote:
>> >> Dear JavaScripters:
>>
>> >>      I finally got my form reset with <Esc> working.  The event model
>> >> of JavaScript controls is definitely not as clear as I would like.
>>
>> >See my reply in previous thread. Your problem was related to a bad
>> >assumption, not the DOM event model.
>>
>>      Well, given that the event model is not clear, that pretty much
>> set me up to make wrong assumptions.  You tell me why if a control has
>> focus, that its onblur would fire as soon as I re-enabled validations.

>Re-enabled validations?  ISTM that there were several problems with
>the code, but I don't follow what you are talking about with respect
>to "validations".

     I have onblur event code that validates for each control.  If the
validation fails, focus has to be put back to the erroneous control.
In order to do this, the validation for the new control must be turned
off before the focus is moved.  If it is not, then it may result in
another validation failure.  After, the validation must be turned back
on.

     I turn the validation on and off by setting a global
appropriately.  The start of the validation code checks whether
validation is currently enabled and simply returns true if validation
is off.

     The problem was the <Esc> handling that I was having was that as
soon as I turned the validation back on, the validation code was
executed.  Somehow, an event was firing.

     This problem has been dealt with, but it was not easy to track
down.

Sincerely,

Gene Wirchenko

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

#12639

On Mar 13, 1:13 am, Gene Wirchenko <ge...@ocis.net> wrote:
> On Mon, 12 Mar 2012 21:51:42 -0700 (PDT), David Mark
>
>
>
>
>
>
>
>
>
> <dmark.cins...@gmail.com> wrote:
> >On Mar 5, 1:02 am, Gene Wirchenko <ge...@ocis.net> wrote:
> >> On Fri, 2 Mar 2012 20:05:01 -0800 (PST), David Mark
>
> >> <dmark.cins...@gmail.com> wrote:
> >> >On Mar 2, 6:37 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> >> >> Dear JavaScripters:
>
> >> >>      I finally got my form reset with <Esc> working.  The event model
> >> >> of JavaScript controls is definitely not as clear as I would like.
>
> >> >See my reply in previous thread. Your problem was related to a bad
> >> >assumption, not the DOM event model.
>
> >>      Well, given that the event model is not clear, that pretty much
> >> set me up to make wrong assumptions.  You tell me why if a control has
> >> focus, that its onblur would fire as soon as I re-enabled validations.
> >Re-enabled validations?  ISTM that there were several problems with
> >the code, but I don't follow what you are talking about with respect
> >to "validations".
>
>      I have onblur event code that validates for each control.  If the
> validation fails, focus has to be put back to the erroneous control.

Mustn't be put back... Just add a class to indicate the value is
invalid.


> In order to do this, the validation for the new control must be turned
> off before the focus is moved.  If it is not, then it may result in
> another validation failure.  After, the validation must be turned back
> on.

Well, that's entirely up to you (and your code), but I would forget
the whole thing.

>
>      I turn the validation on and off by setting a global
> appropriately.  The start of the validation code checks whether
> validation is currently enabled and simply returns true if validation
> is off.

Whatever. You can lose all of those complications if you take my
advice.

>
>      The problem was the <Esc> handling that I was having was that as
> soon as I turned the validation back on, the validation code was
> executed.  Somehow, an event was firing.

You've reached the point where your code is too complex and unwieldy
to track. I wouldn't try to do what you are trying to do. It reminds
me of Dojo trying to track tab and shift+tab to figure out where the
focus was going next. You have to understand the limits of what is
appropriate in a browser script (particularly if you want it to be a
cross-browser script).

>
>      This problem has been dealt with, but it was not easy to track
> down.

What did the suspect look like? If you don't know exactly what
happened and why, you are likely to run into trouble with the next
browser you test.

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

#12675

On Mon, 12 Mar 2012 22:38:10 -0700 (PDT), David Mark
<dmark.cinsoft@gmail.com> wrote:

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

[snip]

>>      This problem has been dealt with, but it was not easy to track
>> down.
>
>What did the suspect look like? If you don't know exactly what

     In my onkeydown handler, rather than re-enable the validation
after handling <Esc>, I just return.  The following character,
assuming it is not <Esc>, does turn on validation as part of its
handling.  This was not intuitive, and I hit on it by accident.  It is
clear to me why it works now, but I still do not know why the
validation was firing immediately.

>happened and why, you are likely to run into trouble with the next
>browser you test.

     Possibly.  I recently found that my general scheme does not work
in Firefox.  I will deal with that later.

Sincerely,

Gene Wirchenko

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

#12681

On Mar 13, 10:40 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> On Mon, 12 Mar 2012 22:38:10 -0700 (PDT), David Mark
>
> <dmark.cins...@gmail.com> wrote:
> >On Mar 13, 1:13 am, Gene Wirchenko <ge...@ocis.net> wrote:
>
> [snip]
>
> >>      This problem has been dealt with, but it was not easy to track
> >> down.
>
> >What did the suspect look like? If you don't know exactly what
>
>      In my onkeydown handler, rather than re-enable the validation
> after handling <Esc>, I just return.

Your keydown listener.

> The following character,
> assuming it is not <Esc>, does turn on validation as part of its
> handling.  This was not intuitive, and I hit on it by accident.  It is
> clear to me why it works now, but I still do not know why the
> validation was firing immediately.
>
> >happened and why, you are likely to run into trouble with the next
> >browser you test.
>
>      Possibly.  I recently found that my general scheme does not work
> in Firefox.  I will deal with that later.

Sounds like definitely (and it didn't take long). ;)

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

#12384

In comp.lang.javascript message <72m2l7lf5kn3d4v63ufslu4p6v235bpkbp@4ax.
com>, Fri, 2 Mar 2012 15:37:10, Gene Wirchenko <genew@ocis.net> posted:

>Dear JavaScripters:
>
>     I finally got my form reset with <Esc> working.  The event model
>of JavaScript controls is definitely not as clear as I would like.
>Turning on validation checking after resetting the form was the
>problem.  For some reason, that would cause a validation to fire right
>away.  I omitted doing that, and it be done by the next character to
>be processed, and all is now well.
>
>     Until the next little battle, that is.
>
>     Thank you for various bits of help, but I had to fight most of
>this one alone.  There does not seem to be much on the Net about the
>JavaScript form event model.  I mean a detailed description.

Try the large rhinoceros :
<http://www.amazon.co.uk/s/277-0211083-6467414?ie=UTF8&tag=firefox-uk-
21&index=blended&link_code=qs&field-keywords=flanagan%20david&sourceid=M
ozilla-search>.


<FAQENTRY> There seems to be a new Pocket Rhino, and a Kindle, but not
necessarily world-wide.


-- 
 (c) John Stockton, nr London UK  ?@merlyn.demon.co.uk  IE8 FF8 Op11 Sf5 Cr15
   news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>.
   <http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
   <http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[toc] | [prev] | [standalone]

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

csiph-web