Allow regular expressions to be used in Case structures selector label

[Mark_Yedinak]

When a string is the input to a case structure's selector tunnel allow selector labels to contain regular expressions.

[RavensFan]

Can you post an example?

I'm not sure this could be done.  You could wind up having more than one case having an expression that meets the criteria for the string being wired in.  Then which case would execute?

[smercurio_fc]

This is similar to (though clearly not exactly the same as) this idea. I suspect the pros and cons of that idea apply here as well.

[Mark_Yedinak]

One example would be if I have an application that is processing files in a directory and based on the name of the file it will choose different processing. However, there are multiple files that follow a specific naming convention such as Image0001.png, Image0002.png, etc. There are also some files that have similar names but should not be processed such as Image0001-old.png. Using a regular expression you could select the correct files and filter out the you don't want. There are many cases where regular expression would be useful. Yes, you could define two regular expressions that would match a particular string however this would be something the programmer needs to consider, not LabVIEW. I would expect the first patter to match would be the one that gets executed.

[craigc]

I Like the Idea

I have come across situations where by this would have been very handy, although I can not remember specifics.  Ultimately I had several "Search for reg expression" outside the case structure driving said case structure.  I do not believe it is required that often but it does pop up.

[JackDunaway]

I was the vocal opinion against the similar post that smercurio_fc linked to in the second comment.

However, I would like to hear some discussion on how to reconcile the problem of the case selector data matching more than one case. This is a really neat Idea that could appreciably simplify syntax (I am currently working with Run-Time Menus, juggling the Item Path and Item Tag through nested case structures...)

Could a structure like the C "switch" statement be introduced??? A new breed of case structure that could execute multiple cases???

*** EDIT: I have Kudos'ed the Idea, with the understanding that it could be technically impossible to fulfill without creating a new class of structure. ***

[Intaris]

Maybe it would be a hybrid of a parallel for loop and a case structure with each and every case which applies (allowing for multiple valid cases) is run in parallel..... with the same caveats regarding input and output terminals of the structure.

It would be an interesting construct alright, but I would seperate it from the current case structure.

[JackDunaway]

---

@Intaris wrote:

Maybe it would be a hybrid of a parallel for loop and a case structure with each and every case which applies (allowing for multiple valid cases) is run in parallel..... with the same caveats regarding input and output terminals of the structure. This would be a different behavior than the 'switch' structure, which operates cases serially. I'm not saying parallel is the wrong way to go, maybe it would be advantageous, but just pointing out that it's different. If this structure were to operate serially, it would need something like shift registers.

It would be an interesting construct alright, but I would seperate it from the current case structure. Maybe so, maybe not... it could simply be a configuration of the case structure, or it may be more appropriate to introduce a new structure altogether.

---

[Intaris]

Given the parallel nature of LV I think parallel execution would be more fitting.  A user could always FORCE serial operation if neccessary.

[RavensFan]

Another complication to this is that the order that you define the cases will become so much more important.  With the current case structure, I can't think of any situation where the order of the cases matters.  You do have the option to reorder cases, but I have rarely found the need to do that, and really only matters to the programmer so that he can group similar cases together.  Or in the case of a state machine, have the cases ordered in the same way that you might naturally expect them to run in the normal operation of the state machine (Init, Step 1, Step 2, Step 3, Close) just to make navigation of the block diagram easier and more logical.

[Darren]

Any idea that has received less than 10 kudos within 10 years after posting will be automatically declined.