New primitive: Rename Event

[SteenSchmidt]

Hi.

When you register a user event the name of that event (the name that appears in the event structure selector) is determined by the last output terminal that event emerged from. If your user event came directly from the Create User Event primitive your event will of course carry the name you gave it on its data type, so no problem there. If your event came from a control terminal you are (usually) also in control of the name your event wire carries (as it will be the control label), but if your event wire came out of another primitive along the way your event name will in some cases have changed to something you don't control yourself. In some cases your event name will just be <User event> or even <?>:

One of such events is annoying but can be acceptable. It's worse when you have several of those in your event structure selector - which of the <?> belongs to which user event? Therefore I usually rename events on the wire if they catch a generic name along the way. I use the Variant To Data primitive for this:

The above is the best solution currently, but it has a couple of drawbacks most of which come in effect if the data type of your event changes. In this case you risk ending up with code that isn't broken but executes with runtime errors. Therefore I suggest a new LabVIEW primitive for renaming events - one that will automatically carry over the event data type:

Would that be useful for anybody else but me?

Merry Christmas,

Steen

[elset191]

Relevant

[SteenSchmidt]

@elset191: Yes, I know of the "hidden" Coerce To Type primitive which has the same drawbacks as Variant To Data in this regard, as it also require a labelled constant to rename an event wire. Thus my request for the new primitive stands. But the discussion about why the Type Cast primitive doesn't work for this is very relevant (and the reason I use Variant To Data and not Type Cast). Cheers, Steen

[drjdpowell]

Suggestion: instead of a new primative, how about having wires automatically take on the name of wire label, if one is present?  Then one could just label the wire.

[SteenSchmidt]

I think they serve two different purposes.

[AristosQueue (NI)]

drjdpowell -- I definitely do not want something that looks like a comment having code impact. Wire labels are just free labels that happen to drift with the wire. They were a bad idea when they were suggested (for reasons I have ranted about amply in other forums), they were a bad idea when they were implemented, and they would be a worse idea if used for anything other than the bad idea for which they were designed.

PS: I do NOT speak for NI when I'm talking about wire labels. I loathe the "feature". That's my personal opinion. And as of LV 2013, the feature will hopefully be unnecessary because of the new... oh, wait, this is a public forum isn't it? Well, suffice it to say *my* preferred way of commenting a wire is getting some attention and I hope the feature appears in LV 2013. Until then, I'll just glare at anyone who sends me a VI with labeled wires.

[GuenterMueller]

---

@SteenSchmidt wrote:

Would that be useful for anybody else but me?

---

I like this, Steen.  At most I prefer a "Rename Wire" primitive. That way, we would not be limited to renaming wires that carry events: We could rename any wire.

[fabric]

+1 for a generic "Rename Object" primitive.

[JackDunaway]

As illustrated, the new node affords run-time ability to change the data name -- which doesn't make sense, because it needs to be a design-time static definition. Perhaps modifying the node to have a static configuration with this suggestion for a related idea?

---

@SteenSchmidt wrote:

Yes, I know of the "hidden" Coerce To Type primitive which has the same drawbacks as Variant To Data in this regard

---

Agreed, but Coerce to Type is still superior with its ability to throw compiler errors on developer errors rather than manifesting them as run-time errors 😉

---

@Aristos Queue wrote:

...when I'm talking about wire labels. I loathe the "feature". That's my personal opinion. And as of LV 2013, the feature will hopefully be unnecessary because of the new... oh, wait, this is a public forum isn't it? Well, suffice it to say *my* preferred way of commenting a wire is getting some attention and I hope the feature appears in LV 2013. Until then, I'll just glare at anyone who sends me a VI with labeled wires

---

Agreed -- and neat!

[SteenSchmidt]

@Jack: Agreed that we don't want runtime modification of the new name, so a static setting is preferred. The other idea you link to is not just related, I'd almost say that mine is a duplicate of at least what's going on in the comments of that idea. Regarding Coerce To Type - could you shed some light on how you think this is superior to Variant To Data? I think they have the same abilities, with the drawback of Coerce To Type that it hasn't got error terminals to signal illegal conversions with at runtime. You could still set up an illegal conversion with Coerce To Type at edit-time that will only fail at runtime (just as you could with Variant To Data). My suggested new primitive gets rid of the Type input, thus eliminating that failure mode.

@AQ: I don't use wire labels either, but could you point me towards some more info on what you're hinting at in regards to LV2013? 😉 I have read loads of comments on wire labels over the years and months of course, but nothing springs to mind when you write as you do now... and I'm dead curious 🙂

Cheers,

Steen

[JackDunaway]

---

@SteenSchmidt wrote:

You could still set up an illegal conversion with Coerce To Type at edit-time that will only fail at runtime (just as you could with Variant To Data)

---

I think this statement is incorrect -- would you be able to show an example? I still stand that Coerce to Type has the greatest type safety, Variant to Data is a close second (but still allows some bone-headed moves that cause run-time errors), and the Meat Grinder... erm, I mean Typecast... is waaaaay down there on the type safety spectrum.

But this is orthogonal to your point -- I agree it would be helpful to rename data without needing to supply type.