Parent class object loads all children? Why?

[Abdullah R]

I am not sure if this has already been discussed. I hope this is not a duplicate post.

I have an asbtract class that just exposes an interface (i.e. bunch of public VIs with pass through wires on BD) for children to implement using dynamic dispatching. This class has 5 children classes with lots of private subVIs besides the dyn dispatched interface implementations (public ones).

The problem is that outside project environment (i mean when I close all projects even restart LabVIEW) and just open a blank VI and drop abstract class object (Parent) on the block diagram. What i see in "VI Hierarchy" windows is that ALL 5 children classes with ALL of their SubVIs have been loaded into memory. Is there anyway that children classes & their VI be dynamically loaded into memory at runtime? The reason is that based on inputs to abstract class, i know it will only need to load one child class for particular end user of mine. To the end user it is not only waste of memory but also slow loading time because LabVIEW is loading into memory 4 classes that i know the user will not need at runtime.

Is there anyway that i only load thin abstract class at edit time? I hope i made myself clear!

Any ideas around this problem? suggestions? patterns?

Thanks all!

[Aristos Queue]

A) The parent class has no record of its children whatsoever.

B) A parent class will load all of its own VIs into memory.

C) A VI that loads will load any of its dependencies.

Thus (A+B+C) strongly suggests that some VI that is a member of your parent class uses, on its panel or block diagram, instances of the child classes directly, thus causing them to load into memory. You may have an actual control/indicator/constant of the child classes or you may have said "Make Current Value Default" on a control/indicator of the parent type that contains a child class (if you've done this, the background of the control/indicator will be black instead of gray so you can identify it easily).

[jaegen]

I'm seeing something similar to this:

I built a class hierarchy inside its own library (.lvlib), then built a test project which included the .lvlib and derived its own child classes for some of the original classes. I'm now using the .lvlib in a new project, and one of the "test" child classes is showing up in the dependencies under "Items in Memory" when I load the new project. This child class was a real dependency briefly, as I copied over one of the test VIs into the new project, then deleted all references to the test class. If I recreate the new project from scratch (with the cleaned-up test VI), the test class doesn't show up.

Jaegen

[Abdullah R]

Ok i looked very carefully what was happening and i found the explanation. The problem is that my abstract class (parent) has a Class Factory VI whose BD is shown in the attached figure#1. It has static instances of child classes and thats why parent is loading all the 5 children into memory. I have confirmed that if i remove static instance, then only the parent is in memory and not the children.

Now the question is how to elegantly solve his issue? The only way i can think of (which i dont think is the best) is have a public VI in each of the children that just returns its reference. Then use "Call By reference node" in the class factory to call that VI which just returns you its reference. See figure#2. And yes that solves the issue and that only parent is in memory.

Other ideas are welcomed Thanks all!

Figure#1 (causes the children to get loaded into memory with parent instance)

Figure#2 (Good! Only parent is in memory at edit time)

[Aristos Queue]

QUOTE(paracha3 @ Oct 30 2007, 06:02 PM)

Now the question is how to elegantly solve his issue?

Look up the Factory Pattern in the http://forums.lavag.org/LabVOOP-Design-Patterns-v10-t3845.html' target="_blank">design patterns document.

[Abdullah R]

QUOTE(Aristos Queue @ Oct 30 2007, 09:23 PM)

Look up the Factory Pattern in the http://forums.lavag.org/LabVOOP-Design-Patterns-v10-t3845.html' target="_blank">design patterns document.

Now that is elegant. However looks like "LVClassLibrary::DefaultInstance" is a private method and i can not find it under LVClassLibrary's properties. Hum... i guess i have to copy it from LVOOP Navigation example where it is left purposefully!

Now my class behaves exactly the way i want it (as long as i do not built executable of it). Thanks!

[Aristos Queue]

QUOTE(paracha3 @ Oct 31 2007, 02:07 PM)

Now that is elegant. However looks like "LVClassLibrary::DefaultInstance" is a private method and i can not find it under LVClassLibrary's properties. Hum... i guess i have to copy it from LVOOP Navigation example where it is left purposefully!

Now my class behaves exactly the way i want it (as long as i do not built executable of it). Thanks!

a) Default instance shouldn't be private. Not sure what you're seeing that makes you think it is, but it is a public property, quite deliberately.

b) The default instance property doesn't work in the runtime engine. To get around this, LV8.5 includes a VI in the "Cluster, Class & Variants" palette that does the same thing as the property but works in both the dev environment and the runtime engine. (PS: That reminds me I need to update the Factory pattern in the document so that others don't get burned by this.).