LabVIEW Idea Exchange

Allow the merging of Property Nodes using drag and drop editing. Dragging a property node onto another node would insert its terminals into the target node after the terminal onto which it is dropped.  The editor would highlight the terminal over which the programmer is hovering,  This behavior would only be exhibited for nodes of like objects.  For implicit nodes, the target (drop container) node would remain linked.

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

In the same way that mouse clicks, key presses etc can be filtered or modified before being accepted, having a Value Change? event option would allow tighter control over input data than possible using the Data Entry tab, and without needing to wire to a Value property node or local variable as AQ suggests here.

While this idea in itself probably doesn't make much difference, it would be very useful if such an event could be "bound" to a .ctl (a sort-of mini-XControl) in an enhanced version of what the Data Entry tab currently does.