An idea on the exchange I'm wondering if everyone overlooked

[Aristos Queue]

An idea got posted last week for improving conditional compilation symbols. I saw it today as I was reading my backlog of ideas, and I quickly Kudos'd it. Then I noticed I was the only the second person who kudos'd it. Really? I would have thought that an ability to set constants in the project file and use them on the block diagram would have generated more interest. Is this really something that most of you would not use? [Note that other ideas posted after this one have 25 to 44 kudos on them, so I'm sure people have been looking at the Exchange during this time, but just passing over this idea.]

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Project-Defines-or-Project-Variables/idc-p/1982619#M18012

[asbo]

I know that on more than one occasion, I've wanted to do this exact thing ever since projects were introduced (that is, use conditional compilation symbols with more flexibility). The workaround I've always seen and used myself was to place the constant in a subVI and place the subVI where necessary. Thinking about it now, I don't know if scoping these constants will always be beneficial - what happens when you load the VI outside the project? You can also argue that the sybVI method can be more readable because it allows you to use a glyph to describe the constant (but that can go either way per developer).

The argument you can, from the standpoint of compiler optimization, could be awesome, but I never really considered it from that angle.

Either way, I kudos'd the idea because I agree that the feature needs a refresh to unlock some valuable potential.

[drjdpowell]

It wasn’t/isn’t clear to me what this idea is asking for that the conditional disable structure doesn’t already do. Could you give an example?

[crelf]

I'll kudos your idea if you kudos mine: http://forums.ni.com/t5/NI-TestStand-Idea-Exchange/Add-quot-Project-Globals-quot-and-or-quot-Workspace-Globals-quot/idi-p/1148493

[ShaunR]

I would have thought that an ability to set constants in the project file and use them on the block diagram would have generated more interest.

\resource\plugins\utilities\IfDef.llb\SetSymbols.vi/GetSymbols.vi and the conditional disable structure does pretty much everything.

Edited May 8, 2012 by ShaunR

[MikaelH]

I've also needed this option in the past.

Do we also need to be able to set these variables for different builds as well.

Maybe I would like to build the same Exe File with different values of a variable.

Currently I have an application, that changes behaviour depending on the Exe-file name, but it's based on the same Top Level VI.

To solve this I would prefer to just change a #Defined variable, this could be solved by the Pre and Post build VIs but I think that would be quite ugly.

[mje]

I didn't kudos the idea because I don't like it. I don't see much use for having the symbols be available on the block diagram per se. I can't think of a use case where it would be proper to want to display that information or react to it at run-time in light of other available features. Now that we have inline VIs I believe they are much more suited to the task when you need to react to constant values outside of a conditional structure.

To me the purpose of symbols is to resolve issues before run-time. If you need to display a symbol on the front panel, or react to the "value" of a symbol at run-time, I'd suggest you'd be better served by reexamining what you're trying to do. Still, if you're determined to do it, there are existing constructs that can do as much.

However I do understand why someone would want this idea, it's similar to the use of #define vs static const in the C languages. I lean on the side of using the actual const because it comes along with type safety, debug info, scope, etc-- but I would be lying if I said I've never used a #define to hold actual values used at run-time.

That said there is some functionality sorely lacking as far as symbols go. Like Mikael has stated, the inability to define them at the build spec level is a particularly big oversight in my opinion.

[JamesMc86]

Ditto regarding builds. Just being able to have one debug and one deploy build spec would be great (functionality I normally implement with conditional structures)

(null)

[Rolf Kalbermatter]

An idea got posted last week for improving conditional compilation symbols. I saw it today as I was reading my backlog of ideas, and I quickly Kudos'd it. Then I noticed I was the only the second person who kudos'd it. Really? I would have thought that an ability to set constants in the project file and use them on the block diagram would have generated more interest. Is this really something that most of you would not use? [Note that other ideas posted after this one have 25 to 44 kudos on them, so I'm sure people have been looking at the Exchange during this time, but just passing over this idea.]

http://forums.ni.com.../1982619#M18012

Personally I would prefer if this setting was also available in the Build Specification Properties (and would overwrite a default setting in the Project Properties) than being able to access them in the diagram in any way.

Currently I have to make different project files (or use the Pre/Post Build VIs to do some undocumented magic to change those symbols) if I want to have different builds depending on such a symbol. This shouldn't be necessary at all if the conditional symbols idea was properly implemented for the project and not only added as a sort afterthought.

I do understand that this can get messy to implement with some settings inheriting from other places and overwriting them in a clear and consistent manner, but that is what I expect from a modern project management tool. And I have refused to use some Microsoft Visual Studio versions because they had some weird inheritance problems with project settings.