Improved Value Change Options On Sliders

[James_McN]

When a user clicks and drags a slider - hundreds of value change events are generated for your code to handle.

Most of the time the user experience you want is just to use the value when the user has stopped dragging the slider. Similar to a text input field where you can select to have the value update only once the user has finished typing instead of all the intermediate values.

My proposal is to change the slider events to support this use case. I'm inclined to leave the exact solution open - as long as NI can support this use case.

There is another idea to add an ended event which would allow for this: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Create-a-quot-User-Control-Ended-quot-Event/idi-p/107... but I created this post to be more specific.

You can find a number of attempts if you search the forums for "slider too many update events" such as 

• https://forums.ni.com/t5/LabVIEW/Slider-control-generates-too-many-quot-value-change-quot-events/td-...
• http://www.ni.com/example/29032/en/
• https://forums.ni.com/t5/LabVIEW/DBL-Slider-prevent-update-until-done-sliding/td-p/3705848/page/3?pr...
• https://forums.ni.com/t5/LabVIEW/slider-value-change-event/td-p/802590

If you follow this through there are always compromises in every solution for getting this behaviour.

[Intaris]

Wouldn't this be a candidate for the setting "Synchronous Display", but for controls?

[drjdpowell]

Doesn't limiting the events in the queue to one effectively limit the problem?

[wiebe@CARYA]

>Doesn't limiting the events in the queue to one effectively limit the problem?

It does prevent 'processing lag' while changing the value.

It would still be nice to know when the user is done (releases the mouse). Mouse up doesn't work, as this doesn't fire if the mouse is moved from the control while changing the value. We could really use a 'lost capture' event on this and other controls.

[REAL!]

Just having this issue, spooky... 

@drjdpowell In one of the threads in the forums that is suggested as a solution, but not deemed "bullet proof".

[AristosQueue (NI)]

> Wouldn't this be a candidate for the setting "Synchronous Display", but for controls?

It would be the equivalent of turning *off* "Update value while typing", a feature that exists on string controls. The current behavior could be termed "update value while dragging". This would provide an option to turn that off.

[wiebe@CARYA]

>It would be the equivalent of turning *off* "Update value while typing", a feature that exists on string controls.

That would have been very helpful in past situations.

[drjdpowell]

>@drjdpowell In one of the threads in the forums that is suggested as a solution, but not deemed "bullet proof".

Does a "bullet proof" option exist?   Note that any digital control (including the optional digital display on the slider) can trigger large numbers of events if the User uses the mouse wheel on it.  Or just clicks things really fast.  No way to tell when they're finished messing with things.

I use a structure such as illustrated here to be robust against a flood of events:

Here I use a feedback node from a "default if unwired" tunnel to use the Timeout case as an "event queue empty" case.  I use one or more flags (such as the "Update Display" boolean above) to allow other event cases to signal that a slow update is needed, with the update happening only after all events are handled.  This setup will be robust against a User rapidly clicking on multiple controls, and works with User Events too.