Dany, I like this and think the next logical step is that any node that accepts a boolean should accept the error cluster as well and unbundle the boolean for evaluation. Rick
I like and support this idea, but how about pushing it one step further (if possible, of course)?
Why not give the boolean operators the ability to accept and evaluate any cluster containing one (and only one) boolean (the error cluster is an excellent example)?
It would sure have saved me many unbundles in some programs...
Using LabView 6.1, soon to be upgraded (I hope) I have just passed CLAD My priority: KNOWLEDGE!
I do not support this. The very significance of the term boolean comparison (logical operators) is that it can accept/compare only boolean values. There is a syntax followed in any programming language. The cluster is equivalent of a structure in "C programming". How does it make sense while doing a boolean comparison for a cluster??
> How does it make sense while doing a boolean comparison for a cluster??
It makes sense if the cluster only has one boolean (which is what you use for the comparison) and LabVIEW already does this for specific cases. Try wiring an error cluster into the Select primitive or into a case structure and see what happens.
I agreed with that but after few thoughts I realized that boolean functions also accept integer data, so it doesnt make sense to use the boolean value from the error cluster if there is also an integer which is the error code. I don't believe that NI will consider this idea. What would happen if we connect two error clusters to the boolean function inputs? It chooses the error codes or the statuses?
I don't see any practical use case where you would want to do boolean operations on the error code of the error cluster. I think it is perfectly legitimate for NI to introduce this functionality where the boolean functions just work on the boolean status part of the error cluster.
I wrote a tiny utility routine whose icon is a Stop Sign with a question mark inside it. It "sits" on the error line and has one additional input (called "User Stop") and one additional output (called "Stop or Error"). It's a simple case statement controlled by the error line that either passes User Stop to the output (if no error) or puts a True there. This makes it mnemonic, without "stretching the definition" of booleans. Here's how it looks in the code.
[If you are unhappy with the Stop control and "While Stop" wires coming in on top, simply rewire the VI and put the error lines higher up, or bring the other two wires in on the bottom].
