Detecting Control Slider 'final value'

[JackHamilton]

A recent info-LabVIEW post asked about detecting the 'final' value of a control knob or slider. The problem with the new event structure is it is TOO efficient at catching all the change events for the control - but what you really want is only the 'final' value selected by the user.

"Mouse Up" event does not always work reliably - as th use may slide the mouse off the control prior to releasing the mouse button.

I've coded up an example using this detection scheme with Queue messaging between two loops a GUI and processing Loop.

The jpg diagram shot is a simpler version only showing how the algo is wired to the shift registers.

Enjoy and Regards

Jack Hamilton

Download File:post-37-1108576177.vi

[didierj]

There is an other way of programming it, avoiding the "before LV6" programming style. Especially when one already use the event structure. This makes "mixed-mode" code.

In the Info-LabVIEW there was an other solution with mouse-up and value change. Unfortunately this won't work, when the mouse is moved avay of the knob while pressed.

Here is my solution:

1. use the mouse-down of the knob to set a flag.

2. in the mouse-up of the vi read the flag and if it is set, read the knob value.

Download File:post-253-1108621995.vi (LV6.1)

Didier

[jpdrolet]

Here are clever techniques that really detect when the user releases the mouse (5.1!).

In LatchSlide.vi , the slide value is latched only when the user releases the mouse. There are two sliders on the slide, one for display and one for manipulation by the user (it is invisible and covers the whole control. On the diagram, the invisible slider is constantly pushed offscale (via local) and then read. If the value stays offscale, that means that the user has released the slider and the value can be latched. If the value is still on scale, that means the user still holds the slider and the value is not latched.

In MouseTrack.llb there is another technique using a picture control. When a change is detected on a control indicating that the user is editing it, a transparent and invisible picture control covering (and in front of) the whole panel is made visible. The mouse position is read on the picture control. The trick is that as long as the user keeps the mouse button down, the focus remains on the edited control and the mouse position on the picture stays (-1,-1). The mouse up event is detected when the mouse position on pict is different from (-1,-1). One slight incovenient of this technique at the time I designed it is that on Mac and some configuration of Windows, the mouse had to be moved at least one pixel on the pict for the actual mouse position being correctly reported after mouse release.

Download File:post-447-1108650884.vi

Download File:post-447-1108650886.llb

[PeterB]

I had to find a solution to this problem a few months ago, I can't remember where I got the idea from , although someone may recognise it (apologies for not giving due credit). The solution attached uses one event structure and works even when the mouse is released and not over the control. The particular solution allows you to read the control value as it is changing, and latch it when the mouse is released.

When the user puts the mouse down on the control, you dynamically register a mouse up event for any further 'mouse ups' on that vi. As the user slides the value around, the control value changes, but not until they release the mouse does the final value get propogated (to another indicator etc.)

regards

Peter Badcock

Download File:post-1272-1108693723.llb

[JackHamilton]

I will caution that multiple control stacking such as the picture control is cute - but will be problematic on complex GUI's. The picture control was a good way to create the "Hover button" effect.

I'm not a big fan of Dynamic Events - mainly because I never had sleepless nights wishing they existed ;-). (however, I'm just not one of those who jumps on the latests thing - until it's been kicked around a bit)

As I get older, It's becoming clear to me that readabiliy of the code is very important. More important than a clever method that may obscure the intent of the code. Anyone who's tried to pick up or be part of the project with lots of VI Server calls knows the potential issues with this.

I chuckle abit at the shock of implementing a Pre-6i solution to polling buttons, my gosh that's all we had back then!

Regards

Jack Hamilton