LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Case structure not working for string

Solved!
Go to solution

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.

Message 1 of 18
(7,061 Views)
Solution
Accepted by OnlyOne

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 18
(7,030 Views)

This is works as intended.

Please review the LabVIEW help under "Entering Values for Each Case Structure Subdiagram":

StringCase.PNG

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 3 of 18
(7,029 Views)

@Norbert_B wrote:

This is works as intended.

Please review the LabVIEW help under "Entering Values for Each Case Structure Subdiagram":

StringCase.PNG


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!

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 4 of 18
(6,962 Views)

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.

0 Kudos
Message 5 of 18
(6,955 Views)

@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. 

 


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 6 of 18
(6,936 Views)

To further elaborate:

When using strings, i often use a separate Default case without any string value attached to it:

DefaultCase.PNG

In that case, i implement stuff appropriate (e.g. error handling, user popup dialog, ...) for 'incorrect' or 'unexpected' strings.

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 7 of 18
(6,913 Views)

@Norbert_B wrote:

To further elaborate:

When using strings, i often use a separate Default case without any string value attached to it:

DefaultCase.PNG

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

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 8 of 18
(6,890 Views)

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.

Message 9 of 18
(6,882 Views)

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

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 18
(6,874 Views)