Malleable control labels

[wiebe@CARYA]

I'd like to get an Malleable VI's input wire label from within the .vim.

It's convenient to use a wire's label in a sub VI, for instance to get a value from a file:

If the input is a variant, I can get this label from it. However, I like to return the same type that I wire to the input... A .vim can be used to make the output the same type as the input. However a .vim will fail with the label part:

The type info's label will always be "Numeric". The type adapts to the wire, but the label does not.

It would be really useful to me if the label of the .vim's input would change with the type, to the label of the wire that's wired to it. I'd think other would find this useful as well.

[AristosQueue (NI)]

> The type adapts to the wire, but the label does not.

This is intentional and will not be changing. All terminals should be named for its role as a parameter, not for its type. Sometimes those are the same thing (often occurs with "path", for example), but that isn't the case for terminals that are polymorphic. So if it is the index, then name it "index".

[Darren]

Declined for reasons listed by Aristos Queue in the idea thread.

[wiebe@CARYA]

Well, that kills a very good use case.

Tell me how to solve the problem then?

I don't thing you get what I mean...

[wiebe@CARYA]

It just sank in what you mend. So for a user, those inputs should have meaningful labels, given by the developer. I see how that would be something that needs to stay.

However, not being able to get the wire label renders .vim's useless for a lot of use cases. I still need to use variant inputs, and I'm still stuck with variant outputs...

Guess I have to start giving all those VI's that use the wire label string inputs... More work every time I use those VI's... Or wait for traits that might or might not have this feature.

[drjdpowell]

>This is intentional and will not be changing. All terminals should be named for its role as a parameter, not for its type. Sometimes those are the same thing (often occurs with "path", for example), but that isn't the case for terminals that are polymorphic. So if it is the index, then name it "index".

Wiebe isn't talking about data-type name, rather he is referring to the data label which is on all wires and is stored as a part of Variant data.  This is actually a parameter name, but it's the parameter of the higher-level calling code.  So it might be "Calibration file" rather than "path".

[drjdpowell]

As someone who makes Variant-based 3rd party libraries, I think this is a good idea.  I don't think NI has the internal experience with such libraries to properly access the value of this idea.

[wiebe@CARYA]

@drjdpowell:

Thanks, yes that is exactly what I mend. Not sure if we're all on the same page or not.

So one wires for instance a constant labelled "Calibration path" to a .vim's "Path" input. The .vim would then be able to get the "Calibration path" parameter from a, lets say, JSON string. And it can return it as a path.

I don't mind having to use a variant to get the label. There are other ideas for that. But for now it's either use a .vim and lose the label, or use a variant and lose the automatic data type.

Although the label would be changed from the .vim's point of view, the help and tip strings should indeed still display "Path". That is the label the developer gave to the input.

No one should be able to see the changed label, but inside the .vim we could get the label of what's connected. This would add even more power to the malleable VI's.

[drjdpowell]

Note, BTW, that VIMs do adapt to cluster element names, so it is sort of inconsistent to not also adapt to the main input-terminal name.

[wiebe@CARYA]

Regarding functionality (functionality intended or our purpose), that is inconsistent. It is indeed that functionality I'd like for all inputs.

Those labels inside the cluster are more or less part of the data type, so that choice does make sense. (But please do not remove the cluster element labels to make it more consistent! )

[AristosQueue (NI)]

> Note, BTW, that VIMs do adapt to cluster element names,

> so it is sort of inconsistent to not also adapt to the main

> input-terminal name.

Cluster element names are part of the data type (as is the element of an array). The wire name is handled independently throughout LabVIEW. The difference in handling is deliberate.