Force typedef constant default value update

[J.Harv]

I searched but didn't see this idea anywhere yet.  There is problem with ring and combobox typedef constants.  Since the values are not actually part of the data type (like an enum), when a their typedef values are modified they are not propogated like you'd expect.  Since I've run into this problem I've seen a lot of posts, but not real solution. Search and replace hundreds of constants...I suppose.. Anyway, most assume this is a bug, but it's not.  See link below. 

Item Lists of Combo Box/Ring Constants Do Not Update from Type Definitions

While not a bug, there is missing functionatlity here, as is evident by the amount of posts, questions, and confusion around the topic. 

The idea is simple, make some way to force typedef constants for rings and combo boxes to update, not just "data type", but default values.  Maybe a 4th typedef type that includes data values?

**Side note (and plug for a related idea):  One motivating factor is the lack of sparse enums.  If you have large spread of name/value pairs, an enum could require hundreds of unused value "placeholders" which makes it too large and cumbersome to use. Either a ring with the appropriate values (that could update) or a sparse enum would probably help many people.**

LabVIEW idea exchange: Add sparse enums to LabVIEW

Thanks for reading.

[J.Harv]

Wow, clever solution.  I have never seen or heard of doing that either.  Makes sense after I see it written out. I will give that a shot here shortly and let you know.

[AristosQueue (NI)]

Part of the reason I've never done it myself is that the few times I've needed this, I've not bothered building the polyVI... I just create the constant VIs that I need and put them in a palette. That suffices to find them with QuickDrop and makes them browsable if people need to think about which one to drop. A unique icon is generally enough for me instead of the ring, but I can easily see why people like the ring.

[J.Harv]

I still haven't gotten a chance to try it, I was pulled off this work for an "emergency".  I was thinking though, with this implementation there isn't a way to easily handle large amounts of values.  For instance, let's say I need 20 values, I have to drop 20 VI's and then handle each separately?  I could build an array, etc.  Right now it's very similar to how the values from the cluster are handled except the cluster unbundle is contained, easy to grow, etc.  While these are convenience things and can be worked around, this still doesn't feel like it's the solution I'm looking for, or the one I've asked NI for  (either sparse enum or forced constant updates).

[Intaris]

This sounds like a good candidate for scripting the polymorphic VI

[AristosQueue (NI)]

I'm not closing the idea. I realize that this isn't what you've asked NI to build. I'd like to see how far you get with this solution and see if that changes the nature of your request. It may just be that we need better editor support for building up the polyVI instead of a new type of control.

This should help speed things along... I wrote this to automate the creation of the polyVI. You probably want to tweak it a bit (I didn't make the polyVI's name customizable I just realized), but it covers the biggest part of the work.

https://decibel.ni.com/content/docs/DOC-43042

[paul_cardinale]

Put this line in LabVIEW.ini

     EnableStrictTypedefConstantConfiguration=True

Then when you place a Ring or Combo Box on the block diagram, right-click and "select “Act as Strict Typedef Constant”.

[AristosQueue (NI)]

I would not advise using unpublished ini tokens in production code. I've never heard of that config token myself, and if we added something but never productized it, there's usually some issue with it. It might work, but I advise against it.

[paul_cardinale]

I don't worry about "EnableStrictTypedefConstantConfiguration" for deployed code because it only affects the behavior of "Apply Changes", which is never executed at run time.