Leif

Thanks Eric! This is (probably) what I was looking for. However, when implementing some features, I've found that my child classes cannot have any attributes or class unique methods. But in my applications that shouldn't cause any problems; attributes are only relevant in the parent class AppBuilder (project file, build spec name...) and I can't see any need for specific methods in the child classes. Is there a name for this kind of class? (This feels a bit like "The Man Without Qualities"...) As I'm using GOOP, all classes are created with a default attribute, so I have to delete this and the associated methods (<class>_New.vi and <class>_GetAttributes.vi) from the child classes. And I guess that their constructors and destructors won't be needed? This feels like a good way to start. Thanks again, Eric!

Well, that's a completely different approach and it could work if I adapt it to my application. I'll have a try. Thanks! But I'm still curious if there is a solution where you can create objects from specific child classes (e. g. AppBuilder 2015) in runtime, without "revealing" them in "compile time". Unfortunately, two pieces of code dissappeared when submitting my post: This is the principle I want to use, but it makes this VI broken. I have tried using Get LV Class Default Value.vi, but I can't connect the object wire to my AppBuilder VIs. Is there some way to create a child class instance in runtime without "revealing" all child classes in compile time?

I'm working on a project for building applications (*.exe) and installers (setup.exe) from LabVIEW projects, that should work for different LabVIEW versions. As we currently use LabVIEW 2013 and 2015 (and soon 2017 I guess), my "framework" (GUI, state machine etc) is developed in LabVIEW2013. When I want to build application and installer from a 2013 project, I'll run this framework in LabVIEW 2013, etc. When building from a 2013 project, I have to use Application Builder in LabVIEW 2013 and when building from a 2015 project, I have to use Application Builder in LabVIEW 2015, and so on. This looks like a perfect case for OOP, right? So do I think, like this: Now to my challenge. In LabVIEW 2013, AppBuilder 2015 won't be executable, and vice versa. If the framwork just uses AppBuilder, this wouldn't be a problem. But I haven't found any solution to instantiate the subclasses. If I do like this in the framwork and open it in LabVIEW 2013, I get a broken arrow as AppBuilder 2015:GetVersion.vi isn't executable in LabVIEW 2013. The same thing happens if I open it in LabVIEW 2015. I have also tried to run the constructors with Call By Reference Node, but this functions requires a strictly typed VI reference, which also causes LabVIEW to recognize the non-executable VIs. Most likely, there is someone that have run into similar problems, and solved it. Any advice is appreciated.

Shaun, I really liked your solution, so I made an implementation; attached VI (LabVIEW 2016). Get SVN info.vi

The class diagram has evolved and grown: Let's investigate a case where Test Case is using Thorlabs OPM to test an optical power. This OPM is connected with USB. But I also want to emulate this OPM with some software where command responses are defined in a text file (used by Response File). Each file should be device (class) specific. In the final application, the execution would look like this: USB calls Thorlabs OPM (buildCommand) where Thorlabs OPM builds a string (commandString) for requesting the OPM power. This string is sent over the USB bus to the OPM which responds with the power value. This value is then propagated back via Real HW Interface and Thorlabs OPM to Test Case. I could also replace USB with Response File. getResponse looks up the commandString (get power request) in the file to find the response (power value) associated with the command, which is passed on back to Test Case. (The method send is not needed here.) Is this a good solution? What are the pros and cons? I realise that it's quite big and bulky, maybe a bit difficult to understand. I've also found that there are some common functionalities that cannot be reused with this solution.

Realised that Operator GUI is not an emulated resource as it could be used to connect to the actual hardware. Then the class diagram should look like this:

Thanks for the comments, hooovahh. Maybe, I'm not using good class names. I've got the feeling that e. g. Digital Multimeter more represents an interface to the device, rather than the device itself. Sometimes we have like ten different hardware classes, so creating an emulating/simulating class for each makes the whole project filled with duplicate classes, where the emulating classes almost have the same functionality. This is why I want to avoid this solution. As you mention hooovahh, I could use a boolean to indicate whether to use an emulated the hardware. However, I also want to define which type of emulation to use; the GUI solution, the more intelligent or something else. Then I think aggregating the selected emulator is better. Earlier, I've tried using the operator as a "communication resource", simply by using dialogs with instructions ("Set DC voltage measurement") and requests ("Enter measured voltage"). This was very useful as the communication interface wasn't developed yet, but the plan was to replace the dialogs with RS232 communication. In this case, we "translated" the RS232 commands into operator instructions. However, this feels a bit like "crossing the stream to get water" (Swedish idiom). I've called this class Operator GUI in the picture. (Emulated ComRes may be unnecessary) Another idea is to use file lookup tables which defines responses (e. g. "1.234 VOLT") for different HW commands (e. g. "READ DC VOLTAGE"). Without adding more intelligent, the drawback is that this always returns the same response to a command. Anyway, I've called the class Response File. To conclude, this is based on putting the emulation outside the HW classes as this could be generic. But is it a good solution?

I often find myself in the situation where I use a number of hardware devices in my application. The communication interface could be USB, RS-232, Ethernet... When developping and debugging the "execution logistics", it would be so nice if I could emulate the hardware, but I can't find a good solution/architecture. Probably, there are lots of intelligent developers here that could help me. Without the emulation option, the class diagram would probably look like in the picture. The most basic emulation could be having a GUI displaying the command sent and a manual entry for the response. On the next level, I could perhaps use some intelligent code that creates a relevant response based on the command sent. BUT: What is the best OO solution to this issue? One thing that I want to avoid is creating one emulated class for each HW sub-class (Emulated Digital Multimeter etc).

My test group has decided to start using OOP (beyond LVOOP I hope). The question is should we use an OOP tool and which one: GOOP/GDS or G#? I'm quite biased as I have used GOOP for a number of years, but I'm trying make fair investigation. I also realize that the StarUML plug-in in G# could be very useful. Has anyone made or seen a comparison between GOOP and G#? Or do you have an own opinion? (Searching for the text "G#" isn't that easy...)