Leaderboard

Certified May 22 2015 Placed in LabVIEW IDE Category

Kernel32.dll GetDiskFreeSpaceEx() does the trick GetFreeDiskSpaceEx.vi

Hmm, you sound like my wife when she's fed up with a discussion and just can't be bothered any more.

TIL: Mung is a real word created in 1958 and not a made up word we used to use at my school.

The composite pattern is not really what you need here since you admit yourself that the different levels of the hierarchy require different interfaces. What you need is simple object composition (a grouping of objects to increase functionality) which is NOT the same as the Composite Pattern. I think your different object hierarchies are relatively clear. Your confusion arises perhaps from the false expectation that all levels of your object composition need to share interfaces. So a Group is a single step for ALL DUTs, right? Group 0 is Initialise essentially, Group 1 is Step 1, Group 2 is Step 2? This sounds like it may actually be a candidate for the Composite Pattern. Why not implement a Group as a Composite of Step with the same interface? This will allow you to treat groups and steps transparently. I don't know if that functionality would actually aid your development, I'm too far away to be able to judge that but it would allow you to have "Virtual DUTs" which are actually comprised of several individual DUTs. Your functions are a completely different beast, as are your Actions. Again you could theoretically define Functions and Actions so that the Composite Pattern could apply. Again this would allow the generation of an Action which actually contains several other actions. Part 1: Base Class : Step Child Class : Group (contains 1..N Steps) A Step is an object which represents a stage of your testing procedure for a single DUT. A group represents the same thing but for 1..N DUTs. A group may contain other groups. A group and a Step can be used interchangeably within the program. The interface you would code to is that of the Step (Parent class). Part 2: Base Class : Action Child Class : Function (contains 1..N Actions) An Action is a single action (Set Voltage, Raise Alarm, whatever). A Function is also an action but contains 1..N other Actions. A Function can also contain other Functions (Hierarchical definition of test procedures). So I could imagine (without in-depth knowledge of EXACTLY what you're trying to do) that you could use a combination of Object Composition (Action&Function or Step&Group) and the Composite Pattern (Step contains 1..N Actions) to achieve what you want.

This post will not directly address your specific problem but rather concentrates on clearing up some confusion which cost me personally many headaches and which I have not seen addressed before (I never actually looked that hard). I have had lots of trouble finding the link between theoretical discussions on the Composite Pattern and actual implementations (Composition) in LabVIEW for years. A short time ago, the penny dropped (figuratively). The Composite Pattern refers to a single hierarchy tree where you have a number of child classes. You define one class of this hierarchy Y (for example a single step above the base class X) to actually contain an array of the base class. It is simply an object which allows a group of objects of base Type X to be operated on as if the object containing them all was also a simple Object X. You can therefore easily picture a hierarchy of objects by simply having an array of Objects X where some of them are actually Object Y containing other objects, some of which again may be X and some Y and so on. By abstracting the "many X" into Y (which due to inheritance is also X) you have implemented the Composite Pattern. The Composite Pattern (as the GoF describe) is certainly not what NI propagates as Composition (a solution where many objects of DIFFERENT hierarchies are collated into a single object in order to implement different functionalities). The key sentences in the links you provide regarding the Composite Pattern are: Implementing the composite pattern lets clients treat individual objects and compositions uniformly (Y containing two or more X is itself an object of Type X) and There are times when a program needs to manipulate a tree data structure and it is necessary to treat both Branches as well as Leaf Nodes uniformly (Whatever operations you can perform on X must also be doable with Y - they have the SAME interface) Composite Pattern != Composition Composition is a general term and can be used for defining a class A which contains classes B,C and D all of which have different interfaces and hierarchy trees. This is a grouping, a Composite object. The word Composite here does NOT infer application of the Composite Pattern. The Composite Pattern is a small sub-set of possible object groupings or Compositions because it has much different requirements and is much more restrictive. WAY back in college, I had a really hard time understanding inheritance in OOP. I couldn't figure out how the mapping from child to parent could possibly be implemented in a way that was stable and robust. It was only after LVOOP came to LabVIEW that the proverbial penny dropped (I'm not wealthy, the time it takes for pennys to drop for me means I'm actually really really poor). Inheritance is an EDIT-TIME declaration, not a RUN-TIME declaration. To anyone who understands OOP this is a no-brainer. But my brain interpreted it differently and because nobody cared to make this distinction when teaching it to us at college I lost out on nearly 20 years of understanding OOP.

Lots of contending terminology here. So I will adopt Test Stand terminology since this is what we are trying to emulate. Sequences, Steps and Actions. One way forward is to consider Sequences and Steps as an ordered list (I posted an example on here somewhere). The "List Object" has add, remove, delete insert etc. You may consider an Action as a single element list or you might wish to break it out into a discrete item. It doesn't matter. If you derive Sequence and Step from a List object. That gives you all the management items. Through composition (see the vehicle example shipped with LabVIEW) you can, add an index as a current execution pointer and a string name so we can display a label for our Sequence/Step. That's the easy bit. It gives you management functions and a currently executing marker with a display name that you can show the user. It also gives you a list of items to iterate over. The hard part is how much do we put in the list objects and how much do we put in the contained items within the list object...... So this is great. We steam ahead and add skip, move up and move down for our lists and pretty soon we have the whole UI mapped out and working where the user can add, remove and modify sequences and steps. Then we get to actions. This is the point when I abandon POOP so the others will have to jump in here.

Well bugger me!!!! Welcome back stranger .