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

[SteenSchmidt]

---

@JackDunaway wrote:

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)...

---

I think you are right Jack, the fact that Coerce To Type does not eat variants the same way as Variant To Data is a further safety measure. There also does seem to be a requirement in the Type input of Coerce To Type that the base object class must match the input. I'll keep an eye on this (by using the primitive of course). So I was probably wrong assuming Coerce To Type and Variant To Data were 100% equivalent. My hat's off! 🙂

Cheers,

Steen

[drjdpowell]

AQ>>"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."

The problem I have with "wire labels" is that wires already have a label, taken from the source output terminal, that shows up in the help window, and (this case) as the User Event name, and is used as cluster element name when bundling, and is part of the variant data when using variants. The "wire label" is really just a comment or caption, and confuses the issue by giving a wire more than one "label".  I'd rather be able to control the actual label of the wire and optionally make it visible.  

-- James

[mawodorfer]

Such a feature is really needed! I use objects, that create user events. And if I have an array of those objects, it is not possible to determine which objects event should be used. I always need to check the object reference inside of the Event structure. So, a better way to set the names of a user event is indeed necessary!