05-15-2017 06:08 AM - last edited on 05-15-2017 05:40 PM by karina.barles
Hello,
i have a case structure where one case is "1".."4".
Then a string input.
When i enter 1, 2 or 3 the case is working. But not for 4.
Why this?
Labview 2015
Thanks
Edit: Correct attachment selected.
Solved! Go to Solution.
05-15-2017 06:24 AM
The end string is not inclusive. Try making it "4!" and it should include the 4.
Of course, if you are only dealing with integers, it would be better to convert to the number and then use the case structure.
05-15-2017 06:27 AM
This is works as intended.
Please review the LabVIEW help under "Entering Values for Each Case Structure Subdiagram":
05-15-2017 05:25 PM
@Norbert_B wrote:
This is works as intended.
Please review the LabVIEW help under "Entering Values for Each Case Structure Subdiagram":
Wow - I never would've even known this. I would've just expected it to be inclusive like the Numeric ranges. Thanks for helping me avoid a pothole!
05-15-2017 06:46 PM
Personally I have to admit that I was under the impression that case structures couldn't actually handle strings at all. I could have sworn I read a help file somewhere stating that this was the case, or maybe I was just confusing them with arrays.
Either way, learning things. Although admittedly not necessarily helpful things, in terms of safe handling I feel like using strings as inputs is just asking for trouble.
05-15-2017 08:26 PM
@ogk.nz wrote:
in terms of safe handling I feel like using strings as inputs is just asking for trouble.
With user input, you are likely right. But you can limit issues by using a combo box.
But I use strings for my state machines. If I mess up the constant for the state, it will become obvious quickly.
And some more information, you can right click on the case structure and enable "Case Insinsitive Match". Then you don't have to worry about capitalization.
05-16-2017 02:35 AM
To further elaborate:
When using strings, i often use a separate Default case without any string value attached to it:
In that case, i implement stuff appropriate (e.g. error handling, user popup dialog, ...) for 'incorrect' or 'unexpected' strings.
05-16-2017 07:32 AM
@Norbert_B wrote:
To further elaborate:
When using strings, i often use a separate Default case without any string value attached to it:
In that case, i implement stuff appropriate (e.g. error handling, user popup dialog, ...) for 'incorrect' or 'unexpected' strings.
Just to add a different way of looking at using strings and default cases to catch problems...
Compared with using type-defined enums, finding bugs using strings requires running the code and exercising all options to make sure we did not type a string wrong. Enums yell at me as soon as there is the slightest discrepancy. Seeing my inability to type and my desire to enhance code without having to go through every single possible transition... I have taken a liking to the enums.
Sure there are many situation where strings based cases work nicely.
Just my 2 cents,
Ben
05-16-2017 07:55 AM
Hey Ben I saw this blog post on the subject recently, and it made me think of you. The author quite clearly has a bias toward strings, but he lays out several reasons why strings can be more useful than enums.
http://kosist.org/2016/11/labview-queued-state-machine-enum-or-string/
That being said enums are a fine way to go and I still use them often, and wouldn't re-write an application using them for a state machine or QMH.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
16 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
05-16-2017 08:08 AM
Thank you for sharing that blog Brain.
Some people like anchovies on their pizza and some do not. There really is no common ground between those two opinions. I have written on my opinion of the Worm Orobouros of design patterns many times and will skip that point now.
Back when LV introduced string based case structures they "were all the thing" and many were excited about them. I tried them out and wrote some error handling functions using string based cases. That set of code lives on today in our re-use library and aside from being adapted to modern OS's, Libraries, etc. it is still string based to this day.
So no I would not rewrite existing code unless there was a problem.
Ben