Why is a boolean sometimes a variant?

[dgholstein]

All;

I have a latch-when-released boolean control on my front panel, when I create a property mode and select either the "value" or "value (signaling)" property, it shows up as the purple variant type -- not the green boolean type I'm so familiar with (and have seen before).  When I wire a "true" to it, I can see it doing an intrinsic conversion.

Needless to say, this really messes up my application (since the "signaling" -- doesn't).  Why is this so?  Why does NI torture me this way?

If you look at the attached BMP, you'll see that the local variable is a boolean, but the value property isn't.  Of course, that only adds to my confusion.

   ...Dan

[Albert.Geven]

Why are you using a property node for the value if you can use a local, that is faster and more readable, but you are right latched booleans are incompatible wit locals.

looking in the help generates:

Data value of the control (LV variant). If this is a Boolean value configured with a latching mechanical action, this property always returns an error. Due to race conditions that can occur when you have a Boolean value with latching mechanical action, you cannot programmatically read Boolean values that are set with a latching mechanical action.

If you make it a switch instead of a latch it works as expected by you.

[Marc_A]

I get around this by making it 'switch when released.' Then in the value change event case, set it back to false. This will make it behave like a latch and still work with events and value properties.

[altenbach]

Just to add to Albert's explanation:

A latch action boolean button is TRUE until it is read by the diagram as determined by dataflow. Once the value is read once, it reverts to false. Imagine what would happen in your code of multiple code locations woud read from it or write to it. Would not work! Right? Every time a different read would get there first and revert it again and the other locations would never see it.

However, I agree that it would be useful to be able to write to a signaling property of a latch action boolean to fire an associated event. Right now, you can just add a second, hidden boolean (switch action) to the same event case and write to a signaling property if it to fire the combo event.

Writing to a signaling property fires the event even if the value does not actually change (e.g. wire a FALSE to a Value(sgnl) property of a switch that is currently false and the event still fires. My suggestions would be that wiring an input to value(sgnl) property should be optional. If unwired, the value of the control is not changed but the event still fires. It should also work with latch action booleans the same way.

There is always the product suggestion center !:)

[dgholstein]

Albert;

Very simply, to fire a change event.  I don't care about the "value", I care about "value (signaling)"

   ...Dan

[dgholstein]

Marc A;

I actually did exactly as you suggested before reading your response.  Thanks.

I just wish I didn't need a work-around to fire an event on such a push button.

   ...Dan

[Marc_A]

I wouldn't really call this a workaround since you're working around something that has been put into the program on purpose to make your life easier. It is not a bug, it's there to protect you. If you don't want to change the mechanical action of the button and have to set it back to false, do what altenbach said and use a second, hidden boolean so you can fire the event programatically. This actually makes more sense now that I think about it.