Adding CONSTs to LabVIEW

[tst]

I would love it if LabVIEW had logical constants, similar to what other languages have. Basically, a logical constant is similar to a variable (i.e. it's a value which is assigned a name), but its value is set at compile time. CONSTs help code readability.

In LabVIEW, a CONST would basically be similar to a global variable, with two differences:

1. It would be read only (so no race conditions, everyone can relax).

2. Changing the value on the front panel of the CONST VI will automatically require the user to save the VI, without needing to manually set the new value as the default.

Today, you can implement these in LabVIEW using all kinds of methods, but non of them is as convenient as this.

[altenbach]

Could that be something like an "even stricter type definition" (I am sure we can find a better word! :D), that also includes the value as fixed?

Changing the value would involve editing the ctl (or whatever it will be called).

[tst]

I don't want to have a separate file for each CONST. We can do that today by having a subVI.

Two advantages globals have over this is that you can have several in a single file and that their name is prominent in the diagram.

[RavensFan]

It almost seems like when you define constants in a Declarations section of a text based language like VB.  It is code in some ways never really runs, but its presence in the file has meaning to a compiler.

This leads to some other questions.  In text based languages, you can define consts as being global/local, or public/private.  How would you implement that in a LabVIEW VI.  If you define a constant in an upper level VI, is the definition of that constant available to all subVI's the upper level VI calls?

[JackDunaway]

Implementation: Simply have a right click menu item called "Read Only" on the Global definition, and use the already-present functionality of "Make Current Value Default". Would that be a viable solution, tst?

[Intaris]

You can also have a single VI outputting a cluster with all your Constants in it so the VI count increases by one only, not one per constant.

I see the convenience but I question the benefit.

[tst]

> use the already-present functionality of "Make Current Value Default". Would that be a viable solution, tst?

Only if you don't have to manually set the new value to be default.

> I see the convenience but I question the benefit.

You're absolutely right. This is more about convenience, but there is also a benefit in the final appearance of the code:

In any case, convenience is also important. It might not make business sense, but I'm sure many of LV's regular users wouldn't mind if NI dropped off the new features race for a year and focused on bugs and usability.

[JackDunaway]

In all seriousness, this is the core of my participation on the Idea Exchange: "It might not make business sense, but I'm sure many of LV's regular users wouldn't mind if NI dropped off the new features race for a year and focused on bugs and usability."

[LabBEAN]

Ditto.  And, I enjoy learning from the feedback on the various ideas (e.g. Christian's coercion post).  We'll see if their listening... 😄

[altenbach]

Even NI has not fully embraced the concept of "constants". The ones in the numeric palette are fine (Pi, etc.), but have you ever double-clicked the "space constant" from the string palette? 😄

[tst]

> ...but have you ever double-clicked the "space constant" from the string palette?

I have noticed it's a VI in the past. That's probably because it's easier to create a VI than the relevant C code. It's the same thing with the True constant in the boolean palette (the constant itself is not a VI, but it's placed in a merge VI). In any case, creating something like that once for merging on a palette is not the same as the needs you have in everyday development.