Add sparse enums to LabVIEW

[tst]

Today, the enum data type in LabVIEW only allows having sequential numeric values (0, 1, 2, 3, etc.).

It would be very useful to have sparse enums, meaning enums which can have custom numeric values assigned to their strings, just like you can do today with rings.

If you want an example where this will be useful, think of error codes - this would allow you to use an enum on the diagram to select the error, or in a case structure.

[maxwellb]

Just ran in to this today!

Sparse enums exist in C. Why can't LabVIEW have them?

[B3guy]

Kudos!!

[crossrulz]

B3guy,

Don't just say "Kudos", actually give the idea one.

[Brian_Powell]

I must have missed this when it was first posted.

We've actually had a lot of debate over this when we created sparse rings.  The original proposal was to create sparse enums, but we changed our mind and went the sparse ring route.  In short, the discussion was that enums should be "pure", and the numeric value should never be of interest to the user.  People who need special numeric values are probably interfacing with external code written in other languages, and there is no way to keep a LabVIEW enum in sync with an external enum.

As has been pointed out with the sparse ring solution, there's a deficiency in typedefs that ought to be addressed.  If you make a sparse ring a strict typedef, it will update if you add new values.  But if the sparse ring is a non-strict typedef, it won't update, since another ring value doesn't change the data type; it just changes the display.  Internally, I proposed that we create something between a typedef and strict typedef to support this, but it's never been prioritized high enough for us to implement.

Is there already an idea exchange feature for my proposed enhancement to typedefs?  If so, I'd vote for that over sparse enums.  There would be many details to think through.

[Dragis]

Brian, just adding a bit to your discussion. We have used probably 100s of enums in our projects and very few of those were to interact with external code. In almost all cases, an enum is simply a way to describe a union of a unique collection of values that are named so the code is more readable. In many cases having sparse values would have been very useful as additional work was done (through helper VIs) to convert the enum value to the appropriate "real" value (power of 2 scaling, flags, etc.). Being able to have a case structure without a default value that breaks when a new value is added to the set is a huge development time saver.

[NathanJD]

I've never understood why this wasn't already possible with LabVIEW.  It would be extremely useful since rings are not a valid alternative as mentioned previously.

[J.Harv]

I'm also very surprised this isn't already in LabVIEW.  This idea thread has been around since 2009 and I'm sure the idea has been discussed long before this.  Yet NI still hasn't implemented this?!?!  So far as I can tell reading this thread the only reason is they "want the enum type to be pure" at a huge cost to those of us that need this.  How many kudos will it take to get this improvement?

Our system has several thousand parameters. The numeric address are modbus registers. Certain register blocks are not full, thus, the numerics are not sequential.  Our desired use it to create an address lookup that is easy to use on the block diagram. Depending what the goal is, at any time 10-15 address might be needed in a new subVI.  An array of enum constants would be a very tidy way to do this.  String arrays are out of the question, to much of a hassle to type names and too much chance for human error.  We need drop down boxes. Once a selection has been made that should result in the appropriate numeric address in the code. Exactly like a sparse enum.  We've tried rings, but their constants do not update from a typedef.  Our solution was to create a cluster of numerics where the label was the name.  Then with an unbundle by name we get the desired functionality, but it's been hell to work with.  Throughout this project when we've work with NI, both support and  Systems engineering has said we shouldn't do this.  Both recommended enums.  Yes, I agree that's what we need, but to put spare's in as placeholders will ballon this enum, possibly up over 8 or 9000 items, erasing a lot of the ease of use, and taking much more memory than is needed.

Sparse enums really fills a need. There is nothing else in LabVIEW to achieve the same.  Our alternative solution to bend some other type to behave this way and has been a real drain on resources and the source of endless problems.  Along the way extra VIs have been created to support this hack and has created confusion among developers.  When we've had problems, NI support has even refused to help because "we shouldn't be doing it that anyway, just use an enum".  ....all this to get something that seems so clear and obvious it should have been in LabVIEW a long time ago. 

[ibmt]

This was pain many years ago when I worked wih register maps for embedded devices.

16 years later the limitation is still there. Would be nice to finally make LabView enums work

like SW engineers expect from other languages.

[MarkCG]

this would be nice right now

[tyale]

I'm just here to resurrect this thread.  This is a needed feature.

The mechanism of "NI prioritizes features based on 'Kudos'" is broken and it does not suit the needs of professional labview developers.  Maybe we should make a post regarding that.  I bet it will get lots of kudos before darren from NI locks it.