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)]

> So this makes it a call site metadata input. Right ?

That's my idea, yes. I really don't know how viable it is, but it seems like it would work... although, I described it to Jeff K the other day and he replied with downer message including a comment about how type names really aren't a well-defined part of the type prop algebra and we should be careful about extending in that direction. But he didn't exactly say "no." 🙂

[drjdpowell]

>Does that settle your nerves

No.  I've long thought there is a blind spot at NI as to the value of advanced Variant handling.  I think because NI developers introduce advanced functionality via LabVIEW primitives, they do not think about how 3rd-party developers can provide important extensions to LabVIEW.  A full Variant capability is needed for that.  Originally, this had to be hacked out of flattened data by the OpenG developers.  Only lately has proper capability been part of LabVIEW itself, and even that is sadly incomplete.

There is a strong danger that NI will drop critical functionality because of this blind spot.  

[drjdpowell]

I note there are multiple 3rd-party libraries on the LabVIEW Tools Network that can never be ported to NXG due to this change, including my JSONtext and whatever library Wiebe is now developing.  Was NI aware of this?

[wiebe@CARYA]

(BTW. I had some priority coding to do, still reading this).

If there ever will be some sort of type trait, that provides this kind of functionality (and hopefully more), I'd have no need for this anymore...

I think there are more people that benefit from this then people that will suffer from it while they are scripting against a .vim (although those people are probably more significant in the idea evaluation process). It's not just all the developers that could use this to develop, but also all the people using the libraries they make.

Losing the label of a variant is problematic. Also because it's the only thing that comes close to a .vim alternative (since .vim's don't pass the label).

So instead of gaining some functionality, we'll soon loose the only alternative that comes close, and that we've been using for years. It's a sad sad day ... 

[AristosQueue (NI)]

> Was NI aware of this?

NI? I don't know. Individuals within NI? Yes. The right individuals? I don't know. Personally, I rely on various aspects of the variant type library for my own work, and I think that the NXG APIs expose the needed data, albeit in a different way (from the parent variant instead of from the child variant), but I haven't tried and I am not actively working on or monitoring LV NXG decisions in this area.

I'll ask someone from those teams to comment more directly.

[Hooovahh]

Yeah this new information on NXG's removal of useful API building tools, definitely sucks.  I have used this feature in current gen.  One instance of this is in my Variant Repository where you provide the name of some tag to be written or read, and it optionally pulls the name of the tag to be used, from the input.  I recognized that if I allows for the terminal to adapt (like a VIM will) that I wouldn't be able to pull this information which is why the input to write, or type to read, is always a variant and shows a coercion dot when it doesn't have to.  Here is an image showing writing a string with the tag "User Name" because it comes from the control.  Then reading that back.  In the read you provide the type that the output is (in this case a string which the output becomes) and the tag to read which is "User Name" coming from the string constant.

That being said I've migrated my code to be VIMs and have lived without this feature, and in my case just explicitly provide the name.  I want it, it is useful, but I have work arounds for my couple of cases.

[drjdpowell]

Note: the case Hoovahh showed, and Weibe's original example, are actually only the simplest of uses of named data in Variants.  If this were the only issue then I wouldn't much worry about its loss in NXG, as having to use a string rather than the constant name is a very minor inconvenience. 

The real loss is techniques that "define in one place".  Anytime one has to have to name something in multiple places is a high-maintenance and bug-prone situation.  The inability to build a cluster that inherits the names of the things it is built from is a particular loss.  Currently, one can unbundle some elements, drop some local variables, and make a subVI call or two, and you can bundle all that data together into a cluster that carries all the correct names and can be used for things like config files or logging.   Changes to names or data elements made upstream propagate automatically through the cluster.   The alternative of having a defined cluster constant will not auto-adjust, requiring hand modification.  This is both expensive in effort and leads to bugs like forgetting to change the name to match, or forgetting to update the numeric type (which coerces instead).  This gets extra expensive if one has multiple uses, like config files, and metadata on measurements/tests.

The stuff I'm talking about here is all compile-time defined stuff, so I think the loss of named variants may not be too bad, if there is some way of setting the cluster element names of bundled clusters to match the outputs they are wired from.   Looking at the NXG help, it is not clear to me if "Build Cluster" does this.  Does it?

[wiebe@CARYA]

---

@drjdpowell wrote:
as having to use a string rather than the constant name is a very minor inconvenience.

Inconvenient and confusing and ugly:

Wire a constant: the string input is required.

Wire a cluster: the string input is ignored.

Not looking forward to putting that in the documentation of n VI's! Makes me want to skip documentation altogether even more. Not good.

[drjdpowell]

>Looking at the NXG help, it is not clear to me if "Build Cluster" does this.  Does it?

I installed NXG 2.1 just to check this.   Answer is "No".   It just names things "Element 1", "Element 2", etc.   Can this major flaw be fixed?

[AristosQueue (NI)]

Powell: No, it does not. Checking with the dev team, this was a very conscious decision. Building a cluster requires naming the elements consciously, either with a diagram constant or a typedef.