Ring String controlling a case structure

[WalterRebsch]

Using a ring control, it would be really nice if LabVIEW allowed the cases of a case structure to be defined by the ring contents, like an enum does rather than the ring value.  It would be easy to force it to have a default case to handle values that aren't defined by strings in the ring.  Just make sure you can still right click the case selector and tell it "add case for every value".  This would be very helpful when creating code to handle exceptions that return values in a ring and you want to handle each case.  It would be much quicker and less error prone than manually adding each numeric case that's defined in the ring.

[wiebe@CARYA]

That's not possible; those items can dynamically change while the case structure can't.

Also, the items are not part of the type, altough that's a technical problem.

Also duplicate:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Text-Ring-with-Case-Structure-Display-of-Item-Names-i...

[WalterRebsch]

It doesn't matter if they change.  Any undefined item would just go to the default case.  We could write code ourselves to do it using control properties to grab the ring text array (like this..)

Ring String

, but there isn't an easy way to make an array of strings load all of it's strings into case selector cases.  If there was an easy way to import an array of strings into a case structure's cases that would work also.  I just don't want to type in the whole list of items into the various cases.  It's tedious.  Computers are supposed to do the tedious work for us, not make more tedious work ...

[AristosQueue (NI)]

And what would happen when you change the strings in the ring to fix a spelling error? Or when the strings in the ring are programmatically changed while the code is running for localization? There's nothing in the type propagating these strings, so the Case Structure doesn't get updated and your code still runs but just stops working. It's really bad.

This is a frequently heard and frequently rejected request. Tying your user interface to your implementation code like this is extremely error prone, and LV R&D has repeatedly refused to admit it to LabVIEW.

There is a separate idea for a sparse enum type that would propagate the strings as part of the type. There is also an idea for localizable enums. Both of these are good ideas that we would like to get around to someday.

[Darren]

Declined for reasons listed in response by AristosQueue:

"And what would happen when you change the strings in the ring to fix a spelling error? Or when the strings in the ring are programmatically changed while the code is running for localization? There's nothing in the type propagating these strings, so the Case Structure doesn't get updated and your code still runs but just stops working. It's really bad.

This is a frequently heard and frequently rejected request. Tying your user interface to your implementation code like this is extremely error prone, and LV R&D has repeatedly refused to admit it to LabVIEW."

[WalterRebsch]

They have existing code in LabVIEW to update the Enum string values when you edit them.  They could do something similar.  Perhap allow a right click option of "update from string array"?  Then it would update the spelling of any items that changed.  If new items showed up, it would create blank cases for those items?  Anyway, I think these items can be handled.

VI server has lots of options to tie your user interface to your implementation code.  I don't think it's a drop dead and it doesn't have to be completely bullet proof.  Nothing in programming is bullet proof.  It's just a string of minor things to help up write code easier, faster and better.  If there are potential gotchas on certain things, they sometimes add an extra dialog like they did when you modify enum cases and LabVIEW can't automatically figure out which value to pick for something that's disappeared.

[wiebe@CARYA]

>They have existing code in LabVIEW to update the Enum string values when you edit them.  They could do something similar.  Perhap allow a right click option of "update from string array"? 

You'll run into all kinds of problems.

An enum has a defined order to it's elements. A case doesn't. What if the ring changes order and strings? What if strings match, but in a different order? For an enum, this is defined pretty well. For a ring, it would work sometimes, and introduce nasty bugs the rest of the time.

If you really want that functionality, you can make it with scripting. It will only work in your situation (if at all), and not in a general case.

Also, duplicate.