Thanks for responding, Shane. All of that was very informative. I still have some comments:
1) Could you elaborate on the statement "references [force] everything through the GUI thread?" This kind of makes sense to me, but I haven't found much info on the web besides "using references for non-GUI stuff is not recommended." I have personally noticed that sub-VI's that use refnums and property nodes do take more resources. 3) Re: OO Having interfaces (abstract classes) would be nice, from a polymorphic point of view. I know LabView has polymorphic VI's, but do polymorphic VI's distinguish between *different* cluster type def's? A more important problem is that you can't easily make an array of different (but related) type-def's. That takes away a lot of the elegance of polymorphism. Here's a real example: I have 3 different types of pumps that have different serial protocols. They all have basic functions like "pump" and "stop." In LabView, I have to call the "XXXXpump.vi" for each different type of pump, and I can't have all the pumps in the same array. In Java, I would create an abstract class called "PumpObject," and each subclass would HAVE to have a "pump" function. I could write the classes Pump1, Pump2, and Pump3, each of which is a subclass of PumpObject. So then, in my main function, I could have an array of PumpObjects, and tell all of the elements to call their "pump" functions. Each type of pump would know what to do, even though they all handle their serial communications differently. This would take all of 4 lines of code. I realize that, with enough polymorphic VI's, case statements, refnums, or variants, I could work something similarly out, but most people would not be able to work out such a hack.
