National Instruments will not be implementing this idea. Given the execution overhead of the node, the Error Ring should be called conditionally in a case structure whenever its value is needed at run-time.
Of course, the two examples would produce identical outputs. One would take a bunch fewer clicks and BD space though.
Of course, the two examples would produce identical outputs.
No, it's not of course. You could equally argue that a false should output warning 5000.
This is a general point which comes up from time where someone says "let's add a conditional terminal to function X" and the usual answer is "just wrap it in a case structure". Maybe the error ring should be one of the exceptions to that rule, but I'm not sure of that.
tst does have a point... How would this handle warnings? Would the pull down menu be pre-filled with all the user defined error messages? That part I like... if it is pre-loaded with all the user defined error codes.
Ray, It would work just like the current error ring. click the error glyph it throws a warning. Click the chain glyph to toggle include call chain. Define an error file with Tools>>Advanced>>Edit error codes and it populates the ring with user error codes and explainations. I'm not proposing to change any of that behaviour. But since most of the time I throw an error from my code there is a boolean condition met. I simply want a Throw this error? boolean to avoid code like the top example or this example, written before the error ring but wow, that would clean it up and explan errors without comments.
tst does have a valid arguement, except when you realise that the ring COULD be configured to throw a warning so it allready has that switch.
As soon as you drop this new CER, it is already a warning because default error is false. If you connect a true value, it becomes an error.
The error code is automatically selected when you select the error message from the ring control. You could even get this to read the contents of an "error list" which is saved within the LabVIEW (installed) directory.
If it is as described above, then this is a fantastic and revolutionary idea.
I cannot take credit for the idea you describe. LabVIEW 2012 introduced the basic features (Thank you Steven!) of the Error Ring. More accuratly the error ring was re-introduced to LabVIEW but, with a serious upgrade!!!!
This idea is quite limited by comparision. Bool- throw "this" warning/Error, out of the error ring / Do not throw "this" onto the error chain out of the error ring and default output a [F,0,NULL] [Bool, I32,String] cluster. (No Error)
You're right, I do need to catch up with the times... Too many new features in LabVIEW 😉
OK... now that I finally caught up a little, I see that you want to add "conditional" to the new error ring. That means you want the False case to automatically select "No Error", right?
Can you explain what is the text at the bottom of the ring? Other than calling it a Schmuck..
Fair enough. I don't use 2012, so I forgot about the toggle option.
As for whether this should be an exception to the just-wrap-it rule, at first I thought of it as a simple constant, so the answer was no, but if you consider it as a function where outputting another value is common enough, then it sounds reasonable.
National Instruments will not be implementing this idea. Given the execution overhead of the node, the Error Ring should be called conditionally in a case structure whenever its value is needed at run-time.