Looks like we can't reproduce the issue or there's a problem in the test case provided.
  1. #1
    Sencha User
    Join Date
    Jun 2007
    Posts
    44
    Vote Rating
    0
    GArrow is on a distinguished road

      0  

    Exclamation Sliders (Single & Multi) fire [before]change[complete] events in setValue

    Sliders (Single & Multi) fire [before]change[complete] events in setValue


    REQUIRED INFORMATION


    Ext version tested:
    • Ext 4.1.0b2

    Browser versions tested against:
    • Firefox 10

    DOCTYPE tested against:
    • html (HTML5)

    Description:
    • The code for handling setValue for a slider triggers change events that are supposed to be associated with user-driven changes rather than programmatic changes.
    • For a slider, the "dragend" event is practically the same as what "change" seems intended to be.
    • For code which handles the "change" event for a variety of fields, this requires a special-case to ignore "change" on the slider and listen to "dragend" instead (and to use getValue() instead of having the new value passed as the second argument).

    Steps to reproduce the problem:
    • Just call setValue() on a slider.

    The result that was expected:
    • No events should be fired.

    The result that occurs instead:
    • Various before/after change events are fired.

    Test Case:

    Code:
        slider.setValue(1);


    HELPFUL INFORMATION

    Possible fix:
    • To fix this in a backward-compatible way, it might be necessary to create a new, abstract/base slider class which does not have this problem. Multi could inherit from it and implement the existing setValue() behavior, while new "BetterMulti" and "BetterSingle" classes provide change events that are more compliant with the behavior of other fields.

  2. #2
    Sencha - Ext JS Dev Team evant's Avatar
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    16,665
    Vote Rating
    586
    evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute

      0  

    Default


    It's intended to work that way, from the docs:

    Fires before the slider value is changed. By returning false from an event handler, you can cancel the event and prevent the slider from changing.
    One might argue that the behaviour itself is incorrect, however both scenarios seem reasonable.
    Evan Trimboli
    Sencha Developer
    Twitter - @evantrimboli
    Don't be afraid of the source code!

  3. #3
    Sencha User
    Join Date
    Jun 2007
    Posts
    44
    Vote Rating
    0
    GArrow is on a distinguished road

      0  

    Default Documentation/Design is broken

    Documentation/Design is broken


    Yes, it is behaving "as documented", but the documentation has been written to describe a "broken" design/implementation that violates the contract of the Ext.form.field.Base class that the slider inherits.

    The Base documentation for the change event says:

    Fires when a user-initiated change is detected in the value of the field.
    The documentation for a slider does indeed change this, ignoring the user-initiated part:

    Fires when the slider value is changed.
    Other fields that inherit this event honor it by firing the event when a user-initiated change is made; but it is avoided/avoidable when the change is made from code -- that is, by simply calling "setValue()" instead of by clicking on the thumb & moving it. If the slider classes needed to have a change-like event which was different, they should have used a different name for it.

    In general, I would think that if code wants to prevent other code from changing the value of a slider (or any other field), it should be using a validation-related function to do that, as other fields do. Maybe it would make sense to have a "validate" event; but it should be separate from "change" -- that is, there is a big difference between "Is this data ok?" and "The user changed this". Specifically, I am not trying to cancel the change & reject the data; but I do want to avoid taking actions that should only happen when a human being fiddles with the UI. (Ext JS itself does this by directly setting internal data fields; but since those aren't documented for application use, that's not a reasonable option.)

    Other fields will fire change through the Ext.form.field.Field mixin, which uses this.suspendCheckChange to control firing the change event. This makes it easy to make programatic changes to values without firing off a lot of incorrect event handlers, which is obviously useful -- particularly when loading up a page of data values. The setRawValue call isn't exactly the same thing; as this isn't about bypassing validation -- it's about avoiding the events that run "when the user does something" when the user isn't actually doing anything.

    One could say that the "bug" here is simply that sliders don't act like other fields & should also use the Field mixin, or else re-implement its behaviors. But in general there need to be ways to set values of fields without triggering code that should run when a user changes the values of fields.

Thread Participants: 1