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.

[drjdpowell]

Uh-oh.

When I experimented in 2.1, I found I could get the cluster names, by using "Variant to Data" to convert to an array of variants then using Get Type Info 2.1 which has a "name" output.  However, I see this output has disappeared in the 3.0 version.  What is NI's plan about supporting libraries that need this functionality?

[RERossel]

I just encountered this same roadblock the other day.

My use case is similar to the universal INI reader or JSON parser.

I'd like to create universal malleable Read and Write VIs where I subscribe to data via an 'Address String' in the form  'Server:Device/Property#Field' and I want to reduce redundancy in what has to be provided in the address string as much as possible - ideally to "none at all" as it's thankfully all in the wire labels already. In this case I'd like to take the 'Property' name from the 'Cluster Name' wired to the input - much like the intended use case for the ini file section names example mentioned in this thread. I understand we're in a strictly typed language, so we have to provide appropriate typedefs and labels at compile time - fair enough. So I use a malleable, provide the typedef I expect as an input to the malleable's Variant and the output Variant nicely adapts. 

All normal VIs, clones, inlines behave the same way and preserve the name. Yet only a VIM will lose my cluster name.

Since NXG seems to have been the killer argument for this thread and NXG is dead now, would it be an option to have consistent behavior now?

 

 

[AristosQueue (NI)]

> Since NXG seems to have been the killer argument for this thread

> and NXG is dead now, would it be an option to have consistent

> behavior now?

NXG was far from the killer argument for this thread.

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Malleable-control-labels/idc-p/3783378/highlight/true...

[RERossel]

Thank you for the very quick reply.

Re-reading with a rested mind, I realize that my last statement was rather harsh and I apologize for that!

I agree with the fact that changing the terminal name would be detrimental for scripting, as well as with the other objections stated. I'm unfortunately not familiar with how the Variant input terminal name of a malleable relates to the name of the data type wired into it. 

Testing with other VIs (standard, inlined, and clones), I just observed that the type name wired to the Variant input is always preserved and can be retrieved - except for inside a malleable VIM.

Meanwhile I have found a workaround which will solve my specific use case:
Using an unnamed cluster as 'ears' for the malleable and making a somewhat specialized but still malleable VI.

Thanks again for the discussion and your argumentation.
I appreciate your answering to this older thread.

[wiebe@CARYA]

>Testing with other VIs (standard, inlined, and clones), I just observed that the type name wired to the Variant input is always preserved and can be retrieved - except for inside a malleable VIM.

That is the problem. That works for variants, but a malleable VI changes the variant to the wired data type. So it's not a variant anymore.