Checking the code is not enough to confirm that an error happened -- you have to check code and status.
I'd like the Equal To Zero? and Not Equal To Zero? primitives to support the error cluster wire. The node would look at the Error Code and compare it to zero, resulting in a Boolean accordingly.
So this would result in a TRUE for a warning or an error. Typically, we are just looking for an error. Not completely sold, but worth thinking about.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
That is a misconception. There are lots of errors with positive codes. Just unbundling the error status is just going to be the easiest way to check for an error. The Not Equal To Zero could work for "at least a warning".
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Another good point. Here's what I want to replace with the ==0 / !=0 nodes:
The Select node evaluates the Status Boolean. I thought evaluating the code would give me more flexibility, but you're right, there are positive error codes. I usually care only about errors, so the ==0 / !=0 could look at the Status Boolean.
From your example, why not just use the NOT primitive? The output would be TRUE if there is not an error and FALSE if there is one.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Lets blow it up. Think bigger. Not sure if its a good idea but this just popped into my mind:
How about the error wire cn be connected to ANY compre function? Check error==57, error>0, error=0 (not the same error=true, the boolean can be T, with the code 0). Even build array to add the error code to a list of error codes.
Why restrict it to compare function? error wired to number to string would give the number as string.
What if we wire to a string fuction it use the sting? Wire the error to a concatenate string, and the error string is concatenated.
The whole theme strikes me as a bad idea because checking the code is not enough to confirm that an error happened -- you have to check code and status. There's enough ambiguity in what the comparison means that I don't think it is worth weakening LabVIEW's type safety -- and I say that as one of the major advocates for allowing the error cluster to connect to Boolean terminals.
it is a bad idea. It would be a lot of work to implement, and only saves one unbundle each time it's used. The boolean action is used a lot, and it is very convenient to have.
Still good enough idea to have some fun thinking it over.
