Scan From String Into Enum -- Exact Match Otherwise Error

[GregFreeman]

Is there any way to accomplish having scan from string, when scanning to an enum, return an error if it's not an exact match? Apparently, if the text in an enum is a subset of the string it will successfully return.

[OEM_Dev]

I just tried this in 2015 SP1 and I get an error if I don't have an exact match. The only difference is my enum isn't a typedef.

[Gregory]

Greg

Just tested in LV 2012 and I'm seeing the same as you. If I'm trying to match the enum option "This", then using the string "Thisasdf" does not produce an error, but using "asdfThis" does produce an error. An easy to catch the case you are worried about is to make sure the remaining string is empty.

[billko]

I never noticed this until you pointed it out.  I have LV 2014 and I see the same thing.  The solution is a good one.

[Darren]

Here's another silly way to do it:

[GregFreeman]

---

@Gregory wrote:

Greg

Just tested in LV 2012 and I'm seeing the same as you. If I'm trying to match the enum option "This", then using the string "Thisasdf" does not produce an error, but using "asdfThis" does produce an error. An easy to catch the case you are worried about is to make sure the remaining string is empty.

---

I saw the same with regards to when it would match and when it would error (i.e. if the string matches the beginning of the enum item). I should have been more clear. This is actually quite an alarming "feature." I need to track down what happens if you have two items in an enum that would cause a match. Does it always match the first? Is it undetermined? This all came about because I was taking a string I received over TCP/IP and scanning it to an enum in my application layer. One of my coworkers said "I noticed your enum has some items that don't match the documentation" to which I responded "well does the sending side have it wrong too then?"

Obviously the answer was no -- there was just no error to be caught. I'm wondering if this is a bug or it is supposed to be that way.

[Intaris]

Hmm, interesting catch.  i think it's designed that way because the primitive can be used to parse a string stream into components, thus parsing what it needs and giving the rest back (it outputs explicity the rest of the string).

Try using %s%[^!-~] as the format specifier.

Never mind, doesn't work.

[Mythilt]

I did a quick test, and it correctly distinguished between an enum with the values 'ThisIs' and 'ThisIsnt', the location of the values in the enums lists didn't matter.  LV 2015.

[GregFreeman]

---

@Intaris wrote:

Hmm, interesting catch.  i think it's designed that way because the primitive can be used to parse a string stream into components, thus parsing what it needs and giving the rest back (it outputs explicity the rest of the string).

Try using %s%[^!-~] as the format specifier.

Never mind, doesn't work.

---

Bummer, was hoping you'd be right!

[GregFreeman]

What if I meant to type "ThisIsn't" as my string but i missed a couple characters. I'll get a match and it will be for the wrong item, when what I really want is it to match neither item. 

Here is the problem: what if I ordered my enum differently so "ThisIsn't" was first. Then scan from string would return that item. Reordering my enum could completely change the functionality of my program.