Read-only globals

[blackburnite]

Sometimes I want to have global static constants which I can read in multiple different places and update in only one.

I either have to do this in some clunky fashion with an in-lined VI that just has a constant on the block diagram which gets wired out, or I use a global variable with default values set and just never write to it.

The global variable option is a way cleaner implementation but has the disadvantage that there isn't technically anything preventing it from being written I just have to rely on/promise that I (or anyone else) won't write it.

I would be awesome if there was a property which could be set on a global which allowed it to only function in the read direction.

[OneOfTheDans]

I agree with the use case, but would prefer to see a new Constant Variable type instead of a mode flag on Global Variables.

[blackburnite]

Yea, I thought about that as well. I don't know which would be easier to implement under the hood. I'd be ok with either.

[Petru_Tarabuta]

+1. I support the sentiment of the idea. Just like OneOfTheDans mentioned, I too "would prefer to see a new Constant Variable type instead of a mode flag on Global Variables".

LabVIEW would 100% benefit from having Global Constants.

"I either have to do this in some clunky fashion with an in-lined VI that just has a constant on the block diagram which gets wired out, or I use a global variable with default values set and just never write to it." - I too am unaware of any other workarounds. Both existing workarounds are a bit of a bodge. I use the first one, namely a VI that has a constant on its block diagram which gets wired out. It seems safer than the second.

[MandatoryAlias]

The way I handle this is I create a labview library (.lvlib) and create the global as a member of that library, scoped as private.  Then I create accessor subvis that are public.  It's tedious if you have lots of variables, that's for sure.  But I feel like it's one of the only ways to work with global variables safely.

[fefepeto_kb]

I can think of some ways in improving how constants are being created and handled in LabVIEW (right now they are only implicitly handled), but I don't think that hijacking existing features would be the best way to achieve this.

In my opinion there should be something, that more closely resembles a control, than a VI that would store my constants. Then those constants should be assignable to different access levels, like for the whole project, inside a library or class, or constant provided by the library to all its callers.

Sometimes there might be a need for VI level constants too, but this would be a corner case, and might not be necessary to add a new concept beyond the existing solution of the way too easy to modify nodes on the block diagram.

All in all, I agree with the need of constants, but I don't like using global variables to achieve this. To be clear, I use the inlined subVI with indicator to provide the same functionality, but this also feels too much effort and too much information stored for specifying a named value, that doesn't change.

[blackburnite]

It wouldn’t have to specifically modify the global variable, but I like that form factor in terms of being able to drop multiple elements on a block diagram and then select between them via the variable node, without having to unbundle a wire or otherwise have potentially many VI outputs in the case of the inlined VI approach.

I do agree that it probably would be better as a separate item versus a modifier on the existing global but would largely function the same way from a UX perspective but with no ability to write to it. Scoping could be achieved by dropping it into a library or class the same way you can with VIs or controls

[wiebe@CARYA]

What's the benefit of a read only global versus an (inlined) VI with a control output?

The VI doesn't even need a constant, as the control output's default value is used.

As a bonus:

There can be more than 1 output per VI

This works with a DD input (not the inlining though)

[blackburnite]

The benefit is UX/convenience.

DD I have to provide an input object and use multiple VI terminals if the output types are different. The global variable node, I can just select which element I want to read and the elements do not have to be of the same type. I can't do that with any VI-based implementation.

They all have some drawback either requiring and input to "select" the constant I want, potentially wiring multiple VI output terminals to support different types, or having to create multiple VI variations with something like a polymorphic VI solution, or output a cluster and unbundle it.

None of them are as clean as how the Global variable node works, except that I don't want to be able to write to it.

[wiebe@CARYA]

The DD is optional. Don't do it if you don't want to.

In the VI solution you can just rewire to another output of the VI. Types don't have to be the same.

I agree that there's a minor difference in UX, but to say it would be "a way cleaner implementation" is a bit of a stretch.

I will +1, because restricting a global is an improvement on an unrestricted global.

Even better if this is indicated in each instance. No programmer would even need to search for global writes.... 

[Yamaeda]

If you make a FGV where First Call? is used to write to the shift register you'll have that functionality, write once.