Make change event always fire as the user interacts with the knob

[amuino]

That is, when using:

• touch
• wheel
• typing (by binding to the "input" event)

Previously, typing did not update the knob until focus was lost (and
no change event was fired), and
using the keyboard arrows did not fire any change events.

Also move event triggering to val() and change() so it works always
in the same way and less duplication exists.

Similar to #130 but fixes an issue with diplayPrevious

[aterrien]

Thank you amuino !

[ACXgit]

Hi amuino, after this merge I started to experiment troubles in my application. After a long investigation I found that this new behaviour introduces a sort of... loop. I use:

$('.dial').val(27).trigger('change');

to set the value, as the documentation tells. I cycle that in a setInterval to animate the knob, used as a playback progress of an audio player. The problem is that, since this version, change the value also means to execute the change hook functions (correct me if I'm wrong). This was not happening before, as I used the change event to do a clearInterval when the knob was clicked/touched. Now it executes the clearInterval at the first cycle of setInterval, and my playback progress knob is not working anymore :)
Can I avoid this issue with a workaround?

[amuino]

@ACXgit that is the kind of inconsistencies that I wanted to avoid… so we kind of need opposite things!

Anyway, I think you can workaround it on your event handlers by using some flag. Something like…

setInterval(function() { 
  $('.dial').data('mute', true).val(27).trigger('change').data('mute', false);
}

... and then on the event handler ...

function handler() {
  if ($('.dial').data('mute') == true) return;
  // standard handling
}

(I've written that from memory, so there might be errors and better options for your specific code)

[ACXgit]

Thank you for the suggested workaround, but sadly it does not work in my case, because I need change event to not interfere with the whole setInterval cycle: playback progress must advance setting the value step by step with setInterval and be stopped ONLY when users click/touch on the knob. I appreciate the need to avoid inconsistencies, but at least give the possibility to set knob's value and manage the change event independently in some way, or it may be impossible to manage cases like mine.

I also noticed a possibly worse issue after this merge: I can't see the numeric indicator change while dragging the knob with the mouse. The value changes only when I release the mouse. In previous versions that wasn't the default behaviour (the value was changing in real time).
If confirmed, this is an usability issue, because it forces the user to guess the exact desired value in a a trial-and-error approach. Please revert the behaviour to the previous standard.

[aterrien]

Afraid to affect everyone :)

[robertc]

This got reverted? Any chance it can be added again? Not having the change event fire for changes with mousewheel is quite annoying.