Expand Data Interface to Built-In Messaging Primitives
We've turned on a search before post feature in the LabVIEW Idea Exchange. This new feature will help cut down on the number of duplicate ideas in this space!
The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
Now that coding for LVXCC is finished (get over there and vote before November 6 in the UI Controls category!), back to the Ideas drawing board.
A common messaging practice involves creating a messaging ref (whether Queue, User Event, or Notifier) from a clustered datatype. The next step involves sending some data along that ref, and the final step is receiving data from the ref:
Above, you can see that the first two messaging types return the entire data cluster on the Receive, thus requiring an 'Unbundle'. I like how the third messaging construct uses the Event Handler Structure to "fan out" the elements on the Event Data Node interface (well, every now and then I'd like access to the top-level data structure on the Event Data Nodes...). All three constructs require fully-formed data structure type information for the Send input.
The interface for these Send and Receive primitives could be simplified, yielding a significant reduction in the BD footprint and an appreciable decrease in layout maintenance.
(Note, also, added a third element on the Dequeue graphic and centered the Enqueue by a pixel )
Since the data is already strictly typed in these messaging references, additional type information is not needed in a separate Data Input Terminal.
Below I've illustrated a place I'd love to use this cleaner interface - between a While Loop and a Case Structure. We save 32 pixels - enough space to fit one more primitive into the Case Structure!
Also note: this follows suit for current practices that allow you to "fan out" data structures on the syntax level, such as Property Nodes (with a cameo appearance):
Discussion questions to duke out in the comments section:
Can the developer rearrange the order of the nodes (like in a Bundle by Name), or is the order fixed (like a Bundle)?
Related, can the developer select fewer or duplicate elements that are in the data cluster (like a Bundle by Name), or is the node size fixed to show the exact number of elements in the data cluster (like a Bundle)?
Are inputs Required, or can the developer leave them unwired to assume default data?
Would these nodes replace the current nodes, be an alternate display of the current nodes, or be new nodes altogether?
Should the Error Terminals go above the data I/O (like Scan From String) or below?
Do we want only the small icons (like Bundle, or Scan From String, and shown in proposed illustration) or the full data name (like Bundle by Name) for data IO on the node? Does it need to be configurable, like 'No Names', 'Short Names', and 'Long Names' on Property Nodes?