Source distributions with shared classes

[jives]

Hi folks,

I am having a bit of a problem with one of my applications, and I just wanted to make sure that it is not stupid packaging and/or directory hierarchy issue.

I have a LVOOP framework running on a RT target, which dynamically loads LV classes called components. Components inherit from the component class inside the framework and are built as source distributions. The framework looks for those components in a directory on the RT target and loads them during runtime. Everything works fine when I use simple classes.

Now I have a couple of components (they represent real hardware) which in reality consist of a collection of hardware "modules", plus some component specific stuff. These modules are the same for every component which uses them, but not every component may use all modules. Because (in general) these modules don't share common properties or functionality, I implemented them as independent classes, which are instantiated inside my components.

That was the easy part

The problem now is that I am using the same naming convention and directory structure for all classes, which looks like this

/Components/

/Components/Component1/

/Components/Component1/Comp1.lvclass

/Components/Component1/Private Data.ctl

/Components/Component1/Private Data Ref.ctl

/Components/Component1/Class Initialize.vi

/Components/Component1/...

/Components/Shared/

/Components/Shared/Module1/

/Components/Shared/Module1/Mod1.lvclass

/Components/Shared/Module1/Private Data.ctl

/Components/Shared/Module1/Private Data Ref.ctl

/Components/Shared/Module1/Class Initialize.vi

/Components/Shared/Module1/...

/Components/Shared/Module2/

/Components/Shared/Module2/Mod2.lvclass

/Components/Shared/Module2/Private Data.ctl

/Components/Shared/Module2/Private Data Ref.ctl

/Components/Shared/Module2/Class Initialize.vi

/Components/Shared/Module2/...

[/CODE]

and I would like to mirror it in my source distributions.

If i now go ahead and build the source distribution of Component1, the directory structure gets flattened, which leads to following problems:

1. Filename conflicts for Component1 and all modules. The builder tries to correct this by creating subfolders and moving the conflicted files into those, but the framework then complains about not being able to load Comp1.lvclass (and throws a LV error code 1498). I assume thats because my component or module does not know about the new subfolders which were created during the build and is looking for VIs in the wrong place.

2. This also creates a copy of all files of all modules used by a certain component in its folder, even if they are shared between components (not that big of an issue I think).

I tried to correct these problems by configuring the build in a way that the folder structure on disk is maintained in the source distribution. [i]This actually works[/i], as long one does not use VIs from vi.lib or user.lib somewhere in the components or modules. If one does, they get copied into their own nested places. The _complete_ directory structure in the NI folder then mirrored, and the framework will again not able to load the component(s), because it expects them to be in a certain (fixed) subfolder - not mentioning the subfolder mess which is created in the process.

I also tried to build separate source distributions for the component and each of the modules - which again does not work as expected and leads to the framework throwing a 1498 error code while trying to dynamically load the component. I am not sure why this happens, and I even tried loading the module dynamically in my component.

My question now is: Am I doing something wrong while building the source distributions? I have a feeling that this may just be a simple problem of just not using the AppBuilder in the right way (wrong project scope, wrong options in the build, etc.). Is there a different way of packaging my modules (llb, etc.)?

Or is this a more complex issue with what I am trying to do or even how the framework loads its components?

Any input on this would be highly appreciated

[LogMAN]

Hello, KeA

If I understand you the right way, you've got a framework implementing an class (interface) for loading inherited classes (components) dynamically.

Your components implementing sub- classes, which are instantiated somehow.

How do you instantiate your sub- classes (modules) within the components (statically / dynamically)?

If you statically instantiate your classes, the application builder will respond errors as you receive, because your modules (sub- classes) have

the same VI names / hierarchy. In that case I recommend you changing the VI names to match a specific pattern which does not cause VI name collision

(e.g.: <Class name>.<VI name>.vi --> CModule.Class Initialize.vi)

You could alternatively change your code to dynamically load the modules at run time (since they share the same VI names). In that case you need an Interface class, loading the inherited modules.

If you dynamically instantiate you classes you'll receive errors if you run your application in development environment (LabVIEW) once and then create the source distribution of your modules, because LabVIEW already loaded the class in memory while executing and will only unload if you close your project (or LabVIEW). In that case you should reopen your project in LabVIEW and create the target solution without execution the application in development environment.

The application should be able to dynamically load classes even with same named VIs, since class member VIs inherit a class specific prefix in call chain.

(<Class name>::<VI name>)

Greetings, LogMAN

[jives]

Thanks for your reply and for reading my whole monstrous post You are completely correct - I have classes (the framework calls them components) which instantiate other classes (I call them modules). I do that statically, by just dragging the class (or class control) into my VI, and I do the same with the class's public methods.

Your suggestion to prefix the class's filenames is a good one, thanks! I've been trying to avoid that for the sake of standardization, but after spending hours trying to find the right setup for the AppBuilder, I think I'll just use your idea

Dynamic loading is not needed in my case, and although fixing the problem it would just add another (unnecessary) layer of complexity to my code.

Edited August 22, 2011 by jives