SubVIs and Methods

[D60]

Hi Experts!

I have two very basic question, but I didn't find a good answer!

1. What makes a vi to be a method of a class? I wanna create a factory pattern, so, when a class is loaded at runtime, all methods are loaded too. There are many ways to create a method for a class. ie.: Right Click and so on, or GOOP (I prefer like goop solution). And what about, if I create a simple VI? Set a paramter in and out an LVClass, and set the VI connectors Dynamic Dispatch....  So this VI is not generated, by standard way, I do it on my own. I think when I set a VI connector as Dynamic Dispatch, LV will know this is a Method, so the Factory pattern can handle this. But what about private methods? (think about their connector pane, and manually creation of vi that I will use as a private method). Will the factory pattern work?
    
2. My Second question is about code reusage and source distributions. I made some tests about Top level vi and dynamically called VIs - Plugins All the plugins are placed separate llbs.   Addition.llb\Addition.vi [Addition_sub.vi] and the second plugin: Subtraction.llb\Subtraction.vi[Subtraction_sub.vi] (EXE Tests) As you can see there the plugin subvis are in the same llb where the top level plugin vi is placed and at last, I have a commonly used subVI.The results are the following:
    
   a.) I have a top level VI, and calls a subvi, the COMMON.vi. All of my plugin vis call the COMMON.vi too. I built source distributions for all of my plugins. The source distribution exclude the COMMON.vi. When I started the program everything works well!
   
   b.) Later, the usage of the COMMON.vi became unecessary, so I've removed the COMMON.vi from the Top-level.vi. I've repeated the above metioned distribution build process and error occured, that the plugin vi is broken.
   
   c.) I've realized that, the distribution was set to exclude the COMMON.vi.
    
3. And Here my problems comes. How to build a distribution, that contains all the COMMON.vis, that are called from several plugin VIs. Including the COMMON.VI in every Plugin Distribution is not a very elegant solution and not a space and memory effective. Am I right?. So how to create a COMMON.llb for my COMMON.vis? 

Thank you very much!

[D60]

For my second question, I think I've found a solution, but something is now correct with that. I've set the VI serachpath to my application INI.

Using full path, it is correct, but it is not possible to use full paths if I would like to install this app.!

Somehow the relative path is not working...

Could you take a look at my ini? thanks!

I've attached my app. build.

[Ben]

Re Q1

THe factory patten should work IF you did everything right.

Ben

[dkfire]

Just one comment you your question 1.

You can't just make a plain vi a member of a class just because you have control and/or indicator of an object of the class type.

The class it self don't know about the vi, and therefor the vi is not a member of the class.

You need to create a method for a class in the right way.

[D60]

Thanks! Good to know!

[Ben]

---

@dkfire wrote:

Just one comment you your question 1.

You can't just make a plain vi a member of a class just because you have control and/or indicator of an object of the class type.

The class it self don't know about the vi, and therefor the vi is not a member of the class.

You need to create a method for a class in the right way.

---

If all of the details are correct (dynamic dispatching, identicle names, same icon connector, exact same VI name ...) then you can just drag the "roll-your-own-VI" into the class to let the class know that VI is a member and it should work.

I have done similar on multiple occations when a method from one child class was a good start for the method of another child class.

Ben