Would be nice to have an element selector with error case. No need to wire an unbundle element to connect the error code, then the Case structure becomes like a numerical values case selector.
Aristos: That assumes that everyone uses NI's convention of warnings/errors, and not everyone does.
As for the idea:
I don't really see the need for this, and I think this would actually complicate things. What happens when you decide to switch from code to the status, and you have more cases than just the 2 possible Boolean values?
Aristos wrote: Any design that NI does will assume that paradigm.
Any design that NI does will assume that paradigm.
I know. My own personal opinion on that convention notwithstanding, my only point is that the rest of the world may not follow that convention and thus would not see it as a problem for this idea. In this particular case this would be in user code, not NI code, so why would the convention have any bearing? Even if this idea were implemented (which I disagree with anyway), NI wouldn't be able to use it because of the convention, so you would simply produce code the same way you do now.
I really enjoyed your comments, thanks to all. I realized that it's not that easy to propose now ideas for LabVIEW.
But I still think it could be simple to use that idea with codes only for errors, ignore warnings like it actually does. So even in "code mode" it would check for the status. Or perhaps clever people could figure out that it's better to have one more option to ignore or not the error/warning status.
For the switch back to "error status" with only two cases I think it should requires to define a "Default" case different than "No errors". As it's actually possible to remove case structure and popup a message to user to accept that he will lose all the other cases code.
You never wire a unbundle element to connect your error code to a case structure, to handle your different error codes?
JICHFI wrote: You never wire a unbundle element to connect your error code to a case structure, to handle your different error codes?
I have, but quite rarely. I can probably count the number of times on one hand. Given that I've been coding in LabVIEW since LabVIEW 2.something, I honestly can't see the need for this. But again, that's only my opinion - don't let that discourage you from supporting your case.
> my only point is that the rest of the world
may not follow that convention
> and thus would not see it as a problem
for this idea. In this particular case
> this would be in user code, not
NI code, so why would the convention have
> any bearing? Even if this
idea were implemented (which I disagree
> with anyway), NI wouldn't be
able to use it because of the convention, so
> you would simply produce
code the same way you do now.
I think you miss my point... the whole world doesn't have a choice about using a different convention. Suppose you write some DAQmx code and you want to trap error code 1850 -- DAQ Card On Fire (I made it up.) Suppose that some DAQmx subVI returns a warning 1850 -- DAQ Card Feeling Hot. You wire your error code cluster to the selection terminal and you put "1850" into the selection ring. Do you expect your case to execute only on the warning or only on the error or both? To implement this feature, LV R&D has to decide how many configuration options to expose and what behavior to have when these edge cases arise. Is it literally just checking the number (both warning and error trigger code)? Is it looking for the error bool to be true and the code to match (just error)? Is there some prefix that you type in front of 1850 that would mean catch the warning?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.