Showing results for 
Search instead for 
Did you mean: 

Slider Disabled property not being read?

I've been trying to come up with a way to use a horizontal pointer slider to show a monitored voltage as well as a lower and upper threshold limit for the voltage. I've created three sliders, two of which have visible pointers and one with a transparent pointer (which is the one I want to use to display the voltage.  I want to be able to adjust the thresholds (which have no fill), but NOT be able to control the actual voltage reading (which fills to minimum) with the mouse.


If I read the active slider in the control's Mouse Down event case, I can set the control to Disabled and Grayed Out, then Reenable on a Mouse Up.  This causes the display to disable and gray out properly when the cell voltage slider is selected, but the slider is still active.  This seems like improper behavior to me.


Of course, what would be really nice is to have the Disabled property be an array when you have more than one slider, and this would be a slam dunk! I can think of many application scenarios where someone would want to disable certain sliders but leave others active.


I've attached the VI in LabVIEW 2011 that demonstrates the problem I'm seeing.  It shows that there are a number of Value Changed events that can occur while the control is disabled.

0 Kudos
Message 1 of 30

One more problem I just discovered.  Although the Slide Properties dialog box has the "Show value tip strip" checkbox within the individual slider properties group, it cannot be changed for a particular slider only.  It changes all of the sliders. If that is intentional, it doesn't belong in that group box.

0 Kudos
Message 2 of 30

Hello wired,


This is Jeff in the Applications Engineering department at National Instruments. I have run your code and see what you are referring to. I am not sure of the intended functionality as to which slider the tip strip should be visible. Your concern as to the functionality seems valid and I would like to submit a product suggestion to see if this needs corrective action.




Jeff L.

0 Kudos
Message 3 of 30



There are two issues related to my post - the more important issue for me is the fact that a disabled control is not being disabled. The tip strip is just something that I noticed while trying to work around the disabled problem.


If this is going to be treated as a product suggestion rather than a bug (which is what I would call it), then my product suggestion would be to enhance the properties for each slider. In general, sliders are not intelligent - they appear to act like a number of overlaid controls.  In order to get sliders to truly act the way we want them to, people are always trying kludgy things like overlaying transparent sliders over visible sliders, programmatically enabling/disabling them or setting range values, etc.


The true product enhancement would be to allow the user to program each slider much like its own control. That way we can do things like enable or disable individual sliders, make them visible, set their range, etc. It would dramatically improve the usefulness of sliders, which are currently very limited in capability. Just look at the posts on this forum where people are trying to get sliders to do something that they are incapable of, but yet, could be capable of given some additional forethought during design of the control. Look at what people are trying to do with them, then see if there's a way to enhance them to allow that capability. I think my scenario is a very common one - (upper and lower adjustable threshold limits with a displayed parameter).


If you have any other suggestions as to how to solve my current problem, I'm all ears.  The implementation I showed you is good enough for an upcoming demo, but it acts weird when the slider I'm using to trigger the disable falls over another slider.  I realize I can overlay another transparent slider, but I have always tried to avoid kludgy solutions in LabVIEW. I'm looking for something a little more elegant, and one that won't have any screen artifacts (like moving a slider back to its original value if someone tries to move it).



0 Kudos
Message 4 of 30

I would also add, based on interacting with sliders quite a lot lately, that if you have chosen a control that utilizes pointers, clicking in the 'bar area' should not cause movement of the slider. To me it is a very confusing behavior because a pointer moves even if you haven't grabbed it with the mouse.  If nothing else, there should be a property to programmatically disable slider moves within the bar area.

Message 5 of 30

Hello wired,


This is exhibiting irregular behavior and I will be taking this issue up with the LabVIEW Experts team to see what they have to say about the matter.




Jeff L.

0 Kudos
Message 6 of 30

JL@NI wrote:

Hello wired,


This is exhibiting irregular behavior and I will be taking this issue up with the LabVIEW Experts team to see what they have to say about the matter.




Jeff L.

Post back with feedback!  I just took a look and found the active pointer property does not deliver as I expected.:  see the attached VI for a means to duplicate:
  1. colors are applied on a pointer by pointer basis but not the checkbox options in the property editor
  2. Digital display adapts to active slider but we cannot display DD per slider
  3. DD Format does not change with active slider although I can change display style for each DD
  4. Write to Slider Property>> Scale marker lock yields a runtime error.
    1. Help for scale marker lock re-directs to text>Lock (Which is writable at run-time!Smiley Frustrated)
    2. Active pointer disable does not exist (But I can set it from the controlls property editor?)
Are there open CARs?
LabVIEW 2011.0 32bit on Win7

"Should be" isn't "Is" -Jay
Message 7 of 30

Hmm. looks like sliders need some serious investigation...  Thanks for doing a little more leg work, Jeff B. I'm guessing there are other issues lurking as well.


I've never been real happy with how sliders work.  This might be a good time to look into actually making them useful.

0 Kudos
Message 8 of 30

Jeff L.


Has there been any action on this?

"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 30

I do not have LV11 so I can not see exactly what you are trying to do, but that should not stop me from wild speculation.  If what I tell you makes perfect sense, and you already knew it, please ignore.


1.  Current Slider Behavior:  When you click somewhere in the empty space of a slider, the Active Slider moves to the point you click.  You can change the Active Slider either with a property node or by clicking on one of the pointers.


2.  Mouse Down is a notification event, the deed has already been done so it is too late disable.  You have rediscovered a "trick" I pointed out here:


The problem you are currently facing is that you would like the Mouse Down Event to occur so the Active Slider is selected and then react based on which slider is active.  This is not quite possible, but you can take on some of the work in the Mouse Down? event.  In this example:


I detect which pointer is closest to a click and then set the active slider accordingly.  This way, the closest slider is always chosen.  You could do something similar:  If the click is going to land on the display pointer, ignore it (Discard the event), otherwise choose one of the two threshold sliders and make it active.  I'd probably go a bit further and ignore all clicks which are not in close proximity to one of the movable pointers, I find it cuts down on stray click problems when you make someone click and drag instead of jumping to the point of a click.  I mean if you are using a physical slider it's not like you can just touch in the middle somewhere and the knob moves there, you have to actually slide it, but I digress.


0 Kudos
Message 10 of 30