LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

Error to Boolean - Available. . Why not for Integer and String?

Status: New

Connecting the error cluster to boolean inputs is implemented and its a very good feature. The same why not implemented for the integer and the string data types present in the error cluster. There are several instances where this will be handy to use (Error handling - every project has this) so it would be very good if this is implemented. This can be implemented with certain restrictions as done for booleans.

 

Error to Int and String 1.png

 

Error to Int and String 2.png

-----

The best solution is the one you find it by yourself
8 Comments
Member

I agrre, this should be a no brainer... With the new error and boolean comparison LabVIEW is training us to think in terms parts of the errror cluster being equalt to something, so if we can ask if the error is TRUE or False, why can't we ask if the error is a particular TYPE of ERROR  (or CODE) or STRING etc..

If you can compare any part of the cluster then you should be able to compare any other element that is part of that cluster so long as the TYPE is the same

Member

Kudos!

 

And a further step could be...

 

Error-numeric.png         and       Error-string.png

 

may be configurable via right click on the Case selector.

 

Cheers

Trusted Enthusiast

Good one. This could be made configurable right clicking the case seletor.

-----

The best solution is the one you find it by yourself
Proven Zealot

Merely because something is well defined is not a good reason to break type safety. You're not going to win my vote for this one. If you think of the error object as a whole, then asking whether it is an error or not is meaningful, but asking whether it is equal to a string is not meaningful. Asking whether it is equal to a Boolean is not meaningful -- it is never equal to a Boolean. One of its fields, yes, but not the error cluster as a whole.

 

(And I'm talking about the original idea, not Ironman99's extension, which is a wholly separate idea that I'm fairly certain is covered elsewhere in the Idea Exchange.)

Trusted Enthusiast

"Asking whether it is equal to a Boolean is not meaningful -- it is never equal to a Boolean"

 

I don't think I have posted anything like that, ofcourse its already available in 2011 - You can wire up the error cluster to gates and perform operations.

 

If you were talking about the integer type  - why not I had many case where I need to check the error code and for me I feel its meaningful.

 

Thanks

-----

The best solution is the one you find it by yourself
Proven Zealot

You can wire to the Boolean logic primitives (And, Or, Not, etc) but you get a broken wire if you try to wire to Equals.

Untitled.png

Trusted Enthusiast

Yes I agree comparing boolean and a boolean doesn't make any sense but comparing an integer and an integer make sense to me and in many cases we do that.

-----

The best solution is the one you find it by yourself
Proven Zealot

Comparing a Boolean and a Boolean does indeed make sense... they're either both true or their both false or they're not equal. It's no different from comparing two integers. What doesn't make sense is comparing an integer and an entire record of things, only one of which is an integer.

 

Untitled.png

The error code cluster is the same situation. Value wise, it is never equal. And while we could weaken the type safety to allow this, each reduction of the type safety makes it more ambiguous as to whether that was intended or accidental wiring that LV is just interpreting as valid.

 

The hole we cut for the error code cluster attaching to the Boolean functions was deliberately narrow. We did not make the error code cluster coerce to a Boolean type. We overloaded the specific functions to have meaningful definition for the error code cluster in a very limited case where the ease of use trumped the type safety because the way those nodes are used are very specific with the error code cluster. But Equals is a much more generic operation, and I would not support weakening the type safety here.

 

Again, there's no technical reason we could not do this. There are merely opinions about why we should not do this. This happens to be my opinion, and it is one that is consistent with the rest of the design philosophy of LabVIEW that keeps the language approachable for new users and maximizes readability of diagrams written by two different advanced users.