Add an event type like html's `change` event?

[AmaiKinono]

The change event we have for now seems to be more close to the input event in html. This MDN doc explains the difference between input and change:

The input event is fired every time the value of the element changes. This is unlike the change event, which only fires when the value is committed, such as by pressing the enter key or selecting a value from a list of options.

This describes when is change event fired.

I'm thinking whether we should have an event type like change in html, which is useful at times, e.g., to normalize user input, to record an undo checkpoint, etc.

For range sliders, I think (in html) the input event is fired during dragging, and change is fired upon releasing the mouse.

[mikke89]

Yeah, I agree. Ideally, we would use the same behavior as in HTML, add a new input event for the current behavior, and make change only trigger when committing the value.

I would also add to this that we should only emit any of these events when the user initiates the change, not when changing it programmatically. I believe that is how HTML behaves, and it might also solve some binding loops like in #701, and events being emitted upon initially setting the values.

This would be a breaking change though. Although, I'm not sure how bad of a breaking change it would be, maybe in many/most causes it would still work fine. Needs some testing I think to understand the implications. It might be we'll have to wait to merge it until the next major version change.

[AmaiKinono]

we should only emit any of these events when the user initiates the change, not when changing it programmatically.

I'm looking into this, as it seems to be better done before we add the HTML change event (for now I think we could have a name like changeend. We can rename it in the next major release).

I plan to change Core/Elements/ElementFormControl.h:

• Add a second argument to the virtual method SetValue which is a flag of whether the change comes from the user, and it can have a default value of false.
• Change SetValue implementations of specific form controls, and modify its call sites when suitable.

Does this look reasonable to you?

[mikke89]

Yeah, it generally sounds reasonable to me.

I do wonder though if, or to what extent, the emit only on user interaction is a breaking change.

Minor design input: I would prefer a strong enum over a bool. Also, I think it's not ideal to have virtual functions with defaulted parameters. Consider using a protected virtual "impl" function with no defaults, and a public one with the default parameter. Not sure if we actually need to publicly expose the second parameter to users though?