Slider Bar Events - Best Practice?

[DailyDose]

Hello everyone.  Per customer request, I am implementing a slider bar that changes the attenuation at will.  However... this has proven slightly trickier than I thought it would.

Ideally, changing the value of the slider would trigger an event that queues the device to change the attenuation to the slider's current value.  However, sliding the bar causes a ton of events and sending this many messages to the device seems to cause it to hang up.  So I thought I'd implement a "Mouse Up" event.  Seems to be a solid solution except that with the slider, you'll never get the value exactly what you want.  So then you could change the value of the slider manually by typing it in, but then this does not trigger an event.  I thought about maybe introducing a "timer" into the event so that a message can't be queued every 50ms or so.  But I typically hate "band-aids" like that and it leaves you in a situation where you could actually not get the value you settle on.  So I was curious if anyone else out there had a solution for this type of thing.  Any thoughts or suggestions?

[Photon_Dan]

I like to handle the sliders by setting a flag (Boolean) in the Value Change event and then "servicing" that changed value in the Timeout case. If the flag is set (True) whenever the Timeout executes, send the message containing the latest slider value and reset the flag (to False). You can control how often the updated value gets transmitted by the Timeout setting on the event structure.

[billko]

To generate less events, you can set the increment property.  Your slider should "snap to" the nearest incremented number, allowing you to more easily control the value.

edit:

[altenbach]

Simply change the event to not lock the panel and have an event queue size of 1.

(And thank me for this idea!) 😄 (other workarounds are in the idea discussion and here for what we did before)

[DailyDose]

---

@Photon_Dan wrote:

I like to handle the sliders by setting a flag (Boolean) in the Value Change event and then "servicing" that changed value in the Timeout case. If the flag is set (True) whenever the Timeout executes, send the message containing the latest slider value and reset the flag (to False). You can control how often the updated value gets transmitted by the Timeout setting on the event structure.

---

So this was something I had considered doing (or similar to) where you are essentially limiting the number of events using time.  But what I find is that you can miss the actual final value because of this.

[DailyDose]

---

@billko wrote:

To generate less events, you can set the increment property.  Your slider should "snap to" the nearest incremented number, allowing you to more easily control the value.

edit:

---

Increment value set to .01 - still triggers quite a few events.

[billko]

Edit:

As usual, Altenbach comes up with the easy solution.

[Photon_Dan]

If you set it up as I described, the Value Change event is just setting the flag, the Timeout case is where the control terminal can be read so it will have the latest (final) value. It executes only if there are no events firing for the <Timeout> amount of time. I use something like 25 or 50 msec.

[DailyDose]

---

@altenbach wrote:

Simply change the event to not lock the panel and have an event queue size of 1.

---

I was able to scroll from 0 to 70 in 2 seconds and triggered 150 events.  Includes time it took me to mouse from play and to click stop.

[altenbach]

---

@DailyDose wrote:
I was able to scroll from 0 to 70 in 2 seconds and triggered 150 events.  Includes time it took me to mouse from play and to click stop.

---

Yes, if the event case is basically empty and can be repeated in nanoseconds. As soon as the event does some actual work, many intermediary changes will be discarded and only the last one kept.