Slider Control --High Frequency of Event Capture

[alukindo]

Hi:

When a user changes a slider control value from say 1.0 to 5.8 by sliding the control all the way through, the slider control will fire hundreds of events in quick succession all the way along the interval change from 1.0 to 5.8. If you put code handling for these events, LabVIEW becomes unneccesarily too busy.

Is there a way to slow down the frequency of these slider value change events? My current work around is to use a separate loop that fires the value change event only after detecting a lapse of say 0.5 sec from the most recent slider value change.

. . . But I am thinking that there could be another way around this.

Any ideas?

Anthony L.

[Randy81]

Hi Anthony,

Silly question, but is it necessary to detect the value changes while sliding? Or is the final value between transitions sufficient?

Randy

[eaolson]

QUOTE(alukindo @ Aug 31 2007, 11:07 AM)

Is there a way to slow down the frequency of these slider value change events? My current work around is to use a separate loop that fires the value change event only after detecting a lapse of say 0.5 sec from the most recent slider value change.

There's no way that I'm aware of to discard the value change event while the slider is still sliding. I got around this by catching the Value Changed event, the Mouse Down event for a slider, and the Mouse Up event.

1. On the mouse down, put a control reference to the slider in a shift register, and the current value in another shift register.

2. In the mouse up case (which is not specific to a particular control), check the reference and if it is valid, fire the value changed event using the Value (Signaling) property. Also invalidate the control ref in the shift register.

3. In the value changed event, check the value of the control reference in the shift register. If it's valid, the mouse is still down and do nothing. If it's invalid, the slider is no longer moving and handle the event.

[orko]

Another way of doing this is to put a case structure outside of your event structure that handles the waiting for the mouse up if the slider has been clicked on. Of course, it depends if you have other events you want to trap while you are sliding (this won't work in that case).

http://forums.lavag.org/index.php?act=attach&type=post&id=6820

http://forums.lavag.org/index.php?act=attach&type=post&id=6821 (LV8.2.1)

[B Chavez]

QUOTE(orko @ Aug 31 2007, 12:10 PM)

Another way of doing this is to put a case structure outside of your event structure that handles the waiting for the mouse up if the slider has been clicked on. Of course, it depends if you have other events you want to trap while you are sliding (this won't work in that case).

http://forums.lavag.org/index.php?act=attach&type=post&id=6820

http://forums.lavag.org/index.php?act=attach&type=post&id=6821 (LV8.2.1)

http://forums.lavag.org/index.php?act=attach&type=post&id=6822 (LV8.2.1 - w/throttle)

EDIT: I've added another VI that uses a timeout to throttle the value changes. Try playing with the timeout value in the case structure and watch the "Loop Count" while changing the slider.

My front panel activity gets locked out for some reason. It seems to happen when I click just below the slider, on the scale. I tried un-checking the "Lock front panel until the event case for this event completes" box, but it still happens. Anyone else seeing this behavior.

[BobHamburger]

Most of the time, the action that would be desired while adjusting the slider is a steady (but finite) stream of value updates. Presumably the user is moving the control while observing the results in his system, and wants to see continuous control actions. The mouse down/mouse up routine previously described wouldn't provide this kind of control action.

Face it folks: some times polling is the right way to handle GUI servicing. It's certainly the simplest in this situation. Use the timeout on the event structure so that the current value of the slider is captured every 100 - 200 mSec, and be done with it.

[orko]

QUOTE(BobHamburger @ Aug 31 2007, 12:50 PM)

Face it folks: some times polling is the right way to handle GUI servicing. It's certainly the simplest in this situation. Use the timeout on the event structure so that the current value of the slider is captured every 100 - 200 mSec, and be done with it.

I agree with this and it was my original thought when reading the post. Mine was only an alternate suggestion that worked without polling, as alukindo seemed to be after. It probably isn't the best suggestion now that I'm looking at it (since someone already found a bug in it ).

Ah well, just another way to skin the feline.

[Val Brown]

QUOTE(orko @ Aug 31 2007, 01:47 PM)

I agree with this and it was my original thought when reading the post. Mine was only an alternate suggestion that worked without polling, as alukindo seemed to be after. It probably isn't the best suggestion now that I'm looking at it (since someone already found a bug in it ).

Ah well, just another way to skin the feline.

And to keep seeing how the skinning is progressing as it is happening...

[orko]

QUOTE(Val Brown @ Aug 31 2007, 01:55 PM)

And to keep seeing how the...

Eeeeeeewwww! http://forums.lavag.org/index.php?act=attach&type=post&id=6823''>http://forums.lavag.org/index.php?act=attach&type=post&id=6823'>http://forums.lavag.org/index.php?act=attach&type=post&id=6823

[jzoller]

Another simple method is to grab a timestamp whenever the value change event fires, and toss it into a shift register. The next time the event fires, if the new timestamp isn't greater than the old timestamp plus some delay (100ms, for instance), just route the event into an empty case statement and do nothing else. It will waste some cycles, but, for user interfaces, that is usually invisible.

For reference, if you tinker with the slider event change, you can measure how fast LV grabs events. On my computer in a simple test VI, LV can grab a timestamp every 15-16ms, but it fires value change events about twice that fast.

Joe Z.

[Yair]

Here are two efficient methods:

http://forums.lavag.org/index.php?act=attach&type=post&id=6827

The value change event in the bottom loop sets the timeout to something (let's say 50 ms). When the last event happens, the timeout expires and you can execute your code.

The top one relies on the terminal having the updated value immediately.

[jdunham]

Here is a simple solution. The main issue is that the GUI goes dead during the waits, so the slider is not even repainted as you move the mouse. If you set the wait time above 250 you can see that the behavior is really unacceptable, but for values of 50-100, it's totally fine.

The subtletly is that you can't use the NewVal from the Event Structure because that will usually be stale by the time your wait finishes.

http://forums.lavag.org/index.php?act=attach&type=post&id=6834

I generally shy away from handling mouse up/ mouse leave events because there are many cases in which they don't really behave the way you would like, as orko found out with his example.

Jason

[orko]

:thumbup: Simple is good.

QUOTE(jdunham @ Sep 3 2007, 01:37 AM)

The subtletly is that you can't use the NewVal from the Event Structure because that will usually be stale by the time your wait finishes.

If you put the timeout constant inside the sequence and the wait primative on the output you won't have the "stale" newval issue.

http://forums.lavag.org/index.php?act=attach&type=post&id=6836''>http://forums.lavag.org/index.php?act=attach&type=post&id=6836'>http://forums.lavag.org/index.php?act=attach&type=post&id=6836

[Yair]

QUOTE(jdunham @ Sep 3 2007, 11:37 AM)

Here is a simple solution. The main issue is that the GUI goes dead during the waits, so the slider is not even repainted as you move the mouse. If you set the wait time above 250 you can see that the behavior is really unacceptable, but for values of 50-100, it's totally fine.

http://forums.lavag.org/index.php?act=attach&type=post&id=6834''>http://forums.lavag.org/index.php?act=attach&type=post&id=6834'>http://forums.lavag.org/index.php?act=attach&type=post&id=6834

I'm sorry, but I don't see how this can be used. As mentioned in the original post, you can get hundreds of Value Change events from a simple move of the slide. In your example, if you get a hundred events, it would take 5 seconds before the code finishes executing for all the values which are mid-way, when usually only the last value is needed. That was the point demonstrated in my two methods.

[jdunham]

QUOTE(yen @ Sep 3 2007, 12:06 PM)

I'm sorry, but I don't see how this can be used. As mentioned in the original post, you can get hundreds of Value Change events from a simple move of the slide. In your example, if you get a hundred events, it would take 5 seconds before the code finishes executing for all the values which are mid-way, when usually only the last value is needed. That was the point demonstrated in my two methods.

Well I built it before posting and ran it and it worked great, so I just don't know what to tell you.

I looked in the LabVIEW manuals and didn't see any direct information on why this works, but I have to assume that the NI developers either knew in advance that it would be useless to stack up events for a slider control, or else they did it wrong the first time and it was fixed in an early LabVIEW 6 beta. The slider control would probably be unusable if moving its slider generated thousands of events and they were allowed to accumulate.

I was a little surprised that orko's last suggestion also worked. I thought it would miss the last update, but it never does. That means that the sequence frame is not needed at all.

What you can't really do is know that the slider is still in motion and only run the event case one time when the mouse up has occurred. I don't think that's possible, since there is no safe way to trap the mouse up event.

Jason

[Yair]

Sorry, I probably should have tested it before I said that.

I did run things like this in the past, however, and I definitely got a lot of events. I think the reason is probably the UI locking - it seems that when the UI is locked, you can move a lot without generating events. When the UI is unlocked, you get hundreds of events.