Labview slider event handling problems - revisited

[WNM]

This topic asked a question that was very close to a problem I am having:

Labview slider event handling problems

That is, how do I, using an event structure and/or other means, only read out the value of a slider control after the value change is finalized?

The extra constraint I'd like to place on this, which I believe will invalidate the answer given in the thread above, is that my slider control also has a digital display which can also be used to change the value without ever using the mouse. I cannot look for a value change followed by a mouse-up event if the mouse was not used to change the value.

Any ideas how this might be accomplished? FWIW, I am using LabVIEW 7.0

[altenbach]

You have a few possible solutions, you just need to program around it or adjust your requirements.

(1) Don't use any event for the slider, but pair it with a "send" boolean button. Do a "value change" event on the send button, and place the slider inside that event case.
(2) Monitor the values and only send it if it hasn't changed for another two seconds.
(3) ...

[WNM]

OK, I just couldn't let this rest. First of all I have requested that NI consider adding at some future date the ability to set, either for the event structure or the slider control, when the value of the control is reported out as its slider is being dragged along. There are good reasons for retaining its current behavior and good reasons for allowing it to have the proposed behavior (value is reported only at the end of a move).

Anyway that didn't do me any good for now so I dug a bit deeper and came up with the attached solution (LV 7.0)

Thanks to Vitalijus for the initial VI demonstrating the problem.

[WNM]

Here is a slightly modified version of the same pair of VI's.

It includes a bit more documentation.

I have attempted to make it a bit more generalized in the types of numeric controls with which it will work. As I originally built it, the control refnum input of the subVI was (by default) strictly typdef'd to only work with that specific slider control type as used in the main VI. I have instead gone to a generic numeric control reference that should work with any numeric control thereby allowing you to use this (renamed) Finalize Control Events subVI with any numeric/slider/dial control.

[WNM]

FWIW, this method of waiting to finalize a control's value until after the control has quit changing does NOT appear to work with dynamically-registered events linked to controls on another VI's front panel.

For this type of event, the option to lock/unlock the front panel while the event completes seems to be missing from the event structure setup for the event and the front panel that holds the control always acts like it is in the "locked until event completes" mode. This means that, after the initial value change, the control will lock up until after the mouse button is released.

I have not found a work-around to this yet, nor do I even know if one exists.

[WNM]

Well, this is turning out to not be as simple as I had hoped. It turns out that even though I have managed to stop any but the final value of the control from being reported out, each and every incremental value-change event generated by the movement of the slider is still detected and queued up for use by the event structure.

And the event structure loop wades through them all before it's done.

Until I can either figure out how to keep this from happening in the first place or else flush the control's event queue before leaving the initial event structure state then this is not going to work for me.

Example attached.

[WNM]

---

Each and every incremental value-change event generated by the movement of the slider is still detected and queued up for use by the event structure and the event structure loop wades through them all before it's done.

---

I have come up the attached "fix" (LV v7.0) for this problem. While it is not as clean a solution as I had hoped it would be, it's the best I can manage given what LabVIEW offers me to work with and it does work in the situation where I need to use it.

Now, within the Finalize Slider Events subVI, I'm keeping track of the most-recent values seen by the subVI, checking to see if they have changed, and reporting out that fact. That gives me a Changed/Not-Changed bit within the event case that I can use to control what code then gets executed. If the event case is just playing catch-up to the real value of the control, I can now see that fact and ignore it.

In this version I've also dumped the variant output and limited the VI to using DBL values. I decided it added complication to something that was too complicated already and I wanted the output terminals for other purposes anyway (reporting of the correct "OldVal" of the control).

Message Edited by Warren Massey on 04-28-2005 03:56 AM

[Philip_Courtois]

Hi Warren,

Your example is a brilliant workaround for a known limitation of the slider control. Your documentation of the code makes it easy to understand what's going on.

I would recommend you to submit your VI as an official example. Use the "Submit new example code"-link on the Example Code Library page.

Good job!

[rpursley8]

Did you think about using the 'Mouse Up' event to capture the value and also use the 'Mouse Leave' event to change the slider back to its previous value if you unclick the mouse elsewhere? You can still use the 'Value Change' for a separate digital control for the manual value changes.

Message Edited by rpursley8 on 04-29-2005 10:35 PM

[WNM]

---

@rpursley8 wrote:
Did you think about using the 'Mouse Up' event to capture the value and also use the 'Mouse Leave' event to change the slider back to its previous value if you unclick the mouse elsewhere? You can still use the 'Value Change' for a separate digital control for the manual value changes.

Message Edited by rpursley8 on 04-29-2005 10:35 PM

---

Yes I did think about it briefly but quickly realized that in the most general case (and the way I wanted to use the slider) that its digital display would be visible and that meant that I had to allow for the possibility of a user never touching the mouse to change the value of the control. It is possible to select any control on the front panel using the TAB key and then to enter a value using the keyboard/keypad and the enter key. The only easy way to allow for this was to use the value change event - otherwise I would have had to been trapping and sorting various key presses, something I did not want to take on...

When I started this I did not want a separate digital control whose value would require coordination with that of the slider. After all, why should I have to add a digital interface to something that already had one for that express purpose? In hindsight, that probably would have been easier to implement. I have hopes that NI will fix this problem eventually since even their people admit that it reflects a shortcoming in the system.