Is this a weird question?
The current onChange implementation is good for showing the current position/value of the slider as the user is moving it. This helps the user stop on the correct position. However, I would think that in most use cases we would want the ability to also trigger something when the user has actually settled on (selected) a value. Especially since many of us make heavy use of Ajax, we wouldn't want every intermediate value sent to the server.
Am I alone here or am I missing something obvious?

Thanks

Looking at the code, it doesnt appear to be an cut and dry change to implement... you have to take into account A11y (keyboard nav) and people that click randomly on the bar to get where they are going... How do you determine "onStopChanging" (obligatory made up name to discuss :P) with all of those?

-Karl

Thanks for checking into it Karl.
I agree that 'click' feature (vs slide) makes it a little more complicated. I think an appropriate name for the event I am trying simulate would be 'onSelect'. I think that would cover both cases...
a) When the user is sliding and stops and releases the mouse button.
b) When the user clicks on the slider bar to have the slider jump to that location.

I often overlook the details, so correct me if I'm wrong, but my thinking is that both an onClick on the slider bar as well as an onClick (or onMouseUp?) on the slider handle should constitute and onSelect.
In other words...

a) If the user clicks on the slider bar, onSelect would be triggered.
b) If the user slides the handle (by clicking and holding mouse button down) to the position he wants and releases (mouseUp) this would also trigger onSelect.
c) As for A11y, I guess the same thing, only use keyUp.

I think in these cases, it is a reasonable assumption that the user is where he wants to be and expects the appropriate action to be triggered. I know some users will click on the slider bar repeatedly to get where they want, but that's just something I would have to deal with... user would learn eventually if the corresponding action takes too long.

What do you think? Any trick I could use to implement this (given the issues I mentioned in my first post)?

Thanks

Unfortunately, I can't seem to connect to any of the events except for sliderHandle.onClick. Unless maybe I'm just not referencing the right node(s)... but I've tried everything I can think of. Anyway, thanks for the suggestion and I'll go ahead add the enhancement ticket in Trac.

I came across the same limitation, I use the onChange to fire an XHR request. With a slider containing lots of values each onChange would be an XHR request, that would be cancelled by the next request (onChange), and eventually the last XHR request to sometimes fail (50% of the time).

The work around I have is to delay the action that causes the XHR request in such a way that the user does not notice and the form is still responsive. Code is simple:

if (jobViewSliderBufferTimer) {
    clearTimeout(jobViewSliderBufferTimer); //set new timeout
}
			
jobViewSliderBufferTimer = setTimeout("jobViewGridLoad()", 250); 
//eventually, after 250ms of no further timeouts, the grid load is called.

Hi Trule,
Thanks for posting the workaround. I haven't been back to re-visit this problem since I first posted this (I just found a way to avoid the slider for the time being), but I hope to attempt to implement it again sometime soon.
I also just noticed that they closed the bug ticket I submitted. Looks like they have another solution as well...

http://trac.dojotoolkit.org/ticket/4958#preview