Building application and distributing classes

[thebandit]

Hi all,

Just starting to cut my teeth with LVOOP and having trouble working out exactly how to build the project in the way I think it should work, hoping someone can give me guidance. 

I have an application where each piece of test equipment has a base (parent) class (just empty methods) and have child classes which get dynamically loaded at the start to override the base. The idea being if we want to change say the PSU for a different model, I just write the new child class and call it (the class type to call is taken from a config file).

My understanding is, I should be able to build an appication exe to distribute and then also wrap together all the classes in a library or some single file to distribute along with the exe. When I want to add the new PSU model, I write the class, add it to the classes library file and update the config to call the new class, no need to update the application.  

What I am struggling with is how to do this, what is the mechanism to generate this "library" or packaged single file of classes, how do I achieve this ? 

I have tried various things, llbs, lvlibs etc, what seems to be the way to do it is have the child classes in a library (lvlib), then create a packaged library of these, but Im getting stuck at the adding child classes to the library step..... any help greatly appreciated,  

EDIT, OK, so Im nearly there, I have the child classes in a library, I can create a PPL from that, lat piece of the puzzle, how do I call them dynamically from the application.exe, at the moment I am calling the child class by file location, when they are all bundled up in a PPL, how does the claling work ? 

[crossrulz]

What I do is create a PPL for each of the parent classes.  I then use another project for all of the devices that use the build parent classes to build a PPL for each device.  Have the PPLs build into a standard directory structure and follow a naming standard that you can easily use to get the path to the classes inside the PPLs.  Another tip is to use the Get Exported File Path VI to get the full path of the class that is inside of the PPL.

[thebandit]

Thanks for the quick response crossrulz, what I hadn't appreciated was PPLs maintain a directory structure, Ill give it a try and see if I can get it working.  

Is it strictly necessary to have a seperate project for the child classes ? currently my application project has a child class library in it which I can build into a packaged library seperately. 

[thebandit]

OK, so I have been working on getting this working... 

The issue I have come up against is that when I run my source code trying to override a base class with a child from a PPL the "to more specific class" errors with:

err 1448 "LabVIEW: (Hex 0x5A8) Bad type cast. LabVIEW cannot treat the run-time value of this LabVIEW class as an instance of the given LabVIEW class.
=========================
LabVIEW: (Hex 0x5A8) Bad type cast. LabVIEW cannot treat the run-time value of this LabVIEW class as an instance of the given LabVIEW class."

I think this is telling me that the base class in the application is not a runtime class and it cannot typecast to the child class in the PPL which would be a runtime. 

Cut a long story short, is this why you have the base class in a PPL and the child classes in a seperate PPL. Does your application code always just use packaged libraries for base AND child classes to overcome the typecast issue ?

I guess this kind of makes the work flow a little less seemless if so, having to always build the PPL before testing but easily over looked for the advantage of OOP. 

[raphschru]

Hi,

Alternatively, you can use this trick to cast classes to a "compatible" base class, e.g. from a class in a packed lib to a base class outside the packed lib, but in my opinion, this is more a small hack rather than a large scale solution.

Regards,

Raphaël.