Showing results for 
Search instead for 
Did you mean: 

Best way to store constants

Nickerbocker wrote:
@Rob - I just went through your little example but trying different types of rings...and wow...that is really frusterating.  Is that a LabVIEW bug or a design decision?

Not a bug. See here: Item Lists of Combo Box/Ring Constants Do Not Update from Type Definitions

0 Kudos
Message 11 of 14

Hi! I found this forum thread through Google, 10 years on. 


Storing constants in any application is vital, and I think coders expect, or at least want, it to be easy.


This thread suggests there's no easy way to store constants in LabView -- at least no method which is robust or especially suited to the purpose.


Can anyone help me update this thread with a conclusion of the actual best practice(s) for this fundamental requirement?


Thanks in advance!




PS - By constants I mean data of any type that is set before an application is compiled or run; remains read-only during application execution, and can be accessed globally throughout the entire application. Constants are label:value[s] tables in locations having universal read access and nonexistent write access. Naturally, as with any other programming language, a pre-runtime architectural change in the label:value[s] must propagate automatically through all application code, in a way that's synchronized and clear to the developer. What I'm describing here is the behavior of constants (as well as macros or defines) in Microsoft Visual Studio and practically any other IDE I've worked with. It would be very helpful to have a direct functional equivalent in LabView.


0 Kudos
Message 12 of 14

Generally I use a VI (e.g. a function that returns a constant value) for the use case you describe. Searching for VIs is fast, and it's easy to update this way while ensuring it can't be modified outside of the dev env. Setting the VI to "Inline in caller" removes the overhead associated with the function call, so this should be quite fast. Whether the data is stored internally as a block diagram constant or as the default value of an (unwired) control doesn't make any difference.


Here is a sample project (LV 2018) that shows a few other ways to do it. I've included an example of using a conditional disable symbol to create constants that depend on e.g. the target product.


I don't recommend using a bare typedef control with default value for this purpose as the value won't globally update. Using a class is appropriate if you want to limit scope.










For more complex data types, I typically store the data in json format and deserialize it using JKI JSON so that.

Message 13 of 14

Really nice reply, Rob and thank you!

I'll keep your material as a reference and consider it a best practice.

It seems to me like what you wrote would belong in a knowledge base article. 



0 Kudos
Message 14 of 14