I guess you could have raise() call update() or have it explicitly fire a change event. As for understanding the “why not?”, maybe its a “bubble up” vs. “bubble down” thing?
The reason that the change event doesn’t fire on a scripted update to the field, is that the change event only automatically fires on user interaction.
The onchange event occurs when a control loses the input focus and its value has been modified since gaining focus.
I believe that some web browsers used to trigger the onchange event when a script made a change to an element, but if that onchange triggered another change to the same element, endless loops were easy to get in to, and hard to get out of.
If you instead use the standard event declarations for the elements:
Thanks for the explanation Paul.
I’m going for the eventlistener approach thouhg, so I can have multiple functions triggered by one event if necessary.
That’s the problem with using the eventlistener technique. Web browsers don’t have as much access to it as they do with the standard event techniques, so you’ll need to double-up on the calls to the update function while you continue to use eventlistener.