LabVIEW
Strange Boolean Value
Not sure what I am seeing here. I created a Boolean from the UI Control Suite: System Controls 2.0 palette (a free add-on) and as I did not like it, I replaced it (by that I mean I used "Replace...") by a System Boolean (a check box):
I created a Property Node "Value" from it and I got this:
In other word, my Boolean is a Boolean AND a Variant... Do I win something special for this one?
A demo VI (LV 2011) is attached.
Note: of course if I get the Check Box System Boolean directly from its palette, things work as expected (i.e. the "Value" has a Boolean type).
I understand the difference between latching and not, what I don't understand is the behavior of the Property Node.
Actually, if you change a non latching Boolean to a latching one, its "Value" Property Node changes to some "undefined" black color (which would in fact be a good way to warn the user):
which no Ctrl-RUN click will transmogrify into the Variant type I was describing above.
The Help mentions that the "Value" Property Node will return an error, which it does in the VI I attached (error 1193, "LabVIEW: When a Boolean control has a latch mechanical action, you cannot use the Value property to read or write its value").
But there seems to be no particular logic to have the Property Node "Value" be of type Variant.
I want my CAR!
🙂
X.
the system check box is a varient because system check boxes depend on the operating system for their representation. System check boxes don't even require a BOOL representation. On a Windows 32bit PC this is an unsigned char same as LabVIEW (hence the easy Bool to 0,1 conversion) On other OS's; a U32? U16? U64? I8? (for mixed check boxes?) I don't really know- its system dependant and I trust LabVIEW R&D to do that work.
All good answers above. My point though, was that this behavior does not appear to be documented, at least not in the natural location, which would be either the "value" property node help or latching boolean help.
I know that I need to drop a latching boolean control in the event node that handles it (as examplified in the WRONG VI below - which does not work in the sense that the Boolean is NOT updated):
What I was suprised about is that you have to wait until runtime to be warned about it (and then only if you look at the error output - which I bet very few do - or you watch carefully how the Boolean reacts ..not). I think the black/broken VI behavior of the Property Node, which occurs when you change the behavior from non latching to latching and the Property Node was already here, is SAFER and MORE INFORMATIVE than the one I was reporting. That is, if you drop a "Value" Property Node for the latching boolean, it shows up as a Variant, which at best is "puzzling" for the non-insider.
My 2 cts.
Maybe not a CAR, but at least a BIKE (*)?
(*) Bit of Information, Knowledge or Explanation
@X. wrote:
All good answers above. My point though, was that this behavior does not appear to be documented, at least not in the natural location, which would be either the "value" property node help or latching boolean help.
Which behavior are you referring to? The fact that the datatype is a variant? Or that when you change the mechanical action from switched to latching that you get an "unselected" property (i.e., the "Value" property text is black instead of green or purplish). Or both? I can see where having a little extra documentation certainly wouldn't hurt.
However, I will guarantee you and even bet you $1 that for every person that is able to find out the answer via the documentation, there will be 3 that post a question to this forum before even bothering to look at the documentation.
Oh, and so far, I have never lost my $1 bets. 
