LabVIEW Idea Exchange

Virtually ALL of my more complex typedefs have multiple datatypes wrapped in a cluster. The result? A pink wire. I have fat, pink wires all over my code.

Allow us to choose different patterns and colors for wires on a typedef. Increases the ability to spot a typedef, and allows for distinction between two complex datatypes.

(Note: I am not condoning making a new wire for every typedef... that would be a point of confusion when collaborating. I would just like to add distinction to some of my more distinct typedefs).

The current behavior of LabVIEW is as such:

The pick list of event data strips the cluster, only allowing access to the elements inside the cluster. In order to manipulate the native datatype, you must reconstitute the cluster inside the event structure, a performance hit on large data structures firing at quick event rates. This is not to mention a messy FP.

I suggest that User Events preserve the clustered event datatype, allowing the programmer to access to the native datatype on the consumer end. The option to select only the element "Clustered Typedef.Array of I32s" of course still remains, but is not forced upon you. (Note that the below block diagram is NOT a direct LabVIEW screenshot... brought to you by trickery and a paint program. I clustered the cluster on event datatype [not shown] so that the event structure could eat the outer layer)

My motivation with this suggestion is directly linked with my other post on the Big Typedef Issue.

Currently, you can place a probe on a wire while developing, which is an indicator of the data on a wire. I want the ability to CONTROL the data on the wire, with a data forcing mechanism.

The implementation would be very simple... right click on a wire, and in the context menu the option "Force" would be right under "Probe." It would pop up a window of the forcing control, and while the VI is running and forcing is set to "Enable", the programmer can control the values that pass on the wire. If the force window were set to "Disable", the data in the wire would be completely controlled by the VI's logic.

I think the implementation by NI could be trivially simple. If you only allow a forcing control to be added during edit mode (not while the VI is running), the force could be added as an inline VI (as denoted by the green rectangle on the wire). The code inside the inline VI would be as follows, and the front panel would be "Data Force (1)" as shown above.

Of course, if you could add a force to a wire during runtime like probes, props NI. But I would be PERFECTLY happy if you could only add these force controls in edit mode prior to running.

One level further (and this would be AMAZING, NI, AMAZING): enable and disable certain parts of the cluster that you would like to force and allow the other elements to be controlled by the VI logic. I made the example above because it would be very natural to ONLY force Sensor1 and Sensor2, and letting the output run it's course from your forced input.

I use the search function everyday, but there is a feature missing. For a state machine with a lot of state data, I would like to specifically find every place a certain element is being read and written. You can search for the text, but this often turns up "false positives" such as constants, FP objects, property nodes... when all you want is the bundle/unbundle.

The  way I currently find every place state data is used is pull the element out of the state data definition, then use the error list to find all the places that the confused bundle/unbundle broke the VI!

I could be easier to insert or delete element from array by only select and hit Insert or Delete on keyboard.

Insead of this:

Select like this: