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
Showing results for 
Search instead for 
Did you mean: 

Allow Error Case Structure to Handle Specific Error Numbers

When you connect the error wire to a case structure selector, you get two cases for error and no error. I think you should be able to add in cases for specific error numbers so you can handle specific errors differently. You could do this currently, but you would have to unbundle the error and use the error code.


Numbered error case.png

Proven Zealot
but i dont see any great use for this. As you yourself have said this can be done by unbundling it. and as such you cant do much in the program for the error. A wiser thing would be to display the error message no matter what error occurs.
Proven Zealot

like this. Maybe we can suggest the dialog accepts the "source"directly instead of an unbundle



Active Participant



With your solution you would still need to create an nested case structure if you wanted to handle each error with custom code. 

Knight of NI

Sounds like a good idea. We should not be allowed to remove the plain error case, which would act as default for all errors that don't have a specific case defined.


However, I would suggest to enter the error number as integer, not as a string with quotes. It could even format it more descriptive, so if I enter 7, it would show as [Error 7] and also have a red frame. A case with multiple errors would show as [Error 7, 2000, 12345]


How about allowing a case for warnings (with e.g. an orange frame)?

LabVIEW Champion Do more with less code and in less time
Active Participant
I agree Altenbach, the general error case would be the default and the quotes were because I was too lazy to cut them out and i just forced the number in there for a screenshot.
Active Participant
This idea is in the same vein as this one, I think
Tim Elsey
LabVIEW 2010, 2012
Certified LabVIEW Architect
It seems to me that the two ideas should be merged in an elegant fashion, if possible. What about warnings?
Nothing like a good dose of LabVIEW to cure what ails ya'.

I agree with altenbach, but I'd prefer a yellow frame for warnings Smiley Tongue


The idea is great, but how @RandyP noticed, there are some more aspects to consider.


If there are different cases for errors (red) and warnings (yellow),it should be possible to enter a code without distinguish between warning and error. Indeed it should be user selectable. I would suggest an orange frame for this.


Because the concept behind the idea of @Hueter is more powerful than just to apply a single code to a case, combinations of codes which apply only to an error or a warning and codes which apply to both are possible too. That could look like this:

Error and Warning Case Structure.jpg

The brown case applies to all possible combinations of more than one category.


Because it isn't intuitive for a beginner, how to express a complex combination which applies to a state, I would recommend an editor like this ...


Edit Errors and Warning Codes Wizzard.jpg


If now somebody complains, what's about a generic warning state, it could look like [Warning ..-1, 1..] or simply [Warning].

Proven Zealot

gerh: Generally I like the proposal, but I wonder if you have any thoughts on how to differentiate those frames via something other than color. I already hear complaints about red/green on the error case as it stands from color blind folks. You have some pretty subtle shading in your current picture. Can you propose anything to differentiate the border by pattern that wouldn't disrupt your reading of the diagram?


Also, I would expect people to want a frame that handles both one specific error and no error -- that would crop up when trying to filter one error out but report all other errors. Similarly, one frame for no error and a warning, and for no error and an error and a warning.


What if we didn't do any new color differentiation at all? Green for the no error case (even if it had other errors in the same case) and red for all the others, regardless of the error/warning mix?