This nugget is the third in a series of nuggets on Case structures. Today I will discuss Case structures that use String data types for their selector values.
The fact that we can wire strings to Case structure selectors is pretty handy. One common example would be running different cases of code for processing a file depending on its type. You can use the Get File Extension VI to get the file's extension, then use a Case structure to process the file differently, depending on its type:
As you can see, a string Case structure allows for multiple values for cases, just like a numeric Case structure. Also, the use of a Default case for unknown strings is pretty common. Now in the case of this example, we don't have to worry about the casing of the file extensions, because the Get File Extension VI always returns file extensions in lower case. If you are in a situation where the casing of the string you want to match is unclear, you can use the Case Insensitive Match option on a string Case structure:
I also like to use the fact that a double-double quote ( "" ) will match an empty string in a string Case structure. So instead of wiring a string to the Empty String/Path? function, and then wiring the Boolean output of that function to a Boolean Case structure, I just wire the string straight into the Case selector and have a "" case for the empty string.
Finally, here are some oddities about string Case structures that you may need to know about someday:
The string type of case is my favorite as it is the basis for my Queued Message State Machine. It is more readable than numerics and more flexible than enums. One caveat is that you have to supply an error trapping case to catch wrong / undefined strings. I use the default case for this and prompt with a programming error and the string name.
It is more readable than numerics and more flexible than enums.
I think Enums are more flexible.
Even a typo in string will take the execution to the error-handling state. And the Case Insensitive match should be used with great caution.
But, Enums dont care for spelling, in the sense whatever is used in its Typedef original will automatically get reflected in each case in every place thro' out the project.
Also, the QSM will look more elegant & easily understandable for all developers with the Enum array for the Queue states.
The reason string selector ranges seem to work unintuitive is actually well thought out. There were various discussions on Info LabVIEW about that and LabVIEW cracks like Greg Mc Kaskle and others provided the reasoning about this.
Basically if you have a range the strings in the range are not anymore an exact match. So take "a".. "c" wil not just match "a" and "b" but anything that starts with an a or b. So the word "anything" would match just as much as "beer", "boot" and "baked beacon". The reason is pretty obvious as having for instance a range "ab" ... "cd" would be very ambigues if the match would be applied to only the exact strings.
Now to make this all work properly and be able to define multiple succeeding ranges that do not exclude certain patterns, one has to make the end of a range exclusive.
The main problem with using a string selector in a state machine has to do with testing and coverage. Unless you can prove you went through all the states and transitions, you can never know for sure that you didn't ship buggy code.
Enums also potentially have this (e.g. if you delete an element from a typedef enum, all the instances where that element was used will be automatically changed for something else), but it is generally safer in that respect.
Enums also potentially have this (e.g. if you delete an element from a typedef enum, all the instances where that element was used will be automatically changed for something else)
Even then, the case structures that use these deleted names will turn red & break the code. That is quite easier to fix than to find & fix an error due to string typo.
I think it was about LV 5.1 when case structures started supporting strings and they were "all the rage". I have some old re-use code that still uses strings. But I have moved into the same camp as tst and generally go with the enum version to take advantage of those "cases I did not think about". Another thing that keeps me away from the string version is just a gut feel that enum selections have to be faster than the string version since it has to be easier to switch on a numeric than a string.