LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 

Conditional Disable Symbols settable in Application Builder

Status: New

I use the conditional disable structure in my projects to turn debug options on and off.

At the moment before every build I have to go into the project properties and make sure that DEBUG variable is set to FALSE and after the build I have to change it back.

You can get around this by automating you build but an option in the build specifications would simplify this.


It would make life much more convenient if there were a list of the available (non-system) conditional disable symbols in the application builder dialog where the appropriate variables for the build could be set. This would also allow for a simple duplication of a build spec to have one with DEBUG=TRUE, and one with DEBUG=FALSE.


Completely needed!!!

With this feature, not only will we be able to switch from DEBUG to DELIVERY, but we can also plan to compile for a hw configuration or another, a fully functionnal or limited options application, and so on.




I'm using conditional disables to include a simulation mode (running without hardware, eg. for demonstration and training purposes) in many of my projects. And as some of the above already said: YES, it's boring to change the projects properties every time compiling for test and actual application using the hardway. Forgetting to do this I already provided a package compiled in simulation mode for download by my customer.


-> Having the conditional define being part of the EXE build would prevent this and I would be able to debug/test in my office (I have NO hardware here) and roll out the new EXE for the customer without changes in the project.


I have a program that runs in two modes: demo, and 'real'. The difference between the two is wholly controlled by... A conditional disable symbol. I use separate builds to rename the output executable, select different icons, select debugging and logging options, and build using the different values of the conditional disable symbols. I too have to change the symbol'(s) values, build a project, change the symbol(s) values AGAIN, build another project, and (in my case it's worse!) change the symbol(s) values AGAIN to go back to development mode when NOT creating a build.


I too think that conditional disable symbols should be available per-build as well as per-project. So my suggestion would be to include build-specific conditional disable symbols as an option when you right click on the build specification and select "properties".


What I want is values of conditional disable symbols that are specific to each build. I don't much care if you can define new symbols that are available in the build, but are NOT available in the project. In fact, I think since the whole point is to share a code base, the conditional disable symbols should ALWAYS have to be defined in the project, and the ability to create conditional disable symbols (instead of just set their value) should NOT be available per-build, only per-project.


So here's my pass at the implementation:


A "Conditional Disable Symbols" option should be added to the Properties category of build specifications visible when you right-click on a Build Specification in the project explorer window and select "Properties". It should:


1. Have a screen almost identical to the Conditional Disable Symbols screen under Project->Properties, except that the "New Symbol" and "New Value" fields and the "Add" button should NOT be present.


2. Display the project's list of already-defined conditional disable symbols, and allow you to set the value that they've when THIS build is performed.


3. There should be checkbox called "Use Project Values" that grays out all conditional disable symbols and always uses the value they are set to in the Project (this should be the default).


4.  If the "Use Project Values" checkbox is NOT checked, then each symbol can have it's build-specific value set.


5. There should also be a button to "Restore Project Values" to the build-specific conditional disable symbols so that you can easily restore the value of the symbols for a build to match a project available (enabled) only when "Use Project Values" checkbox is NOT checked.


Also: Conditional Disable Symbols (Project- and Build-specific) should work with executables created to run with the LabVIEW Run Time Engine.


Why hasn't this been implemented yet?


I would also have a need for this feature.

I tried the work-around provided by Dan DeFriese in but it is no longer working in LV2013.


That would be so great. No need to remember 10 different compile variables to be set in the right way....


sbus layout would work excellent for me.  Another option would be to expose the project conditional symbols to VI scripting and then we could set them in a prebuild script.


How is this still not implemented? What is even the point of conditional disable without this? It has an extremely narrow use when wanting an automatic way to change the code in, say, an LLB vs an EXE, but in practice I find myself wanting to use a conditional disable frequently, and then 99% of the time abandoning it because I can't tie the symbol to a build configuration.


I use the <LV_INSTALL_DIR>\\resource\plugins\Utility\IfDef.llb library and a prebuild script that queries the dev for the status of each conditional symbol.  This works well but must be specifically configured per project.  I will do a writeup on the forum when I get time.

I am not saying this is fixed, only that I have a decent kludge which allows turning options on/off at build time.


Yup, I was implementing a similar kludge when I got the reply notification email. Basically, generate a pre-build action, and then you can either use a different action VI per build config, or use the same pre-build VI for every config, and simply check the name of the config. Either way you set the symbol accordingly in the pre-build action.


This functionality is significant enough that it's worth the kludge, but there should be a direct option to set a conditional disable symbol per build config. 


If anyone can't figure out how this works feel free to message me (or randol, except I can't speak for him).