Case structure with string selector "N\A"

[billko]

---

@elset191 wrote:

---

@RTSLVU wrote:

I may be being picky here but I assume your "N\A" case is short for "Not Appropriate" ?

Shouldn't that be abbreviated as N/A (forward slash) not N\A (back slash)

BTW: The forward slash works fine as a case

---

Your assumption is right.  And it should be N/A, but I cannot count on my field engineers not to type N\A or NA, so I was putting those all in the selector. 

---

I think it would be easier to fix this at the input rather than at the case structure.  Either automatically handle bad input (a little complicated) or make it a choice like an enum or a ring so there is no possibility of bad input (really easy).

[elset191]

---

@billko wrote:

---

@elset191 wrote:

---

@RTSLVU wrote:

I may be being picky here but I assume your "N\A" case is short for "Not Appropriate" ?

Shouldn't that be abbreviated as N/A (forward slash) not N\A (back slash)

BTW: The forward slash works fine as a case

---

Your assumption is right.  And it should be N/A, but I cannot count on my field engineers not to type N\A or NA, so I was putting those all in the selector. 

---

I think it would be easier to fix this at the input rather than at the case structure.  Either automatically handle bad input (a little complicated) or make it a choice like an enum or a ring so there is no possibility of bad input (really easy).

---

The configuration with a potential N/A comes from a text file.  Me making this case structure is basically handling it at the input. 

In my system, N\A or NA would get caught downstream saying those values are not valid because they wouldn't match the contents of a different config section, but I'm just trying to eliminate a potential error my users have to figure out.  N/A is the keyword I've chosen that will skip the downstream steps for a particular item.

[billko]

---

@elset191 wrote:

---

@billko wrote:

---

@elset191 wrote:

---

@RTSLVU wrote:

I may be being picky here but I assume your "N\A" case is short for "Not Appropriate" ?

Shouldn't that be abbreviated as N/A (forward slash) not N\A (back slash)

BTW: The forward slash works fine as a case

---

Your assumption is right.  And it should be N/A, but I cannot count on my field engineers not to type N\A or NA, so I was putting those all in the selector. 

---

I think it would be easier to fix this at the input rather than at the case structure.  Either automatically handle bad input (a little complicated) or make it a choice like an enum or a ring so there is no possibility of bad input (really easy).

---

The configuration with a potential N/A comes from a text file.  Me making this case structure is basically handling it at the input. 

In my system, N\A or NA would get caught downstream saying those values are not valid because they wouldn't match the contents of a different config section, but I'm just trying to eliminate a potential error my users have to figure out.  N/A is the keyword I've chosen that will skip the downstream steps for a particular item.

---

Oh, I thought it was direct input.  I guess it's too late to change it to something less ambiguous?  😉

(I understand - yes, of course it's too late, or it would have been done already.)

[RTSLVU]

---

@elset191 wrote:

---

@billko wrote:

---

@elset191 wrote:

---

@RTSLVU wrote:

I may be being picky here but I assume your "N\A" case is short for "Not Appropriate" ?

Shouldn't that be abbreviated as N/A (forward slash) not N\A (back slash)

BTW: The forward slash works fine as a case

---

Your assumption is right.  And it should be N/A, but I cannot count on my field engineers not to type N\A or NA, so I was putting those all in the selector. 

---

I think it would be easier to fix this at the input rather than at the case structure.  Either automatically handle bad input (a little complicated) or make it a choice like an enum or a ring so there is no possibility of bad input (really easy).

---

The configuration with a potential N/A comes from a text file.  Me making this case structure is basically handling it at the input. 

In my system, N\A or NA would get caught downstream saying those values are not valid because they wouldn't match the contents of a different config section, but I'm just trying to eliminate a potential error my users have to figure out.  N/A is the keyword I've chosen that will skip the downstream steps for a particular item.

---

Maybe I still do not understand but, here is the DC Source section of my config file.

Here is my VI for setting the DC voltage.

The other cases contain the proper instrument VI's to control the proper instrument. The default case is also the "none" (no DC source) case so if the technician enters "norn", "N/A", "N.q". "nada", "Agilant" or "ahgi84t" it will default to none and not cause problems trying to communicate with an instrument that is not present.

In your case I would do the same thing, if I understand correctly one would only enter N/A when they want to skip that portion of the test. So making "skip this portion" the default you will still skip it of the user enters N/A or N\A, or aseht989shrg.

If they enter N?A instead of N/A it will still skip, and if they mistyped whatever is supposed to make it run that test. They will see that the test was not run, so that should lead them to checking the configuration file for mistakes.

Frankly if you do not want to do it this easy way then you have to error check the configuration file either before or as you read it. 

[elset191]

[Config]

InstrumentNames = Temp1, Temp2, Temp3, N/A, Temp4

[Temp1]

//Scaling info for Temp1

[Temp2]

//Scaling info for Temp2

[Temp3]

//Scaling info for Temp3

[Temp4]

//Scaling info for Temp4

The InstrumentNames list is in the order they are wired physically, so I can't just leave the N/A out.  The names in the list are used to reference those sections in the config.  If I encounter an N/A, I don't try to read from the config.  If I encounter an N\A it would search for the N\A section and throw an error because it's not there.  I'd prefer my user not encounter this error, so I tried to expand the N/A.  Of course, they will still get an error if they try to use N?A, but I figure that's not as common a mistake as reversing or omitting the /.

By having the N/A not being the default case, I don't have to add a case for Temp1, Temp2, Temp3, Temp4, Pressure1, Pressure2, Pressure3, Pressure4, etcetcetc (all of which would be indentical)

[RavensFan]

No.  What you do is when you read the string from the config file, search the string for all the bad variations such as N\A and replace it with N/A using the search and replace string function.  From there, you use the fixed string to drive the case structure.

[elset191]

---

@RavensFan wrote:

No.  What you do is when you read the string from the config file, search the string for all the bad variations such as N\A and replace it with N/A using the search and replace string function.  From there, you use the fixed string to drive the case structure.

---

Yes, that would be better, particularly if the need to filter on N/A comes up again anywhere else in the program.

[d.w.b]

---

@altenbach wrote: Yes, standard rules for escaping special codes apply (should be mentioned on the help page!)

It is, at least now. See https://www.ni.com/docs/en-US/bundle/labview/page/lvhowto/creating_case_structs.html and https://www.ni.com/docs/en-US/bundle/labview/page/lvhowto/case_selector_values.html