LabVIEW Idea Exchange

Currently there is a method for setting the control value of another VI via the Control Value Set Method. But there is no set with signaling method which allows control of VI's which react to changes on front panel controls. This makes it hard to automate VI's that are using front panel control events. There is a tedious work around to get references to control on the front panel and then use value signaling method . It would be very useful to just have one additonal method that does the signaling in additon to setting the value of the control.

If a class is contained in the private data cluster of another class, this is the LVOOP equivalent to an Association (as OOP concept). I'd like to optionally display this relationship of classes in the Class Hierarchy window. It should also work for nested structures (class in array, cluster, DVR).

As used from normal BD programming, different kinds of wire should be used to identify details of the relationship:

• green color if it's a by-ref relationship (DVR, SEQ);
• double wire if it's contained in an array;
• an directional arrow symbol would be necessary to indicate the navigable end.

The following would be nice to have, but partially difficult to implement:
In addition there should be a way to annotated the associations to indicate when the intended use is restricted to a child class, such as class that contains objects of the type of the same class. Here the association would point to an ancestor of this class. Either we should be able to put a comment on the 'wire' to document this intention. Ideally we could be able to wire classes with recursive associations (which are not possible in LVOOP, hence this should also not have any effect on the code by only be documentation), and link it to the implemented association wire.

The tendency of LabVIEW to indicate that 5 or 10 VIs have been changed for every VI actually edited makes maintiaining organized, legible version control logs difficult. To be kind to my co-developers, whenever possible, I try to keep the number of spuriously modified VIs down by intentionally not saving VIs that do not need to be saved. This would be a lot easier if the "Save all (this Project/Library/Class)" menu item behaved as it sounds intuitively. Currently, it functions to save all of the items in the Project/Library/Class, as well as their dependencies. In 99.9% of all cases, I did not intend to modify any dependencies. If I had intended to work on them, they would be in the library or project.

This idea is to have the "Save all (this Project/Library/Class)" menu item save only items inside the Project/Library/Class, and not their dependencies.