"LabVIEW class is not in memory" error

[eaolson]

I am developing a library of classes. The classes are all in a lvlib, the library is in a project, and the project also has a small test VI, which uses the library. If I open the test VI from the project, everything is fine. If I open the VI on its own, running it gives this error in a popup window: The LabVIEW class is not in memory. The dynamic subVI cannot execute. Probe the wire going into the dynamic terminal to see the data type." The problem seems to occur when the dataflow enters into a dynamic dispatch VI. Shouldn't the classes be loaded when the calling VI is loaded?

(Crossposted from the NI forums.)

[Tomi Maila]

Yes, you should not be able to have a class instance flowing along a wire that is not in memory. So I guess you are encountering a bug. Can you provide an example that duplicates the issue, there could be something I'm not thinking of that you are doing that's actually causing the problem.

Tomi

[eaolson]

QUOTE(Tomi Maila @ Oct 5 2007, 05:03 PM)

Yes, you should not be able to have a class instance flowing along a wire that is not in memory. So I guess you are encountering a bug. Can you provide an example that duplicates the issue, there could be something I'm not thinking of that you are doing that's actually causing the problem.

I've attached the whole directory as a zip file. If you open Image Demo.vi by itself, this problem happens (8.2.1), if you open Image Demo.lvproj first, then the Demo, it doesn't. I would appreciate any suggestions.

[Tomi Maila]

QUOTE(eaolson @ Oct 6 2007, 09:42 PM)

I've attached the whole directory as a zip file. If you open Image Demo.vi by itself, this problem happens (8.2.1), if you open Image Demo.lvproj first, then the Demo, it doesn't. I would appreciate any suggestions.

Works properly with LV 8.5. There must be a bug in LV 8.2.1.

In Image.lvlib:Image.lvclass:All Image Types.vi you have an Image class array indicator, the default values of which contains all the child classes of Image class. I guess this doesn't load the child classes to memory in LV 8.2.1. Add class constants wired to build array wired to the indicator to All Image Types.vi. I guess this should be a workaround for the bug (or feature) but I've not tested.

Second this VI and creating child classes in a method of parent class is bad OOP design as your parent class Image.lvclass should not be aware of its child classes. You're mixing functionality of a factory class with the functionality of a Image parent class. Google factory design pattern for more information on using factory classes for creating instances of other classes.

[Aristos Queue]

QUOTE(Tomi Maila @ Oct 6 2007, 07:36 PM)

Second this VI and creating child classes in a method of parent class is bad OOP design as your parent class Image.lvclass should not be aware of its child classes. You're mixing functionality of a factory class with the functionality of a Image parent class. Google factory design pattern for more information on using factory classes for creating instances of other classes.

Actually, I may have led him to this if he's read my posts on factories in various forums. I've been asked by many people what class should properly own the factory method. I don't have a problem with the parent class owning that method. I don't see the need for a separate Factory class. I'd be curious to hear pros/cons on this point.

[eaolson]

QUOTE(Aristos Queue @ Oct 7 2007, 03:14 PM)

Actually, I may have led him to this if he's read my posts on factories in various forums. I've been asked by many people what class should properly own the factory method. I don't have a problem with the parent class owning that method. I don't see the need for a separate Factory class. I'd be curious to hear pros/cons on this point.

Sorry Tomi, AQ outranks you. Yes, in fact it was a post of yours on a different thread on this very issue. You have an example up somewhere (I forget where) with a dynamic factory example; I figured this was a small enough class that it wasn't worth the effort to go through all that.

He has a point. Your method means that the parent has to be aware of its children and that seems a bit inelegant. My original approach was sort of an implementation of the Chain of Responsibility pattern (yes, I've been reading the Gang of Four book again), though because of the way the image data cluster is written, the topmost class still needed to know where to send the data for instantiation, so it didn't really help much.

Anyway Tomi, thanks for checking this out and verifying that the error doesn't happen in 8.5.

[Tomi Maila]

QUOTE(Aristos Queue @ Oct 7 2007, 11:14 PM)

Actually, I may have led him to this if he's read my posts on factories in various forums. I've been asked by many people what class should properly own the factory method. I don't have a problem with the parent class owning that method. I don't see the need for a separate Factory class. I'd be curious to hear pros/cons on this point.

If the factory is in the parent class, then you are stick with that factory implementation. First you can't easily change the implementation of the factory from one to another by simply changing the class implementing the factory. Second if you write a class hierarchy say image library. Then later on somebody else wants to extend your image library, then this somebody is married with your implementation of the factory as you've decided that the factory is a property of the parent class. Again it would be easier to extend the library if the factory wasn't part of the parent class but a class in a parallel hierarchy.

I've always tried to follow the rule of thumb that keep classes clean of things that do not logically belong to the class. This rule of thumb gives often cleaner implementations that are easier to extend when the time comes. Following the rule may require some extra thought but saves a great deal later on. An ability to create different kinds of images is not a general property of a general image. Following the rule of thumb you should put it to a separate Image factory class. Actually I'd make the Image factory class abstract and then derive special implementing class from that.

Sorry Tomi, AQ outranks you. smile.gif

Then I've not done enough to show my talents

Cheers,

Tomi

[Aristos Queue]

QUOTE(Tomi Maila @ Oct 7 2007, 04:17 PM)

Sorry Tomi, AQ outranks you. smile.gif

Then I've not done enough to show my talents

Never forget ... I'm a C++ programmer professionally. I'm only a G programmer as a hobbiest. When we started this OO thing, there weren't any pro LabVOOP programmers, so my hobbiest status counted for a lot. That'll wane over time (assuming I've done my C++ work well enough )

Maybe someday LV will be finished and I can -- as some of the more senior LV architects have done -- become a G programmer professionally.

PS: Tomi makes some interesting points about the utility of a separate Factory class. I'll have to think about that.