LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DBL Slider - prevent update until done sliding

hi 

creating mouse up event for both slide and pane is working well(both in same event). It updates even if user release mouse outside control. 

bp
0 Kudos
Message 21 of 30
(2,197 Views)

Expect when the mouse is released outside the pane...

0 Kudos
Message 22 of 30
(2,188 Views)

doesn't work ..Smiley Indifferent also including vi mouse leave event updates immediately before releasing mouse...

bp
0 Kudos
Message 23 of 30
(2,185 Views)

Hi DD,

Here's a VI that does, essentially, what RavensFan and wiebe suggested (though, no purging of event-queue).

 

Hope it helps!

0 Kudos
Message 24 of 30
(2,168 Views)

In the specific case of a value change on a slider, I would suggest this:

 

Compare%20slide

 

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.

 

 


___________________
Try to take over the world!
Message 25 of 30
(2,144 Views)

tst wrote

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.


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?

0 Kudos
Message 26 of 30
(2,139 Views)

"... 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.

0 Kudos
Message 27 of 30
(2,113 Views)

+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.

 

Event Timeout Slider_BD.png

0 Kudos
Message 28 of 30
(2,099 Views)

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.

0 Kudos
Message 29 of 30
(2,091 Views)

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.

Message 30 of 30
(2,081 Views)