Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 05/15/2015 in all areas

  1. But I called it a collection.
    1 point
  2. Your upload is missing a file, luckily it was just a type def'd cluster and I could disconnect it to see how it worked. From your description I didn't think I'd like a design where a while loop is inside a case of an event structure, but having it be encapsulated in a reusable subVI makes me like it for some reason. I also don't like how this is polling in a while loop where an event structure could generate new events for a mouse move, but then again the refresh rate is configurable, and it is only for the time the mouse is down. A different design could be using the Limit Maximum instances of a mouse move event to 1. But then that's more work in the VI using this function, where your technique is pretty easy to incorporate into a new VI. It could be reduced even more simply by the init and close in the subVI, possibly keep the reference open with an uninitialized shift register. You can also read the calling VI reference. The result could be a single VI, that you put into a Mouse Down event, that takes care of a window move. Attached is some of these improvements. Thanks for sharing. Drag Drop Hooovahh Edit.zip
    1 point
  3. 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.
    1 point
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.