LabVIEW
DBL Slider - prevent update until done sliding
Search LabVIEW like a graph! doesn't work ..
also including vi mouse leave event updates immediately before releasing mouse...
In the specific case of a value change on a slider, I would suggest this:
This works because the terminal always has the current value and will both discard old events and guarantee you get the last event correctly.
In the case of window resizing mentioned here, you can compare the old and new bounds, because LV throws an extra event when the resizing stops.
tst wroteIn the case of window resizing mentioned here, you can compare the old and new bounds, because LV throws an extra event when the resizing stops.
Except when minimizing, maximizing or restoring. So you need to check that too. Another one of those things... (Don't recall window resizing being mentioned here?)
Checking the value seems like an elegant solution if not the solution.
I guess there are now three workable solutions:
1) limit events
2) check new value with control value
3) use flush events (haven't checked that)
The mouse enter\up etc. scheme seems way to complicated to get fully working if that's even possible.
This might be something for the idea exchange (haven't checked). I've been in the same situation. But the first (to be avoided) question will be: when are you done sliding? When you pause? For how long? When you release the mouse? You can also move with the keyboard. So (also) when you lose focus? Or after each move?
"... until done sliding" is a tricky requirement, because sometimes the user might stay on the slider and pause to see the recalculated result based on the current value. ("cursor move" events require similar precautions)
All this has been solved by limiting the event queue to 1 as has already been mentioned by others. For a deeper discussion and background information, have a look at this idea for the reason we have this checkbox. Also follow the various links (e.g. this one) for illustrative old examples. (These are my quotes from this old related discussion).
It is also important not to lock the front panel until the event completes. so the slide can be moved freely and does not get hung up by the executing event.
Limiting the event queue to 1 has exactly the same effect as the workaround code posted by tst above, so there is no longer any need for that.
+1 for limiting the events to one. That's how I've done it since that feature was added. The problem with tst's example is with a double (having many digits of precision) you will likely still generate an event with every pixel move of the mouse since the slider will change by an ever so small amount.
The other technique I used before the event structure had a way to limit the number, would be to set a flag to handle the new values event, but then handle it in the timeout case of the event structure and clear the flag once handled. This way I might get 100 events on the value change, but will only process them once I go into the timeout case. Attached is that demo but again I don't use this technique anymore now that the event structure does what I want.
I think checking the new value has a slightly different result, while solving the same kind of problems. It will trigger the case only when you stop moving. I think a wait in the event is needed, or you'll still get a ton of events. The limit on the event will basically fire continuously while values keep changing.
For ease of use, I'd prefer the limit event solution. But in some cases, checking the value might be an addition to it. A code comment as of why the check is needed will be in place, because my first thought would be to replace it with a limit.
Similar to Brian's second suggestion, I do any massive recalculation in the timeout case, but just keep the timeout value in a shift register. I set the timeout to zero or a small value in all event cases that require recalculation and indicator updates. In the timeout event, the timeout is reset to infinite.
If a slide is moved fast, the timeout only triggers once things quiet down. (I still set the event queue to 1 and don't lock.)
Of course really slow recalculations are handled in a second loop to keep the UI responsive.
