LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is there a limit for case structures?

Does anybody know if there is a limit to the number of tests a case structure can handle?

Thanks!
0 Kudos
Message 1 of 15
(4,816 Views)
Hi dpatch,

To my knowledge, there is no limit to the number of cases that a case structure can handle. However, at some point an application with an extremely large number of cases can become complicated to program and debug. Are you just looking for information to help you plan your code, or are you running into a problem that you believe is related to the number of cases in a case structure?

Regards,

Mike N.
0 Kudos
Message 2 of 15
(4,809 Views)
I have picked up someones code that has a large number of cases...I haven't counted them. It is comparing strings that are read from a file. There was strings that it seemed to be missing, but when I looked at it closer it was due to the string case (uppercase vs lowercase).

When I selected "Case Insensitive Match", LV immeadiately exited, displaying the standard "report this error to Microsoft" dialog which is meaningless. I have not seen this before making this selection so was wondering if there was some sort of limit in the Case Structure causing the problem.
0 Kudos
Message 3 of 15
(4,800 Views)
Hi dpatch,

The number of cases should not be the problem. Has this code worked correctly in the past? Does it generate this Windows error message repeatedly when you try running it again?

I would suggest using Highlight Executation as well as inserting more error handlers to try to catch where this problem is occurring.

Mike N.
0 Kudos
Message 4 of 15
(4,791 Views)
I can't use the debugger because it happens when I try to toggle the state of the "case sensitive match" menu option. I have been sitting here playing with it...checking the case sensitive option and unchecking it...sometime it happens and some times it doesn't.

It never happens in a new standalone vi. So it must be something in this code, but it sure is a mystery!

Simply checking (or unchecking) the menu option makes it happen. What ever state I get it in, the code runs as expected. It is when I switch between the two states. Sometime it throws the exception and sometimes it dosen't!

Kind of scares me...
0 Kudos
Message 5 of 15
(4,788 Views)
I do not recall where it was but recently I saw a thread which discussed some of the problems with using strings as case selectors. Apparently the matching functions in the case selector are not very sophisticated and certainly not very powerful. Using the string matching functions was preferred for evaluating random strings. Enums (usually type def'ed) are preferred by many as selector for case statements.

This does not answer your question about what is happening, but my give you some ideas about alternate approaches. Sometimes when mysterious behavior is found in inherited code, it is better in the long run to rewrite the suspect portion.

Lynn
0 Kudos
Message 6 of 15
(4,766 Views)
I think what dpatch is saying is that by just right clicking the case structure and selecting the "Case Insensitive Match" causes LabView to crash. It happens during editing, it has nothing to do with run-time. I am experiencing the same thing, I can't check that option because LabView just crashes. I don't know how this could NOT be a bug.
0 Kudos
Message 7 of 15
(4,691 Views)
Could you post an example?

I would like to see this.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 8 of 15
(4,630 Views)
This is a template VI for a state machine. I tried to check the "Case Insensitive Match" option on the main case structure but could not (at least on my computer: Win2000, LabView 7.0), I eventually re-wrote it.
0 Kudos
Message 9 of 15
(4,608 Views)
Thank you for posting this example.

I was able to duplicate your crash using both LV 7.0 and LV 7.1.

I was able to work-around it by first deleteing the "null strings" ("") specifier you included with your Idle state.

After that I was able to do the case-insensative match. Then I went back and added the null string ("") to the idle case with no errors.

I was not able to recreate this issue from scratch with LV 7.0 or 7.1.

If you have backups that reflect the "before and after" states, you may want to pass those along to NI support. If you do not, we are just going to have to call this a bug in the editor and keep our eyes open for similar issues.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 10 of 15
(4,597 Views)