Checkbox: programmatically checking it, triggering the 'onchange' handler

[aundro]

Hello,

I've been looking on the web for a solution to this problem:
I create a set of checkboxes, and 2 buttons:
- one is labeled "All"
- the other is labeled "None"

Clicking "All" is supposed to check all the checkboxes, which it does
(that's not rocket science , but the 'onchange' event does not get
triggered.

I couldn't find an answer to this issue in the archives of
c.l.j. (even though I bet there is), so any idea/pointer is absolutely
welcome.

Am I doing something inappropriate here?

Thank you for any info!

Best regards,

Arnaud

 

[Morgan]

Observe the rule of KIS,

;-)

<form>

<input type="checkbox" name="checkIt" />
<input type="checkbox" name="checkIt" />
<input type="checkbox" name="checkIt" />

<input type="button" value="Tick All Boxs" onclick="runCheckAll()" />

</form>

<script type="text/javascript">
<!--
function runCheckAll()
{

var changeCheck = document.getElementsByName('checkIt');
for(i=0; i<changeCheck.length; i++)
{
changeCheck.checked = true;
}

}
//-->
</script>

 

[Morgan]

Ah wait, I didn't read your post properly, sorry.

I think you can set a handler to fire from a script without user
changing anything. Waitasec...

 

[VK]

Hello,

I've been looking on the web for a solution to this problem:
I create a set of checkboxes, and 2 buttons:
- one is labeled "All"
- the other is labeled "None"

Clicking "All" is supposed to check all the checkboxes, which it does
(that's not rocket science , but the 'onchange' event does not get
triggered.

Maybe because it doesn't have to?
<checkbox> has one top level user input event: "onclick" (besides all
these onkeypress, onbeforeprint etc.)

IE has new event called "onpropertychange" which will be called if you
change the checkbox state:

<input type="checkbox" name="cb02" onpropertychange="myFunction(this)">

FF has some very obscure interface for programmatically generated
events discussed in my post here:

Posted by: VK
<http://groups.google.com/group/comp..._frm/thread/2602a35ef4a14ac1/50a2ac2da48b4df3>

But in this particular case an "artificial click" seems has no effect
(did not check this option through).

Am I doing something inappropriate here?

You can do whatever you want in any way you want
I am just not clear why you need this two-tier scheme: 1) select 2)
trig onselect event to do something other ?
Why not just do it in one step:

checkboxes.checked = true;
someOtherActionWith(checkboxes);

?

 

[aundro]

Why not just do it in one step:

checkboxes.checked = true;
someOtherActionWith(checkboxes);

Well, that's the way I'm proceeding right now, while I was waiting for
a possible better solution but, as nobody seems to be really inspired,
I guess there are none.

Also this post was, I admit, a bit oriented towards a more general
"Can someone tell/teach me about 'simulated' events?"
(I honestly though programmatically checking a checkbox would trigger
it's onchange handler)

Still: Thank you very much for the info!

Arnaud

 

[VK]

Why not just do it in one step:

checkboxes.checked = true;
someOtherActionWith(checkboxes);

Well, that's the way I'm proceeding right now, while I was waiting for
a possible better solution but, as nobody seems to be really inspired,
I guess there are none.

Also this post was, I admit, a bit oriented towards a more general
"Can someone tell/teach me about 'simulated' events?"
(I honestly though programmatically checking a checkbox would trigger
it's onchange handler)

As I said your question as posted was "How to trig an event from an
element if such element is not native EventProducer of the event in
question?".

Checkbox is not EventProducer of the "onchange" event (<select> is).
Theoretically you can create any artificial event using
document.createEvent (Gesko) and document.cretateEventObject (IE)
methods. But trying to dispatch artificial event to an element in
violation of its EventProducer model *seems* to lead to the security
exeption and script abort in FireFox.
As the question indeed doesn't seem very inspiring (it's rather QA
testing than an actual task) I don't feel like exploring it to the full
depth. Nevertheless the posted link shows all necessary technique to
program artificial events and to dispatch / fire them onto different
object. If you take your time to explore it - it would be interesting
to know the test results.

 

[RobG]

Why not just do it in one step:

checkboxes.checked = true;
someOtherActionWith(checkboxes);

Well, that's the way I'm proceeding right now, while I was waiting for
a possible better solution but, as nobody seems to be really inspired,
I guess there are none.

Also this post was, I admit, a bit oriented towards a more general
"Can someone tell/teach me about 'simulated' events?"
(I honestly though programmatically checking a checkbox would trigger
it's onchange handler)

As I said your question as posted was "How to trig an event from an
element if such element is not native EventProducer of the event in
question?".

Checkbox is not EventProducer of the "onchange" event (<select> is).

Checkboxes *do* have an onchange event, it's in the HTML 4 specification.

<URL:http://www.w3.org/TR/html4/interact/forms.html#edef-INPUT>

Implementations vary - IE doesn't fire the event until the checkbox
loses focus (as per the spec but unintuitive), Firefox /et al/ fire the
event when the checkbox is checked (essentially making it an onclick
event) which is not what the spec says to do but is more intuitive.

[...]

 

[Thomas 'PointedEars' Lahn]

Checkboxes *do* have an onchange event,

There is no `onchange' event. There is a `change' event, and an
intrinsic `onchange' event handler.

it's in the HTML 4 specification.

<URL:http://www.w3.org/TR/html4/interact/forms.html#edef-INPUT>

The relevant specifications here are W3C DOM Level 2+ Events:

<http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents>
<http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-eventgroupings-htmlevents>


PointedEars

 

[RobG]

RobG wrote:




There is no `onchange' event. There is a `change' event, and an
intrinsic `onchange' event handler.

OK, I was not spot-on with my terminology. :-x

The link I quoted is to the definition for input elements, of which
'checkbox' is a type. It shows that they have an onchange attribute,
the content of which is 'script'.

I really didn't know what to make of 'EventProducer of the "onchange"
event'.

The relevant specifications here are W3C DOM Level 2+ Events:

<http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents>
<http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-eventgroupings-htmlevents>

You can go to the event spec and see what elements they apply to, or
look at the elements to see what attributes they have to find out what
events they support. Six of one, half a dozen of the other to me, but
thanks for the extras.

 

[VK]

My bad!

Microsoft indeed has "onchange" handled supported for <checkbox>
elements despite it's not documented and not listed on MSDN:
<http://msdn.microsoft.com/library/d...or/dhtml/reference/objects/input_checkbox.asp>


But programmed state switch seems doesn't trig the event neither in IE
nor in FF. An attempt to sent such event "manually" leads to access
violation error in FF.

If we follow the old Netscape Gold scheme (the only one really we
should follow in forms the OP problem can be solved very easy by:
....
<input type="checkbox" name="check001" value="checkbox"
onclick="someAction(this)">
....

and:
....
myCheckboxes.click();
....

If it has to be the 'change' event and nothing else, then the solution
(if it exists) is not known to me.

 

[Thomas 'PointedEars' Lahn]

You can go to the event spec and see what elements they apply to, or
look at the elements to see what attributes they have to find out what
events they support.

Not necessarily. It is conceivable that an event is handled by an object
without having the respective element an appropriate intrinsic event
handler attribute. One reason is a DOM that is ahead of markup in this
regard (of which examples exist in Valid HTML), another that the event
may bubble up to an object that handles the event and the element its
represented by has the required event handler attribute.

Six of one, half a dozen of the other to me, but thanks for the
extras.

You're welcome


PointedEars

 

[Richard Cornford]

Why not just do it in one step:

checkboxes.checked = true;
someOtherActionWith(checkboxes);

Well, that's the way I'm proceeding right now, while I was waiting for
a possible better solution but, as nobody seems to be really inspired,
I guess there are none.

Also this post was, I admit, a bit oriented towards a more
general "Can someone tell/teach me about 'simulated' events?"

If you are using intrinsic events (the onchange property of the INPUT
element or the corresponding onchange attribute in the HTML) rather than
the DOM addEventListener or IE attachEvent methods, and you do not use
(or need to use) the event objet itself in the event handlers, then you
probably don't need to worry about simulating events. You can just
explicitly call the INPUT element's onchange handler after you set the
checked property:-

checkbox.checked = true;
checkbox.onchange(); //<-- explicitly call the handler.

Or test the state of the checked property prior to assignment and only
call the handler if you are changing the property.

/* In comparison the left-hand side is evaluated first
(so before the assignment in the right hand side
expression):-
*/
if(checkboxe.checked != (checkbox.checked = ture)){
checkbox.onchange(); //<-- explicitly call the handler if changed
}

(I honestly though programmatically checking a checkbox would
trigger it's onchange handler)

The first thing that needs saying is that you should not expect an
onchange event to fire on a chackbox or radio button even if it is
checked/unchecked by the user. The specifications say that an onchange
event is fired when the _value_ of a form control changes, and setting a
radio/checkbox checked/unchecked does not alter the _value_ of that
control. Implementations vary, but if you try to use onchange with a
checkbox or radio control you are already in the area of unreliable
outcomes.

Generally no event handlers are fired when scripted actions trigger
behaviour that would have fired events if the user triggered them. So,
if you submit a form by calling the form's submit method the onsubmit
handler of the form is not called. This may seem unhelpful but it is
quite reasonable. The event handlers allow scripts to notice that events
happen and react to them. If the script itself is triggering the action
then it doesn't need to be told that the action is happening, it already
knows. And if calling the event handler is the most sensible reaction
then it is (or can be) in a position to do that. For example, if a
script wanted to submit a form conditionally upon the return value of
the form's onsubmit handler it can do:-

if(formRef.onsubmit()){ //<-- explicitly call the onsubmit handler
formRef.submit(); //<-- submit the form if it returned true.
}

- and if the onsubmit handler returns false the form will not be
submitted. Of course the onsubmit handler has to explicitly return true
if the form should be submitted, but the author of the code knows that
and so will ensure that it happens.

Richard.

 

[aundro]

The first thing that needs saying is that you should not expect an
onchange event to fire on a chackbox or radio button even if it is
checked/unchecked by the user. The specifications say that an onchange
event is fired when the _value_ of a form control changes, and setting a
radio/checkbox checked/unchecked does not alter the _value_ of that
control. Implementations vary, but if you try to use onchange with a
checkbox or radio control you are already in the area of unreliable
outcomes.

Good to know (that is: to be remembered; as I must have read that some
time ago, but couldn't remember it).

Generally no event handlers are fired when scripted actions trigger
behaviour that would have fired events if the user triggered them. So,
if you submit a form by calling the form's submit method the onsubmit
handler of the form is not called. This may seem unhelpful but it is
quite reasonable. The event handlers allow scripts to notice that events
happen and react to them. If the script itself is triggering the action
then it doesn't need to be told that the action is happening, it already
knows.

Well, after all, that makes perfect sense

Richard.

Thank you very much,

Arnaud

 

[aundro]

As I said your question as posted was "How to trig an event from an
element if such element is not native EventProducer of the event in
question?".

Checkbox is not EventProducer of the "onchange" event (<select> is).
Theoretically you can create any artificial event using
document.createEvent (Gesko) and document.cretateEventObject (IE)
methods.

Yes, but I didn't feel like doing so. I don't need any event property
anyway, so there's no point in faking one.

But trying to dispatch artificial event to an element in
violation of its EventProducer model *seems* to lead to the security
exeption and script abort in FireFox.

Heh, I suppose mimicking the event model is at your own risks. (I
haven't read much about that in the case of browsers, but I know when
one has to use such practices, most of the time there's something
wrong in the whole design)

Thank you!

Arnaud