View Full Version : onchange event of checkbox in client side

06-09-2006, 05:30 AM
hi friends,

Is there a method to call a javascript function on change of the state of a checkbox control in asp.net without having postback the control.

it generates following html source at the client end.

input id="chkInterest1" type="checkbox" name="chkInterest1" /><label for="chkInterest1">Interest1</label>

thanks in advance


06-09-2006, 11:49 AM
better us onclick

<input id="chkInterest1" type="checkbox" name="chkInterest1" onclick="if(this.checked){myFunction()}"/><label for="chkInterest1">Interest1</label>

06-09-2006, 03:37 PM
Be aware of the difference between using onclick and onchange on a checkboxes (and radio buttons). OnClick happens BEFORE the change occurs, so if you click a checkbox that is currently checked, onclick will see the box as checked and onchange will see it as unchecked.

06-09-2006, 03:43 PM
Be aware of the difference between using onclick and onchange on a checkboxes (and radio buttons). OnClick happens BEFORE the change occurs, so if you click a checkbox that is currently checked, onclick will see the box as checked and onchange will see it as unchecked.

<input id="chkInterest1" type="checkbox" name="chkInterest1" onclick="alert(this.checked)"/>

06-09-2006, 04:19 PM
Hmmm, I could've sworn that worked.... but you're right.

Very interesting indeed. If you return false from the onclick event, the checkbox will change on the event firing and then change back when you return false. I have a feeling that's not supposed to happen, I'll do some digging.

06-09-2006, 04:38 PM
ussually almost all the events will fire first the javascript function than their default HTML action - if any, for instance onsubmit. For unknown reasons (or for good reasons) onclick (and onkeyup, and some other few, I guess) do the opposite.

06-09-2006, 04:59 PM
No, that's no entirely true. onclick fires before the default action for hrefs, which is why you can cancel the link before you follow it.

That leads me to believe that there's something weird going on with the way checkboxes handle onclick, but it's definitely not onclick across the board.

06-09-2006, 05:11 PM
Maybe this is the form's controls behaviour...

06-09-2006, 05:14 PM
Nope, just tested a submit button with onclick = return false and it doesn't submit the form. So it looks like the checkbox. I'm gonna test radios.

06-09-2006, 05:17 PM
I created 4 radio buttons, none default selected, each with onclick="alert(this.checked);return false;"

If you none are selected when you click one it alerts true and selects it.
But then, if you click any other one after that, you get an alert that says true, and visually, the radio button selection has changed, but when click "OK" on the alert, the radio button snaps back to the first one you selected.

So radios and checkboxes act weird with onclick.

06-09-2006, 05:18 PM
don't, is the same as checkboxes, I know that for long while. I use onclick and this.checked for long time ago to validade or calculate values for checkboxes and radios.

06-09-2006, 05:26 PM
Interesting is also that the "unsual" behaviour, as you say, it applies for the associated lebels as well

<input id="chkInterest1" type="checkbox" name="chkInterest1" onclick="alert(this.checked)"/><label for="chkInterest1">Interest1</label>
<input id="chkInterest2" type="checkbox" name="chkInterest2" onclick="alert(this.checked)"/><label for="chkInterest2">Interest2</label>

06-09-2006, 05:31 PM
I understand that this has been the behavior for some time, but doesn't it seem unusual that instead of cancelling the default behavior, the default behavior actually happens and then you reverse it? What could be the explanation for this? Why would you cancel the default action before it happens on links and on buttons, but not checkboxes or radio buttons?

And why is it that for radio buttons, if none is selected, and you return false onclick (which should cancel the default behavior) it still selects one the first time but not subsequent times?

I'm going to have dig through the w3c dom standard on this to see what they have to say about some of it, but I'm currently of the opinion that this is not standards compliant behavior.

06-09-2006, 05:34 PM
I don't think is non-standard. As a coder I feel that for checkboxes and radios things must be exactly like they are. I do need to have the HTML checked status triggered before I do something with my function.

06-09-2006, 05:36 PM
But that's what onchange would be for. If you want to fire an event when the checkbox value changes, that's one thing. If you want to prevent the checkbox from changing values when someone clicks on it (based on some dynamic conditions) then you have onclick for that. If you return false on the onclick, it even squelches the "change" event from firing, but somehow the value of the checkbox is changed ONLY for the duration of the click event. It just doesn't make sense.

I don't think it's necessary or even sensible for the onclick behavior to do what it's doing when you have onchange to satisfy the need you have.

06-09-2006, 05:46 PM
Except for listboxes I don't like onchange, as it will do it's job only after the control looses it's focus, or most of the time I want to trigger the function exactly on that moment, no latter

06-09-2006, 05:52 PM
The W3C recommenation is quite clear:
"The onchange event occurs when a control loses the input focus and its value has been modified since gaining focus. This attribute applies to the following elements: INPUT, SELECT, and TEXTAREA."


06-09-2006, 06:01 PM
Interestingly enough though, onchange does fire immediately after clicking a checkbox. Try:

<input type="checkbox" id="x" onchange="alert('checkbox changed');" />

It won't wait for losing focus, it fires as soon as you click it.

So is ~this~ behavior a deviation from the standard? It seems almost like both behaviors, are deviations from the standard.

I'm having trouble finding information in the standard about event handlers firing prior to the default action.

06-09-2006, 06:02 PM
ok, let me know if u find something

06-09-2006, 06:05 PM
Here it is, and here's why you shouldn't use onclick:

Note: During the handling of a click event on an input element with a type attribute that has the value "radio" or "checkbox", some implementations may change the value of this property before the event is being dispatched in the document. If the default action of the event is canceled, the value of the property may be changed back to its original value. This means that the value of this property during the handling of click events is implementation dependent.


Using onclick, the value of the element is completely unspecified and therefore completely unpredictable across browsers and browser versions.

~~lunch, back in 25~~

06-10-2006, 08:09 AM
:thumbsup: I still don't like onchange... I don't know why, irational, with no reason, I dislike it:D It has nothing to do with right and wrong... :D