Many programming languages have a means to define a constant, use a label to refer to that constant, and then at compile time replace that label with the constant. This allows the programmer to set a value one place in code and then use it in many places without additional overhead. This is often utilized for array indices, seldom changed parameters, conversion factors, etc. For example, in C this takes the form #define label value. LabVIEW, as of version 8.6, does not directly support this functionality. Sure, there are several workarounds including the use of global variables (which adds overhead), subVIs (which may add overhead and at a minimum get cumbersome), and conditional disable structures (which aren't practical for constants that may contain a large range of values). This overhead is especially significant when programming in the Real-Time and FPGA modules.
Using the newly released VI Scripting I have created a VI that replaces the values of specifically labeled numeric constants with the values contained in one or more configuration files. The program operates recursively within a directory structure such that a particular configuration file can be applied to a single directory or an entire project. This is far from an ideal solution since a manual step is required whenever defined value is changed; however, it allows the programmer to use constants without the trouble of manually updating each copy whenever the value changes. Note, that this is not meant to be a substitute for using configuration variables for parameters that change often or within a built application.
The attached file contains my program and an example directory that demonstrates its use. It even demonstrates how two definitions for the same constant are handled.
While the program achieves basic functionality, it is far from polished. There is very minimal error handling, some modules/toolkits might not be supported (though the recently disclosed traverse function probably would address that), and the program architecture was designed for simplicity rather than flexibility and future expansion.
