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.

[crossrulz]

Use Strict Type Defined controls.  This will lock down the properties of all of the instances, including the available values.

[J.Harv]

I appreciate the suggestion. Thanks.  I tried strict typedefs.  It was the very first thing I tried many months ago.  That doesn't work either.  From the help...

"When you save a custom control or indicator as a strict type definition, any data type and cosmetic changes you make to the strict type definition affect all front panel instances of the strict type definition. However, if you change a strict type definition, instances placed on the block diagrams as constants act as if the link is not strict, and LabVIEW updates the constant only with data type changes."

LabVIEW 2014 Help: Creating type definitions and strict type definitions

Strict type definition has never meant data values, only "cosmetic" changes (which doesn't even apply to the block diagram).  Regular type def is data type, strict is data type and cosmetics.  There is no way to link/propogate/update default values.

This is pretty widely discussed:

Knowledgebase 2QU94J6I: What is the Difference Between Type Definitions and Strict Type Definitions?

Knowledgebase 3Q5BTAL2 : Item Lists of Combo Box/Ring Constants Do Not Update from Type Definitions

Eyes of VIs: There are no strict type definition constants

[Intaris]

But how should the datatype know if I have set an Enum to "none" as a conscious choice or just because it's the default value.

That is to say, if I change the default value of the Strict Typedef from "none" to "some", how on earth should LV know which ones are default "none" and which ones have been chosen to be "none".

[J.Harv]

Intaris-  That's a good point about the default value, especially for the enum case.  Let's go with this for a second, if it were an option per control, meaning it could be turned on or off, there's no problem.  If instead of being a type of control, it was option on each individual constant?  Something like "Update default values from type def"  Then only those with the setting would update?  I don't know, just tossing around an idea.  What do you think?

Fact is, somewhere there is a lack of key functionality.  It's either the type that updates the way I want (enum) is missing the functionality to be used (configurable values) in our system OR the type that has the functionality I need (ring with configurable name/value pairs) doesn't update the way I need it to. 

[AristosQueue (NI)]

J.Harv -- the usual solution when I want a constant that I use in multiple places throughout the code but I want to be able to update in one place is to use an inlined subVI that just has a single output -- the constant value. Anywhere you use the Ring, you would be saying, "This is a unique instance that is specifically set to this value." Anywhere you use the subVI, you would be saying, "Use this specific value that I might update in the future." That's how I would do it, anyway. Does the solution work for you?

[J.Harv]

AristosQueue-  That is a good suggestion, and we're already doing that with the current implementation that has given us so many problems.  I view that as a workaround for the missing functionality.  Still does not directly address the need like sparse enums or the ability to update values on a constant from the type def.  Thanks for your suggestion though, it's definitely one workaround.

[AristosQueue (NI)]

It's odd to me that you view it as a workaround. Creating a support function would be the standard solution in any other programming language. 🙂 Indeed, that's how several of the "constants" that are in the LV palettes today are implemented. Please don't take that as dismissing your feedback -- I'm fully aware that graphical programming does create different expectations for supported features.

[J.Harv]

I see it as a workaround because that trick only partially works for our use case. 

Let me give some specifics.  Basically what we need is a giant list of name/value pairs (an enum) where constants would be placed all over the block diagram so the developer could select the name of the register address they want to use and the code would translate that to the appropriate register value. 

Enum is ruled out because the address' are chunked in groups of 100 to allow for expansion in each group.  If going by just that register value, it get as high as 13000, which is why an enum with lots of placeholders is very cumbersome to work with and has been ruled out.  It's possible we might end up with this anyway..? 

The current implementation is using a predefined cluster of numerics, so the name is the data type. This updates they way we want such that if parameters change it's reflected in all of the unbundle by names throughout the code. The register address is the value in the numeric.  We use the VI default value trick to make sure the right address go throughout the program.  There is a bit of a problem here where sometimes the default values are out of date, but there is a test for that in VI analyzer.  The real problem is the amount of memory that cluster uses crashes LabVIEW quite often and we've been told by many at NI we shouldn't be using a cluster that big.  Also having to use VI scripting to script the cluster (a 45 min process) each time you want to make a change is a problem.

I've been looking for an alternative.  Sparse enum is what I really want to use, but that idea exchange thread is from 2009 and several people at NI have commented.  It doesn't look like that will happen any time soon (if ever).  So, other ideas... A ring would be perfect, except no ability to update the constants all over the block diagram is a deal breaker.  The text combo box I could possibly make work along side the CVT or a variant lookup, but again no updates for constants.  So I'm out of ideas again.  That's why I posted this, it's another solution to consider and I wanted to see if this would gain any ground. 

Of couse I am all ears if there is a better solution out there.  Thanks.

[AristosQueue (NI)]

PolyVI? Put each constant in a different inlined VI. Put those VIs in a polyVI. Set the polyVI to always show the selector ring. User drops the polyVI, selects the value. Now you have name-value pairs with as much sparseness as you desire, selection ring, and constant folding in the compiler. Yes?

[AristosQueue (NI)]

Note that I've never done the above nor seen it done, but it seems like it satisfies your requirements with no downsides other than perhaps the file work needed to create the VIs.