Structure that allows constants to be generated at compile time.

[Taylorh140]

I posted This on the Idea exchange a few days ago. I have been wondering why no-one sees the need for constant generation at compile time. I think this would be especially useful in FPGA, but also for constants that need data from the build environment. Perhaps there is just a better way of doing these types of operations? Let me know what you think?

Quote

I envision a structure much like a case structure, in which you select your event for evaluating the code inside the structure and the values become constants at the node. The interior would allow code that may normally not be able to run on the host for example, on fpga it might allow the use of doubles and strings and resized arrays, because it isn't actually going to be executed on the host just evaluated and stored as a constant. This would allow for more configuration for fpga and even have some benefits at the traditional desktop environment. For example you could set the structure to evaluate on app build and produce a string constant that is the build date so the build date could be shown on UI to help distinguish builds. 

 

[smithd]

This seems like it would be pretty easy to do using a pre-build step. Is there something you had in mind which isn't solved by this? (Also, on FPGA you can do something like this using VIs to define initial contents of memory)

As for the popularity of the idea, I'm actually kind of surprised the idea exchange still has as much activity as it does -- 85 whole kudos this year -- considering nxg. Anyway, some ideas in the same vein:
https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Conditional-Disable-Symbols-settable-in-Application-Builder/idi-p/924581
https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Conditional-Disable-Symbol-Constants/idi-p/1034752

The first would solve my main issues. The second would be neat, and I've occasionally wanted it in the past. I'm not really sold on the value of what you've described outside of the compile time you show in your post (which is not something I've ever personally implemented)

[Taylorh140]

I typically view the conditional disable as a different kind of item. Not really that different from a case structure with a global written to the conditional terminal. Run this code or that code depending on the configuration of the system. But code is still run on the production environment.

This idea is a bit different because the code is run only on the development environment. The idea is in some ways a very convenient prebuild step. Also it increases consistency. Why do prebuild on pc and vi memory initization on FPGA when you could do it in a uniform fashion. Why not use LabVIEW as its own pre-processor?

Value would be for things like reading configuration files from the development PC, that i don't want editable in production. Easily Labeling the front panels SVN REV and build time. Perhaps event reducing startup time for LV apps by preprocessing startup code.

To me I feel like this would be a great additional structure. I do appreciate your thoughts on the topic, thanks.

[infinitenothing]

Not sure if we're still doing this but there's another subform for ideas:

https://lavag.org/forum/37-labview-feature-suggestions/

[hooovahh]

39 minutes ago, infinitenothing said:

Not sure if we're still doing this but there's another subform for ideas:

That's all the request I need, thread moved.