Horizontal Slider Event Problems

[Tinman265]

What I am trying to do is pretty straight forward.  I have a simple horizontal Slider.  Integer Values. 0 to 100.  I simply need to know if it the user changed it up or down.

There are 2 ways a user could do this with a slider.

1.  Click on the slider tab and drag it to a new value. (Note they could slide it back and forth several times before deciding when to let go of the slider.  I need to know if the value is above or below the value they had before clicking on the slider.)

2.  they simply could click to the left or the right on the slider bar and "jump" to a new value. Not using the slider tab at all.

This is about program proofing the UI.  I want the program to work no matter what the user does.

Further detail: A sound file is played if the sider went up and a different sound file is played if the slider went down.  Also if the value has not changed then no sound file should play.  I send the sound file to a queue that is played in another loop. 

The value change event does not work since it generates effectively infinite events for every change. The Mouse Down or Up does not work since the New Value or Old Value is not available. and it captures all mouse clicks on the control.  Not just the slider or the slider bar.  that causes a lot of bugs with workarounds.

There has to be a way to do this.  The work arounds are so insane and buggy its not worth even adding to the post.  I basically need a combination of the Mouse Up events and the value changed events.  

Summary:  I simply need a user proof way of capturing the event of a click on a slider and knowing if the final value is greater, less than, or the same as the previous value before the clicked on it.  No matter how they click on the slider.  It cant generate an event if they click on the scale.  It needs to fire the correct event if they click and drag the slider up down, pause, up , up again, etc.  No matter what they do after they let go that value and only that value should be compared to the value of the slider before they clicked on it.  I am really stunned this is so difficult.  

[raphschru · Accepted solution]

Hi,

This is indeed difficult because Slides are normally designed to trigger events while it updates, and there is no "Update Value while Sliding" option that can be unckecked, similar to "Update Value while Typing" option for Strings, sadly...

Moreover, there is no convenient "Mouse Up" event that fires even when the user released the mouse button outside the VI window.

So here is how I would do:

1. On value change, set a flag to true and retain the "Old Value". Use the flag to only do that on the first value change event, not on subsequent ones:

2. On Timeout (here I set a resolution of 50ms), check that the sliding is still occurring. If it is not (left/middle buttons are released), trigger your custom action. Finally reset your flag:

Regards,

Raphaël.

[Tinman265]

Thanks!  That does seem to work.  I have done a lot of similar things but this seems to be more robust.  

Whats strange is this was not a problem way back in LabView 7.1 or thereabouts. It just worked.  At some point it stopped and its been a pain ever since.  Thank you so much!

[raphschru]

I am glad that helped.

Don't forget to "Accept As Solution" if it solved your issue. In this way, other people can look at this thread and jump directly at the solution.

Also, Kudos are the primary way of saying "thanks" to someone who helped you on the forum.

Regards,

Raphaël.

[Bob_Schor]

Well, here is another way that seems to do exactly what you want.  There are two events you need to "capture".  One is when the Slide value changes -- well, that's simple, you have a Slide Value-Change Event, and save the Slide Value in a Shift Register on the surrounding While Loop (being sure to carry the value through the other Cases).

The "other Case", of course, is a Slide "Mouse Up" Event, which you want to mean "I'm done manipulating the Slide, now I want its most recent value".  You do this by simply stopping the Event Loop by wiring "True" to the Stop indicator of the surrounding While Loop, and taking the output from the Shift Register (which is the last changed value of the Slider).

Here is a Snippet, showing the Mouse Up case.  The other case is the Slider Value Change case that sets the "changed" Slider Value into the Shift Register.

For this to work, you must manipulate the Slider (which you do by clicking on it with your mouse, a Mouse Down Event, and unless you want to keep your finger on the slider all day, you must also (eventually) do a Mouse Up, setting the Slider value.

Hmm -- there may be a bug, but I can envision a fix.  It's late, and my eyes are getting bleary, so I can't test it now.  But what happens if the slider is not at 0, you click, but don't move the slider before letting go.  Do you get the loop to stop, and does it have the right "Mouse-down" value?  

Bob Schor

[paul_a_cardinale]

---

@Bob_Schor wrote:

Well, here is another way that seems to do exactly what you want.  There are two events you need to "capture".  One is when the Slide value changes -- well, that's simple, you have a Slide Value-Change Event, and save the Slide Value in a Shift Register on the surrounding While Loop (being sure to carry the value through the other Cases).

The "other Case", of course, is a Slide "Mouse Up" Event, which you want to mean "I'm done manipulating the Slide, now I want its most recent value".  You do this by simply stopping the Event Loop by wiring "True" to the Stop indicator of the surrounding While Loop, and taking the output from the Shift Register (which is the last changed value of the Slider).

Here is a Snippet, showing the Mouse Up case.  The other case is the Slider Value Change case that sets the "changed" Slider Value into the Shift Register.

For this to work, you must manipulate the Slider (which you do by clicking on it with your mouse, a Mouse Down Event, and unless you want to keep your finger on the slider all day, you must also (eventually) do a Mouse Up, setting the Slider value.

Hmm -- there may be a bug, but I can envision a fix.  It's late, and my eyes are getting bleary, so I can't test it now.  But what happens if the slider is not at 0, you click, but don't move the slider before letting go.  Do you get the loop to stop, and does it have the right "Mouse-down" value?  

Bob Schor

---

The problem with that is if the user moves the mouse pointer off the slider before releasing the mouse, there will be no "Mouse Up" event on the slider.

[paul_a_cardinale]

I think this will work.

Interesting side note: I can't  make a proper snippet from this VI. It always leaves out the VI Server Reference.

[raphschru]

---

@paul_a_cardinale wrote:

I think this will work.

---

Not if the user releases the mouse out of the VI window, which is why I opted for the Timeout / "Input Device Control" VIs solution.

Also in your example, the event "Pane.MouseUp" can be registered statically.

---

@paul_a_cardinale wrote:

Interesting side note: I can't  make a proper snippet from this VI. It always leaves out the VI Server Reference.

---

It seems like all links to pure layout elements (Pane, Splitter, SubPanel) are not captured in the snippets (references, static prop nodes, static invoke nodes, static events, ... are either removed or disconnected).

[altenbach]

Here's what I might do... Seems significantly simpler than most of the other suggestions so far.

It shows the relative movement during operation and the final relative movement once complete.

(Also, since the indicator is initially not in the dataflow, the VI is set to clear indicators when called).

The event queue for slides should always be limited to 1. Some of the reasons are described in this completed idea.

[raphschru]

---

@altenbach wrote:

Here's what I might do... Seems significantly simpler than most of the other suggestions so far.

It shows the relative movement during operation and the final relative movement once complete.

---

The objective was to have only one event when the user releases the mouse after sliding, since the OP wants to play the sound only once.

In your example, it fires events continuously.