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

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

Intercept radio onclick event

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

Contents

  Intercept radio onclick event wmgill <webworker1950@gmail.com> - 2016-09-12 11:58 -0400
    Re: Intercept radio onclick event wmgill <webworker1950@gmail.com> - 2016-09-13 09:17 -0400
      Re: Intercept radio onclick event "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-09-13 15:35 +0200
        Re: Intercept radio onclick event wmgill <webworker1950@gmail.com> - 2016-09-13 10:27 -0400
        Re: Intercept radio onclick event Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-13 16:58 +0200
    Intercept radio onclick event Ram Tobolski <ramtob@gmail.com> - 2016-09-13 11:38 -0700
      Re: Intercept radio onclick event wmgill <webworker1950@gmail.com> - 2016-09-13 15:53 -0400

#31340 — Intercept radio onclick event

Is there a way to intercept a radio button onclick event and pass it 
through a confirmation process before allowing it to proceed or 
cancelling it?  I have found several solutions that propose to do this, 
but in fact they just set or reset the radio's checked property, which 
doesn't reset any other radio button in the group to original state.

The reason I ask is I have a data input form, and am using radio buttons 
to select which mode (add new, edit existing, or delete existing 
record).  If a user begins in one mode then wants to switch to another I 
need to test that no data will be lost in the process (i.e. changing 
mode without deciding what to do with the data in the partially filled 
form).

Radio buttons may not be the best approach. I can think of several other 
ways to accomplish this, but welcome any insight.

[toc] | [next] | [standalone]

#31354

On 9/12/2016 11:58 AM, wmgill wrote:
> Is there a way to intercept a radio button onclick event and pass it
> through a confirmation process before allowing it to proceed or
> cancelling it?  I have found several solutions that propose to do this,
> but in fact they just set or reset the radio's checked property, which
> doesn't reset any other radio button in the group to original state.
>
> The reason I ask is I have a data input form, and am using radio buttons
> to select which mode (add new, edit existing, or delete existing
> record).  If a user begins in one mode then wants to switch to another I
> need to test that no data will be lost in the process (i.e. changing
> mode without deciding what to do with the data in the partially filled
> form).
>
> Radio buttons may not be the best approach. I can think of several other
> ways to accomplish this, but welcome any insight.

I think I may have found some of my problem(s).  Due to poor memory, and 
inconsistent browser response I was getting unexpected, and inconsistent 
results, causing me to draw wrong conclusions.

I seem to be catching the onclick event, but not early enough in the 
process. So I still need some help in a couple areas.

I found that:

<input type="radio" name="test" value="3" onclick="return false;"> 
works correctly on all the browsers I tested except MSIE.

<input type="radio" name="test" value="2" onclick="catchclick(this);"> 
where catchclick() returns the result of confirm(), does not work on any 
browser tested.

and finally <input type="radio" name="test" value="4" onclick="return 
catchclick(this);"> works but seems to be capturing the event later in 
the process.  While onclick="return false;" never toggles the radio 
buttons, onclick="return catchclick(this);" toggles them, but then 
differs in different browsers.  In MS browsers (IE and Edge) a returned 
false deselects the radio but does not reselect the previous radio. In 
Firefox and Chrome a returned false deselects the clicked radio and 
reselecs the previous radio.

Any insights as to what is going on, and how to correct it?

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

#31355

On 13.09.2016 at 15:17, wmgill wrote:

> On 9/12/2016 11:58 AM, wmgill wrote:
>
>> Is there a way to intercept a radio button onclick event and pass it
>> through a confirmation process before allowing it to proceed or
>> cancelling it?  I have found several solutions that propose to do this,
>> but in fact they just set or reset the radio's checked property, which
>> doesn't reset any other radio button in the group to original state.
> 
> I seem to be catching the onclick event, but not early enough in the
> process. So I still need some help in a couple areas.
> 
> Any insights as to what is going on, and how to correct it?

Have you considered to use the change event instead of a the click
event?  See
<https://developer.mozilla.org/en-US/docs/Web/Events/change>, for instance.

-- 
Christoph M. Becker

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

#31356

On 9/13/2016 9:35 AM, Christoph M. Becker wrote:
>
> Have you considered to use the change event instead of a the click
> event?  See
> <https://developer.mozilla.org/en-US/docs/Web/Events/change>, for instance.
>
Considered, and dismissed. I have seen numerous admonitions against 
relying on the change event, primarily because of browser differences in 
interpretation of the what and when of change.

Additionally I don't see how it could work unless I test and save the 
selected state of the group so that I can restore it later if necessary. 
If I have to loop through the radios; record which is selected; then 
reselect if necessary, I can use a couple different triggers.  I was 
hoping I could intercept the process early enough that nothing toggles 
until the user confirms the action. That may not be possible, or it may 
mean creating a new event listener.

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

#31357

Christoph M. Becker wrote:

> On 13.09.2016 at 15:17, wmgill wrote:
>> On 9/12/2016 11:58 AM, wmgill wrote:
>>> Is there a way to intercept a radio button onclick event and pass it
>>> through a confirmation process before allowing it to proceed or
>>> cancelling it?  I have found several solutions that propose to do this,
>>> but in fact they just set or reset the radio's checked property, which
>>> doesn't reset any other radio button in the group to original state.
>> I seem to be catching the onclick event, but not early enough in the
>> process. So I still need some help in a couple areas.
>> 
>> Any insights as to what is going on, and how to correct it?
> 
> Have you considered to use the change event instead of a the click
> event?  See
> <https://developer.mozilla.org/en-US/docs/Web/Events/change>, for
> instance.

The “click” event is specified to be fired when a pointing device’s state 
has changed from “button pushed” (“mousedown” event)/“finger touching” 
(“touchstart” event)/“pen down” (“pointerdown” event) and back to “button 
released” (mouseup)/“finger not touching” (touchend)/“pen up” (“pointerup” 
event) while on the same target.  IOW:

  mousedown   → … → mouseup   → click (if same target);
  touchstart  → … → touchend  → click (if same target);
  pointerdown → … → pointerup → click (if same target).

The “change” event is specified to be fired when a control’s value has been 
changed by the user and it has just lost focus: focusin → … → focusout 
→ change (if value changed by user).

So canceling either on a radiobutton is not likely to prevent it from being 
checked.  In Chromium 53 on GNU/Linux it does not, although the “change” 
event is already fired when the radiobutton is checked (interestingly, not 
when another radiobutton in the same group is checked, i.e. the target’s 
“checked” state changes from “checked” to “unchecked”).  To see what is 
going on, use the browser’s developer tools.

One could additionally cancel events such as “mousedown”, “touchstart”, and 
“pointerdown” – this does not work with radiobuttons in that Chromium 
version, only canceling “click” works there –, but why not simply set the 
“disabled” attribute/property of the radiobutton (to “true”)?

As an alternative, the “defaultChecked” property value of each radiobutton 
of the group could be used, but reverting user’s choices immediately really 
is not user-friendly and might be prevented by browser vendors in the future 
(they already did so with disabling this.focus() on “blur”).

See also <https://developer.mozilla.org/en-US/docs/Web/Events> pp. (AFAIK, 
the best event reference there is; I am pleased to see how far it and the 
events landscape has evolved since I made my initial contribution.)

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail. 

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

#31358

>If a user begins in one mode then wants to switch to another I need to test that no data will be lost in the process

Well, don't let the user switch modes in the middle. It's a freedom that is likely to confuse the user. After a mode was selected, disable the mode buttons, and show Ok and Cancel buttons. After the user confirmed or canceled, re-enable the mode buttons.

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

#31359

On 9/13/2016 2:38 PM, Ram Tobolski wrote:
>
>> If a user begins in one mode then wants to switch to another I need to test that no data will be lost in the process
>
> Well, don't let the user switch modes in the middle. It's a freedom that is likely to confuse the user. After a mode was selected, disable the mode buttons, and show Ok and Cancel buttons. After the user confirmed or canceled, re-enable the mode buttons.
>

Any user that gets confused by changing between add/edit/delete 
shouldn't be working on any database of mine.

[toc] | [prev] | [standalone]

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

csiph-web