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]

Well, another way to come at it is to suggest that ideally vims should behave as if their code was directly used in the caller (although inside an implicit sequence frame).  The name behaviour breaks that.

[AristosQueue (NI)]

[drjdpowell]

I think you may be misinterpreting what wiebe is asking for.  Neither of us wants to change what the terminal is called.   We want to access the wire name inside the VIM.

[AristosQueue (NI)]

I acknowledge the utility of what you're trying to achieve. I think it is a bad idea even though I don't have a good proposal for how to otherwise achieve that functionality.

> Neither of us wants to change what the terminal is called.

> We want to access the [caller's] wire name inside the VIM [instance].

a) (Major objection) The name of the wire is the name of the terminal. I could add some code to indirect from the instanced subVI to the VIM for displays, etc, but that would be a change from all other uses in LabVIEW. It would make scripting considerably harder if the terminal name of the subVI was not what users saw when hovering over the terminal in tip strips and context help -- and the name would potentially change on every type prop. Scripting authors would have to refer to the VIM to find terminal positions when trying to find a given terminal on a node that called a VIM instead of talking to the node itself, as they do everywhere else in LabVIEW.

b) (Major objection) In the image that Weibe posted originally, he is getting a variant based on the name of the wire. I believe that the current code is correct because it preserves the malleable invariant of doing the same thing regardless of the type. The name of a wire is not part of its data type -- it doesn't propagate across to the outputs, for example. It would be very strange if the output terminals changed their names based on the propagated names. Thus the current behavior is absolutely correct as it allows me to get a variant named "Index" regardless of the type of the index. And although that is not your goal in this code, it could be the goal of someone else's code, and while I have no way of knowing which preference is more common, I think the existing behavior is more consistent with LabVIEW's operation and therefore more likely to be what most users expect. I imagine your objection: "If I wanted the same string every time, I could just wire a string constant." True. But if you wrote this code in a regular VI, you'd be doing it to be resilient against people renaming the terminals in an evolving API. I think that expectation should be preserved here.

c) (Medium objection) I am not denying the limited utility of what you are proposing. For example, I can see utility if the thing that was upstream was an Unbundle node and you're looking up a variant based on the name of the field that you unbundled. But I still cannot believe that you'd want to look up a variant named "x+y" just because there's an Add primitive upstream. Wire names are so rarely meaningful like that, it seems bad to make functionality shift with something that is so fragile.

d) (Minor objection) The code you've written doesn't work in a non-malleable inlined VI. Inlining does not imply adopting the caller's names when compiling internally. If inlined VIs propagated the names of the wires, I would be more inclined to look at the malleable VI behavior as a bug to be fixed, but that is not the case.

e) (Minor objection) This would be a change to run time behavior of working code. Even if I thought this was a good idea, I'm unsure how I could mutate existing VIs to continue the current behavior if the new behavior came into vogue. I dislike introducing breaking changes unless I'm really convinced it's a better thing. This is particularly true when a workaround exists: You can add that functionality yourself by putting the variant name lookup in the caller and passing the resulting string into the subVI. You could make the subVI into a merge VI in the palettes to combine the nodes on drop. I acknowledge that this is a less pleasant block diagram, but it achieves your functionality goal.

f) (Minor objection) Wires do not have names at all in LabVIEW NXG. It isn't even a language concept to propagate names, so that code posted by Weibe won't work ever. I do not want to encumber malleable VIs with aspects that would mean less compatibility with LabVIEW NXG.

[AristosQueue (NI)]

g) (Major objection) We want code to behave the same as a malleable instance and the same way when user converts the malleable instance to a real VI. Converting to a real VI is meant to aid with debugging -- it wouldn't aid much if the behavior shifted. If we use the caller's name in the instance, then in conversion, we would have to preserve the caller's terminal names. That means there really would be index terminals named "x+y", and that would impact every user, not just the few users who are using the type reflection nodes to write variant libraries.

[AristosQueue (NI)]

If you can't tell from the long post, I really am looking at this idea and trying to find ways to make it work, but the more I investigate, the more issues I find with the request as stated.

The best alternative I've come up with would be to introduce a new class of terminals specifically for harvesting information about the caller. This draws on some work I've been contemplating for "make a subVI able to do different things when a caller leaves a terminal unwired."

Today, you add a control to a conpane, you can set it as Required, Recommended, Optional, or Dynamic Dispatch. That last item hints at the direction I'm thinking. Suppose you added a Boolean to the conpane and set it as a new enum value, something like "No Wire -- Detect Unwired". (That's a terrible name, but bear with me, please.) It means "yes, this Boolean is on the conpane, so data will be passed from the caller, but callers won't see that terminal... the data on that terminal will be a Boolean indicating whether some other terminal is wired." There'd have to be an association from the Boolean control to some other control on the panel -- like the arrow for associated comment or a naming convention of the labels ("Bool has same label as the other control but with an added underscore" or something like that -- hopefully not that since that's really hackish, but you get my point, I hope).

OK, let's take that idea... on malleable VIs, what if you could add a string control to the panel and tag it with "No Wire -- Caller's Wire Name". It would indicate information coming from the caller, but, again, the terminal wouldn't be seen on caller diagrams. Instead, it would be compiled to supply a constant that is the name of the wire on the caller's diagram.

I've brainstormed about other "No Wire -- Harvest ___ info from caller" that might be useful -- such as "No Wire -- VI Reference Of Caller", as a way to simplify writing Brat VIs. Most of these are info about the VI as a whole (panel color, so a subpanel could take on the same color), but they're pretty light on value, and the "is unwired" is the only useful one I'd come up with for terminals, until now.

[AristosQueue (NI)]

PS: I'm not closing this idea as rejected. I've raised a number of objections, but I haven't floated them in front of anyone else from R&D. I will, and maybe the consensus will be that we should make this change.

[drjdpowell]

Re (f): will variants not carry any names for contained data in NXG?!  Is NI aware of the usefulness of this feature for 3rd-party libraries that deal in named data (such as weibe's INI library)?  What is the planned replacement for this important capability?

[Dmitry]

AristosQueue wrote:

OK, let's take that idea... on malleable VIs, what if you could add a string control to the panel and tag it with "No Wire -- Caller's Wire Name". It would indicate information coming from the caller, but, again, the terminal wouldn't be seen on caller diagrams. Instead, it would be compiled to supply a constant that is the name of the wire on the caller's diagram.

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

[AristosQueue (NI)]

> Re (f): will variants not carry any names for contained data in NXG?! 

Variants will not carry wire names. And variants obtained from contained data won't contain names. BUT, cluster and class element names are still available from the cluster or class variant. In other words, if you have the variant for the whole cluster, you can ask it for the variant for its Nth element and for the name of its Nth element. But you cannot ask it for its Nth element and then ask that second variant for its name.

Does that settle your nerves or would you still like more details from someone on NXG? I can ask one of them to visit this forum if you have further questions.