Factory pattern with dll in child class

[Madottati]

I have a main class and its two child classes. I want to dynamycally load the class, depending on what is set in the ini file. 

The product is a lvlibp, where I add the two child classes as Always included - so they are in the lvlibp but which is loaded, will be decided in run-time. For loading the class I use get LV CLass Default Value.vi. 

One of the child class uses a third party dll, the other class not. So I expect in run time, when the class without the dll is loaded, the dll must not be on the PC, as the class is not used. But it doesn't work, because if the dll is missing, the lvlibp won't work too, an error 1003 will be thrown. 

Is there any hints I am not aware? 

[avogadro5]

You need to use multiple packed libraries, or switch to a source distribution.

[rolfk]

To clarify the post before: Every class needs to be in its own lvlibp (and consequently in a separate lvlib). A lvlib loads everything it contains at the first reference to any of its components. This means even if you just try to load the main class, any other class contained in that lvlib is loaded too and needs to have all dependencies satisfied.

The "one lvlib wrapping one class", is the perfect plugin system but requires some careful planning and maintenance to work properly. And if you ever plan to support more than one build architecture (Windows x86 and x64 count as two separate architectures too, not just Windows, Linux or LabVIEW RT), you need to be very very careful how you work to not make a total mess of your projects. Basically it requires to have different projects for each platform architecture and in most cases for each plugin component. lvlibp's don't play nice when used from different targets with different binary CPU architecture! For some reason they are not isolated to their specific target context but infect the entire project name space and that clashes badly when another lvlibp with the same name but different architecture is accessed from a different target context.

[Madottati]

Hi Rolf, 

I did it, so now I have one lvlibp with my application AND the parent class. 

The child classes are now each in other lvlibp. 

Now I get an error 1448 when call the To More Specific Class --> this throws no error if the child class is included in the same lvlibp as the parent class. 

Do I need to do some other actions? Why do I get bad typecast error? 

This is the class hierarchy:

Means, DIAG ist the main class, DIAG, CAN and LIN classes are included in the main lvlibp, I want to have the bottom 4 classes in additional lvlibps. 

[avogadro5]

---

@Madottati wrote:

Hi Rolf, 

I did it, so now I have one lvlibp with my application AND the parent class. 

The child classes are now each in other lvlibp. 

Now I get an error 1448 when call the To More Specific Class --> this throws no error if the child class is included in the same lvlibp as the parent class. 

Do I need to do some other actions? Why do I get bad typecast error? 

This is the class hierarchy:

Means, DIAG ist the main class, DIAG, CAN and LIN classes are included in the main lvlibp, I want to have the bottom 4 classes in additional lvlibps. 

---

XLIN probably inherits from x.lvlib:LIN.lvclass, in your application this is named x.lvlivp:LIN.lvclass. Totally different thing (according to LabVIEW). You'd need to edit LIN.lvclass to inherit from the class in the lvlibp instead of the lvlib.

If you don't want to live in namespace hell, you might consider my second recommendation (use a source distribution).

[wiebe@CARYA]

AFAIK, when you build a child in a PPL, it's parent will be included by default.

So the child inherits from the parent in the PPL, and casting it to the original parent in the executable or source doesn't work.

[Madottati]

I was looking for a way how I can tell the child class, which class is its parent class. 

I tried this:

But writing the property ParentClass throws an error, that the library is locked. I guess, because the class is in a lvlibp, I can't just modify even programmatically in it.

One workaround would be to create a lvlibp for the parent class, and reference it in the sources. But my wish is just to have some lvlibps for the plugins, but not for the main class

[wiebe@CARYA]

---

@Madottati wrote:

I was looking for a way how I can tell the child class, which class is its parent class. 

I tried this:

But writing the property ParentClass throws an error, that the library is locked. I guess, because the class is in a lvlibp, I can't just modify even programmatically in it.

One workaround would be to create a lvlibp for the parent class, and reference it in the sources. But my wish is just to have some lvlibps for the plugins, but not for the main class

---

Nice try!

No, you can't change the class hierarchy that way, when the code is blocked for editing...

When running, there's no way to change the class hierarchy at all, it's basically fixed at compile time.

Theoretically, the parent class that is used will be the first class loaded with that name (there can only be one class with that exact name in memory), but the name includes the (packed) library name, so there I don't think there's much wiggle room.

[rolfk]

Unless you use a tool like this: https://github.com/jovianarts/LVSolutionBuilder you can not dynamically change the inheritance from an lvclass in a lvlib to a lvclass lvlibp.

Without that tool you need to build the parent class lvlibp an then make sure the child lvlib inherits from the class in the lvlibp and not the lvlib, and then you can build the lvlibp for the child!

The above mentioned tool allows you to specify which lvlibs need to be turned into lvlibps and will then start building the topmost lvlibp, change any dependencies in other lvlibs and then build the next one and so on until all lvlibbs and other binary artefacts are built.

[wiebe@CARYA]

---

@rolfk wrote:

Unless you use a tool like this: https://github.com/jovianarts/LVSolutionBuilder you can not dynamically change the inheritance from an lvclass in a lvlib to a lvclass lvlibp.

---

Dynamically change as in "change it during edit time", or "dynamic runtime behavior"?