Change Data Name (New Primitive)

[PJM_Labview]

I am proposing the creation of a new primitive allowing user to change the name of the data that is easier to use than the "variant to data" primitive.

There are some situations where the data name coming out of an output terminal need to be changed. Currently, a way to do this (while preserving the data type) is to use the "variant to data" primitive (which is less than ideal). One of the draw back of this method is that it requires to create a constant of the data to rename. Below is an example where this name change is useful using the "variant to data" primitive.

Now, it would be a lot nicer to have a "polymorphic" (aka XNode with type propagation) primitive where the user just need to drop a constant to rename its data. The tricky part about such a function is that you would NOT want to allow dynamic name change during runtime and therefore the name input parameter can only be a string constant (or its equivalent). Below is what I came up with.

It maybe that the string constant requirement of this method make it unpractical, but someone may have a better idea that would accommodate for this requirement.

[Jolt]

Why is this idea old and not more popular (or already implemented!)?

I finally got frustrated with the lack of this ability and went searching in the Ideas Exchange before posting. Not only did I find it in here (not surprising) but I also learned about "coerce to type" which, generally speaking, will now replace my use of type cast in these situation. 

Speaking of these situations, it is exactly the "bundle" case that this drives me most crazy. The "New Bundle Node" as suggested by jgcode would be perfect in 99% of the cases I need this for. I'd be fine if it completely replaces the old one. It could be dropped by default with the data-type image thingy, but editable as jgcode has shown. I think I'd trade the super-compact bundle with the slightly taller editable one if it came to it.

Cheers, 

[AristosQueue (NI)]

The reason it hasn't been done already is that there are a finite number of developers on LabVIEW and this is a waaaaaaay low priority. Here's how I'd rank this idea:

1) Low kudos count suggests it didn't motivate many folks. That's not sufficient by itself -- good ideas can die because they were posted on a Friday afternoon.

2) I wouldn't expect most low-level users to need it. They're generally working within a single diagram and they bundle wires together just to simplify diagrams (like only having to have one shift register in their state machine). Within the same diagram, there's not much reason to care what name gets assigned.

3) I wouldn't expect most high-level users to neede it. Mostly, if I'm going to pass a cluster to another VI, that signals that I need a typedef, and a typedef means that I would wire the center terminal of the Bundle node. And, repeatedly, advanced users tell me that they use the Bundle By Name way more often, which, again, means that the center terminal is being wired to set the names. In other words, as coder level increases, the names become something that is defined first, long before there are any values to supply on a Bundle node.

All of that is my personal hypothesis and evaluation... other members of LV R&D may rank it differently, though I think I've got a pretty good read on this particular one.

I did kudos the idea because it has come up once or twice in some cases where I'm converting data into variants and doing type comparisons, but it certainly isn't a regular need.

Requests like this one tend to get picked up in batches with other similar ideas when a developer tries to work on improving a general aspect of LabVIEW and sees this idea as part of that overall improvement. Such an edge case idea only gets more priority if something happens to makes strong financial sense to go after it sooner or if we happen to hire a developer for whom this becomes a personal crusade. When you have millions of users and thousands of suggestions and far FAR fewer developers (the general number is NI Confidential information), that's the way it goes. I've sometimes asked customers to estimate how many people they think are on the entire LV R&D team -- all I can say is that most users way overestimate. It makes me proud that we are able to (apparently) emulate a much larger team than we actually are, but it does give people the wrong impression about just how responsive we can/should be to ideas on the Exchange.

Does that give some perspective on this idea and it's place in the universe?

[drjdpowell]

Hi AQ,

Re (2), the JKI Statemachine template shown in the initial post, is an example where a non-typedeffed cluster is constructed in a single VI, and then entirely accessed by-name from then on.  And it's developed and used by some who would certainly be consiered "high-level users".

Personally, I would like to have a way to specify the name of an element, WITHOUT also specifying the type.  The most common example I face is an Event Registration Refnum, whoes type changes if I add or remove an event.  I would prefer that that type-change automatically propagate through my block diagram, but if I also need to give it a specific name via a constant somewhere (by whatever means) then I instead face a broken wire.

[AristosQueue (NI)]

I did say "most users", not "none". I actually did kudos this idea myself -- I think I've needed it about twice ever, but it would've been nice to have in those cases. There is a use case -- that's why we can even talk about priority as opposed to just rejecting the idea. But that priority is, in my evaluation, very low.