Project #Defines or Project Variables

[MikeeB]

The concept is to have a project level #define or variable where a value of your type can be set. This is to allow the user to change constants across multiple targets. Wherever this is called in code it will be set when the run button is clicked and then be static until it is run again. The same would happen when a build is run that the value is set then and never again.

This would allow multi target configuration quite simply and make for some more readable code when you a constant referred to at multiple levels or across large chunks of code. Instead of having a wire to span these sections or being passed down multiple subVIs it would just refer to one point, much as a #define in C

Project

Then calling code for targets

[drjdpowell]

I think the "Conditional Disable Structure" provides this functionality. 

-- James

[Mr.Mike]

drjdpowell is correct in that you can do what you described using Conditional Debugging Symbols.  However, I don't believe you can access these symbols on the block diagram.

[stbe]

I don't like this idea because I think it will not make code more readable.

I also wouldn't use this feature, since I do target configuration with a set of *.ini files. With them, I don't even need to build or recompile anything if some attributes or values change. Just reload the config or restart the program and it's done.

-Benjamin

[AristosQueue (NI)]

This is a MUCH NEEDED idea.  Mike Bailey's use of it for targets is kind of a red herring -- we need this just to control compilation, regardless of whether targets are involved or not.

Currently, as Mr. Mike notes, you cannot get the Conditional Disable Structure to give you the value of the conditional symbol, so you cannot conditionally define font sizes, or optimization levels, or any of a thousand other things.

Defining them as conditional values means that I *can* recompile them. Stbe says he'd rather use a config file. There's a lot of stuff that can be precomputed as a constant, if only we knew to do it, rather than making it a run-time value. The LabVIEW compiler keeps getting smarter about memory management and constant computations can eliminate huge amounts of runtime overhead.

[Dan_DeFriese]

I don't like this idea. If anything, I would prefer a global variable VI that could have access properties set by the owning Library/Class. I can just imagine the headaches I would have when I try to move a VI(1) from its original Project, which defines a Project constant, and later try to use it in a new Project which hasn't defined this constant. 

(1) Especially if the VI was written by someone else, or worse, written by me a few months ago...

[Norbert_B]

While i understand the request and see much demand for it, i think that LV currently is not suitable for a *alround answer*.

Looking into your code, the constant will pass a value of '0' as the reader will see it. A link to a project definition could result in some other values to be passed on during runtime (THIS is the purpose of your request!), but the code does not show what the actual value is for the actual target!

The current answer from LV looks like this:

I understand that this is not very handy when talking about several symbols (e.g. more than 5). But on the other hand, even if you have more than 5 elements effected by this request, isn't it possible to collect combinations of settings to configuration sets whose count is less than 5?

Considering your suggestion will only be worthwhile, if the "instances of the defines" is not displayed by constants of the given data type, but a dedicated "Symbol Value" constant similar to a global variable:

Norbert

[tst]

> If anything, I would prefer a global variable VI that could have access properties set by the owning Library/Class.

You can do that today - just put the global in the library and set its access scope to private. Then, no one outside the library can access it.

[tst]

> Considering your suggestion will only be worthwhile, if the "instances of the defines" is not displayed by constants of the given data type, but a dedicated "Symbol Value" constant similar to a global variable:

That seems similar to this - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Adding-CONSTs-to-LabVIEW/idi-p/942213

[JeffreyH]

1 kudo from me, but only if this (and the currently available Condiftional Disable Symbols) gets implemented to make it possible to set them on the build-spec level instead of project level!

[sbus]

I want the functionality of #defines. But I think we would accomplish the same thing if we add the ability to place Conditional Disable Structures on a Global Variable container; that way we could set global variables based on Project Variables. This allows us not only to set the value of globals based on conditions such as platform or application specific project options (such as compiling a version of your program that supports a particular piece of hardware) but it also lets us set global variables to match the value of the project variable inside a Conditional Disable Structure, effectively letting us 'get' the value of project variables.