Darren's Weekly Nugget 03/09/2009

[Darren]

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.

String selector

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:

• If you find yourself needing to match some of the special characters used in a string Case structure (like a double quote), you need to escape these with a backslash.  So for a case matching a double quote, type \" in the frame selector.  For a case matching a backslash, type \\.  Most every other character I tried could be entered without the backslash, and instead just by enclosing it in quotes...for example, to match a comma, type "," in the frame selector.
• Matching ranges of characters doesn't quite work the way I expected it.  For example, if I have a string Case structure with an a..c case, it matches a and b, but not c.  I'm not sure why that is, but I'm guessing there's some sort of reasonable explanation.  I can't think of any time I've needed to use ranges when matching strings, but if I ever do, I'll probably just play it safe and match ranges of ASCII character indices (and thus, use a numeric Case structure) instead of trying to match string ranges.  You can convert strings to character arrays and vice-versa with the String to Byte Array and Byte Array to String functions, respectively.  Now that I think about it, if you're just dealing with a single character, you could just use the Type Cast function.

Message Edited by Darren on 03-09-2009 11:14 AM

[Spectre_Dave]

Darren

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.

[GregSands]

Can you explain why a string case is more flexible than enums for specifying states?  It's not like you ever want to use a state you haven't defined.

[jcarmody]

 I like using them because you can easily pass data from state to state (without using an enum+variant cluster) ala the JKI State Machine.

[parthabe]

---

VADave wrote:

Darren

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.

[rolfk]

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.

Rolf Kalbermatter

Message Edited by rolfk on 03-10-2009 08:39 AM

[tst]

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.

[parthabe]

---

tst wrote:

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.

Message Edited by parthabe on 03-10-2009 05:34 AM

[Spectre_Dave]

The reason the strings are more flexible is that you can create a generic QMH that works for different states for different VIs.  Enums have to be created for each QHM. But like I mentioned before you must create a state to catch incoreect strings.  I have a Polymorphic Queued Message Handler and I never have to use the Queue primitives.

[Ben]

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.

Ben