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.

[wiebe@CARYA]

Active Participant

‎04-30-2018 05:46 PM

Options

>>The string input would not be ignored. The string would be the name of the cluster overall.

>AQ, Wiebe is making an INI library, where it is natural to work in name:value pairs and use clusters as sets of name:value pairs.   In JSONtext, it was more natural to associate clusters with JSON Objects, at not work in bare name:value pairs, so I didn't actually need this idea for that.  But I am familiar with lots of name-value uses, where the lack of wire names matters

Indeed. I could use the cluster label as a section name, and the element names as key name. That would make the input string required, as we can't get the cluster label. At the moment that's not how I do it (it needs an overwrite). 

[wiebe@CARYA]

>>The string input would not be ignored. The string would be the name of the cluster overall.

>AQ, Wiebe is making an INI library, where it is natural to work in name:value pairs and use clusters as sets of name:value pairs.   In JSONtext, it was more natural to associate clusters with JSON Objects, at not work in bare name:value pairs, so I didn't actually need this idea for that.  But I am familiar with lots of name-value uses, where the lack of wire names matters

Indeed. I could use the cluster label as a section name, and the element names as key name. That would make the input string required, as we can't get the cluster label. At the moment that's not how I do it (it needs an overwrite). 

[AristosQueue (NI)]

> "numeric constant_B" 

Doesn't localize. Arabic numerals conquered the world. Roman letters did not. 🙂

[drjdpowell]

>Doesn't localize. Arabic numerals conquered the world. Roman letters did not. 🙂

Even better!  Anti-localize.  No-one would mistake "numeric constant_b" as meaning the second of anything, as they might for "numeric constant_B".

[drjdpowell]

Just a note: another developer I know just independently hit this roadblock and asked me about it.

[AristosQueue (NI)]

I have kicked this around over the last few weeks... I've decided to decline this idea. I can clearly see the utility for these generic data toolkits. But with LabVIEW NXG abandoning wire names entirely, I think it is bad for LabVIEW 20xx to add features that cannot ever migrate. We are adding lots of new features that cannot migrate today, but I don't think we should be adding features that will make users more reluctant to upgrade as NXG gains power.

I talked to the LabVIEW NXG lead architect and evaluated a few different options for ways to put this specific use case -- malleable VI terminal names -- into NXG. I could not find any satisfactory workaround there. They just don't have type names propagating on wires.

I said in my first comment on this idea that this idea wouldn't be changing, but I thought that was because of the CH and diagram readability use cases. Posts in this thread made a good case for changing it, so I brainstormed on it, and came up with some variations on retaining the terminal's original name in the control's caption so that the CH would work but the diagram could still pick up wire names. But the NXG behavior wasn't something I could work around.

I've been sitting on this reply for a while, trying to come up with something; Powell's note today that another user hit this made me decide it's better to kill this hope sooner than letting it linger.

Sorry, folks.

[drjdpowell]

A link to a related discussion on a private forum (apologies to those without access) with my thoughts on clusters in NXG.

[wiebe@CARYA]

>But with LabVIEW NXG abandoning wire names entirely, I think it is bad for LabVIEW 20xx to add features that cannot ever migrate. We are adding lots of new features that cannot migrate today, but I don't think we should be adding features that will make users more reluctant to upgrade as NXG gains power.

I actually agree with that. It's sot a good idea to add G language features that can't exist in NXG.

I'm still thinking the "NXG no wire names" is going to hurt in unexpected places. Still a bit sad to see that feature go...

[drjdpowell]

>We are adding lots of new features that cannot migrate today, but I don't think we should be adding features that will make users more reluctant to upgrade as NXG gains power.

Remind me what NXG is for, again, if it involves eliminating capabilities relative to LabVIEW?

[smithed]

---

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.

---

Maybe I am misunderstanding, but I read this as "you should still be able to dynamically get the names of the elements inside of a cluster". But when I look around for that functionality, it does not appear to exist. This is where I would expect it to be: http://www.ni.com/documentation/en/labview/3.0/node-ref/get-cluster-info/

(On a related note, the documentation for get type info in NXG 3 is wrong, as it says it exposes the name. It does not, as mentioned in this discussion: http://www.ni.com/documentation/en/labview/3.0/node-ref/get-type-info/

The terminal does exist, but its not on the connector pane and if you debug through the code it does not have any data on it.)

Just to pile on to the rest of the thread, I rely on Dr jd's json library as part of the lowest layer of a library of tools I use internally, so this is a blocker for any attempt to migrate to nxg for me. In fact most projects I've ever worked on have relied on similar functionality, whether its the current set of JSON libraries or the older similar xml libraries -- they all use this feature set.

[wiebe@CARYA]

Good catch on the cluster names, smithed!