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.

[JackDunaway]

Kudos!

(Currently, a better prim than "Variant to Data" is "Coerce to Type" for two reasons: it's got a smaller footprint, and you can leverage the compiler to your advantage by catching the broken run arrow when you have a gross type mismatch between the constant you created and input wire.)

Perhaps, rather than a string constant, this node is always dropped with it's label showing, and the output wire always inherits the label of the "Change Data Name" prim (#1 below). Or even better, have the label name integrated into the node (#2 below) for all the same benefits enumerated here:

[PJM_Labview]

I was not so sure at first, but I think I like the modification that you made Jack.

By the way, I did not know about the "coerce to type" that you refer in your comment. This is cool. I think I am going to create a vip package and add it to my palette.

[crossrulz]

A better way might be to simply use the wire label (now in LV2010).

[JackDunaway]

>> A better way might be to simply use the wire label (now in LV2010).

If there were a distinction between wire label and wire caption, I would agree. (On the other hand, you still have the problem of distinct wires on either side of structure boundaries)

[smmarlow]

Kudo!  Will it have the ability to handle clusters?  What about renaming the elements of an input cluster.  Could it be resizable?

[PJM_Labview]

> A better way might be to simply use the wire label (now in LV2010).

This is an interesting idea, although this will be a bit odd since the label does not have terminals. So where does exactly the name change occurs? I think that two terminals (and therefore a primitive) are needed.

> Kudo!  Will it have the ability to handle clusters?  What about renaming the elements of an input cluster.  Could it be resizable?

This did not occurred to me at all. This is an interesting idea, but I think it is beyond the scope of what was my initial concept.

[smmarlow]

>This did not occurred to me at all. This is an interesting idea, but I think it is beyond the scope of what was my initial concept.

Perhaps an Express VI version could be added that is based on the primitive you and JRD suggest that has a resizable node (and pop-up dialog) for renaming cluster elements.  It could also be viewed as an icon.

[JackDunaway]

I don't think you should be able to rename data members using this prim. If you need to rename data members, fan out using Unbundle, drop the rename on each member, and Re-Bundle. Consider multi-layer nested datatypes - it could get ugly.

(Also, making this VI wear an Express VI bib might not be a popular idea 😉 )

[smmarlow]

@JackDunaway.  I'm no big fan of express either ;-), but where did I say the primitive would have to be wrapped in this express vi only? Sorry if I gave that impression, and perish the thought. Also, the 'multilayer' problem is not a problem at all.  It would only rename the elements of a cluster, not anything below (elements of elements, etc.).  Anyway, I feel like I'm hijacking this thread,  so Kudos again to PJM for a great idea, with or without cluster element renaming.

[jgcode]

I love this idea.

If you just want to define the name for the cluster data-type (my only use case thus far) then what about a direct edit option on a bundle node?

No footprint change compared to bundle by name

If you want to edit the name, just type it in to define it when the cluster is constructed.

May want to differentiate its appear to that of bundle by name, but it would be different as there is no input cluster wired in??