LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
Showing results for 
Search instead for 
Did you mean: 

Graphically display 'Associations' in the Class Hierarchy

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.

1 Comment

Building an OO implementation generally requires designing the implementation in a UML modeling environment (Visio, Artisan, etc.), as well as maintaining an  as-built design of the system. The bigger the system, the more important the need for the design material. This feature would assist the developer in validating the implementation against the design to identify deviations so that they can be understood and corrected in either the design or the implementation.