Jump to content

Slider Control --High Frequency of Event Capture


alukindo

Recommended Posts

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. :o

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. :book:

Any ideas?

Anthony L.

Link to comment

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.

Link to comment

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)

Link to comment

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

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.

Link to comment

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.

Link to comment

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 :o ).

Ah well, just another way to skin the feline. :D

Link to comment

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 :o ).

Ah well, just another way to skin the feline. :D

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

Link to comment

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.

Link to comment

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

Link to comment

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

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.

Link to comment

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

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.