Create objects in different LabVIEW versions

[Leif]

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.

[Chris_Collier]

Does this work:
http://www.ni.com/example/30051/en/

It says it works on all LabVIEW versions post-2011, but I've not tried it.

[Leif]

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?

Edited April 14, 2017 by Leif

[G-CODE]

8 hours ago, Leif said:

Is there some way to create a child class instance in runtime without "revealing" all child classes in compile time?

You can easily instantiate a child class at runtime. You can launch your application with only the parent class in memory until you specify which child class should be instantiated. Each of your child classes can be placed in their own libraries (LLB or packed project library 'should' work). The path to the class in the library can be passed to the 'Get LV Class Default Value' function as shown in attached.

However, without looking into it more, I'm not sure this really solves your problem since you are trying to load code that is specific to a LabVIEW version. It sounds like you want to create a parent class that can be opened with either LV2013 or LV2015 and then dynamically load a child class that could have been created with either LV2013 or LV2015. Is that correct?

-Eric

[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!

Edited April 15, 2017 by Leif

[Stagg54]

Is there a way to use vi server to communicate across the app instance boundaries to achieve what you want?  Seems like that might be doable.

[Rolf Kalbermatter]

On 4/15/2017 at 11:05 PM, Leif said:

Thanks Eric! This is (probably) what I was looking for.

Is there a name for this kind of class? (This feels a bit like "The Man Without Qualities"...

If you talk about patterns, then this follows the factory pattern. The parent class here is the Interface, the child classes are the specific implementations and yes you can of course not really invoke methods that are only present in one of the child classes as you only ever call the parent (interface) class. Theoretically you might try to cast the parent class to a specific class and then invoke a class specific property or method on them, but this doesn't work in this specific case, since that would load the specific class explicitly and break the code when you try to execute it in the other LabVIEW version than the specific class you try to cast to.

Edited June 19, 2017 by rolfk