LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

case struct v. coerce w.r.t. string input

Solved!
Go to solution

Can anyone tell me what's going on with the case structure?  It decides "Z" is  not in the A..Z range.  Works as I expect when I pass it into a "in range and coerce" function.

 

Found on LV2013-32 running on Win7-64.  Confirmed same behaviour in LV2014-32 on same machine.

0 Kudos
Message 1 of 8
(3,163 Views)

I can confirm this on my LabVIEW 2013 32-bit Full / Win7-64. In the case structure just a simple Z works fine, but anything .. Z fails.

Z .. is OK 

0 Kudos
Message 2 of 8
(3,147 Views)

This is not a bug, its a known behaviour according to the LabVIEW help. To verify replace the range with "A".."Z" with "A".."a" and see the difference.

 

Edit: Case Structure link for your reference

-----

The best solution is the one you find it by yourself
Message 3 of 8
(3,130 Views)

This is correct behavior.  The strings are not inclusive when it comes to the upper range.  I don't remember the exact reasoning.  It was somewhere in the Idea Exchange.


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 4 of 8
(3,107 Views)

Hi,

 

what's going on with the case structure?  It decides "Z" is  not in the A..Z range.

Well, reading the LabVIEW help would explain the behaviour in each detail.

It says:

A range of a..c includes all strings beginning with a or b, but not c.

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 5 of 8
(3,100 Views)
Solution
Accepted by topic author Zwired1

P@Anand wrote:

[,,,] To verify replace the range with "A".."Z" with "A".."a" and see the difference.


I like "A..Z", "Z" better.  It'll avoid ambiguity when a desired range is, say, from C to L, inclusive.  "C..L", "L" makes it clear that "M" isn't included.

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

Message 6 of 8
(3,076 Views)
I agree. I just wanted to show the OP that what happens is an expected behaviour and mine is not a solution for the problem.
-----

The best solution is the one you find it by yourself
0 Kudos
Message 7 of 8
(3,067 Views)
Solution
Accepted by topic author Zwired1

Remember that the case structure is based on a string in this case, even if you are thinking in terms of chars.

 

Let's say that the upper limit was inclusive, then to match strings which start with A,B, and C [A..C] you would have to specify the "largest" string which begins with C, is it CZZZZ or CZZZZZZZZ or C\xFF\xFF\xFF.... etc.  The way it is now you can do [A..D)

 

The same issue complicates adding floats to the case selector options.  

 

One solution is to add the ability to specify the inclusiveness of the boundaries.  The normal method is [,] for inclusion and (,) for exclusion.  Then you could write [A..D) for strings and [A..C] for chars.  And you could add floats to the Case structure as well.

 

Another is to allow U8's to be viewed as their ascii equivalent so you could use those more readily.  Same as selecting the radix.

 

Another option is to have an option to match only the first char of the string and make the limit inclusive in that specific case.

Message 8 of 8
(3,032 Views)