LabVIEW Idea Exchange

[#1]

Hi all!

I know the title doesn't make sense, so I will try to explain.

I think it would be a good idea to have a way to define values similar to the C instruction #define. In C code, you can define constants and change its values all over the code during development time.

Right now, there is nothing like this in LabVIEW. You can use controls and variables, or controls and property nodes.

(Strict) Type Defs for controls have kind of the same philosophy, you change things on a single file, while all the instances are updated (but there is no way to define a single value for all the instances of a control). I guess in LV it would make sense if we could define a constant file, and place it in every block diagram that we want to get that value.

Don't you think it would be a good idea?

I tried to define a Strict Type Def with a range where only one value is possible, and the coercing options. Anyway, the behaviour is not what I expected, as it seems that the control doesn't look at its own properties until you try to change its value. If the control has a default value of 4, and you change the valid range to [5,5], the control will have the 4 value until you try to change it (and then the value will be coerced to 5).

I don't think that is a good behaviour, do you agree?

PS: I think it would be great to have a "User Defined Type Def", in which you could define the things that stay the same and the thing that doesn't, but I know that idea is not mine .

Regards!

[#2]

I think it's very useful, almost necessary, to define CONSTANT (e.g. number of channels, times, ...) that are known at compile time.

This is somewhat similar to "# define" as used in C.

[#3]

Like this?

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Adding-CONSTs-to-LabVIEW/idi-p/942213

[#4]

Create "constants.vi" consisting of nothing but a bunch of meanigfully-named indicators wired to the connector pane and set to the constants you need to use elsewhere.  Paste it in wherever you need to reference a constant, and inline it for speed.  Change it in one place and it instantly changes everwhere else.

Is there any funtionality or use case you need to address that the above doesn't satisfy?

[#5]

Yes tst, that's kind of the same idea (I have already kudoed yours )

And yes rgvdh@rdf, that would be a workaround, but, as discussed in the link tst provided, or up here, I am not saying you can't have that functionality (variables, property nodes, files...), I just think it would be a good idea to include something like this.

[#6]

I just don't see the point of creating a whole new type of object when an existing object (subVI) does the job (of having you be able to change a constant and have the change propagate.) The term "workaround" only applies if your method would be less effort to program with than mine, and I don't really see how it would be. 

With the subvi approach, you can even make the values of your constants be environment dependent by embedding different constant VIs in a conditional disable structure.  I'm having trouble figuring out how to do that with typedefs.

What is the advantage you anticipate in using a special kind of typedef rather than a subVI?