Jump to content

Create objects in different LabVIEW versions


Recommended Posts

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:

AppBuilder.png

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.

Link to comment

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:

factory.png

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 by Leif
Link to comment
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

2017-04-14_10-15-16.jpg

  • Like 1
Link to comment

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 by Leif
Link to comment
  • 1 month later...
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 by rolfk
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

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