Classes in llb or multiple classes in same folder?

[dsavir]

Hi all,

In our main program there is an option to dynamically load a subvi given to us by our customer (so we don't know it or have it in advance). We discovered that for the subvi to load properly ALL its subvis and dlls need to be in the same folder. In order to not have thousands of VIs in the folder, we usually worked around this by putting all the subvis in an llb in the same folder. The subvi to load needs to be outside the llb, but all the rest is in an llb in the same folder. So far, so good.

I am writing in LVOOP a subvi to load in this way. Therefore, it has a number of classes. And I can't put all the classes in an llb because I have override VIs therefore I have a number of VIs called, for example, "Get". However, If they are not in the same folder as my subvi, the subvi does not load properly at runtime. Catch 22.

So my questions:

1. Is there a way to define a "namespace" for each class so they can be in the same folder without changing names? I thought this was inherent because of the class_name::class_method syntax, but apparently it's not...

2. If I put each class into an lvlib, will it ruin the override and dynamic dispatching VIs?

3. Does anyone have any other solutions to this problem?

Thanks all,

Danielle

[Andrey_Dmitriev]

---

dsavir wrote:

So my questions:

1. Is there a way to define a "namespace" for each class so they can be in the same folder without changing names? I thought this was inherent because of the class_name::class_method syntax, but apparently it's not...

2. If I put each class into an lvlib, will it ruin the override and dynamic dispatching VIs?

3. Does anyone have any other solutions to this problem?

---

1. Can you put two same files into the same folder? No. In the memory SubVIs represented as you have described, but namespace is not used for storing SubVIs on the disk. You have to use subfolders for each class.

2. Yes, it should be OK.

3. You can build single executable with LabVIEW 2009 without any conflicts and extra files (because full paths stored in exe with new application builder) . You have no chance to put same files into llb, because structure of the llbs was not changed in LabVIEW 2009. What you can do is - put each class with all SubVIs in own llb. This should work.

Andrey.

[dsavir]

Thanks for your quick reply, Andrey! I'm still using LV 8.2.1 so I can't use the 3rd option, but I'll try the lvlib way and see if it works...

Thanks again,

Danielle

[Andrey_Dmitriev]

As far as I remember, LabVIEW 8.2 had serious issues with classes. Its a time to upgrade (if possible).

Regard lvlib - I don't think, that something will be changed from the builded application point of view. Lvlibs - just method for organising the project (also you can set private/public flag to each file in lvlib and you can have VIs with the same names (Get.vi, for example) in different lvlibs - but they should be placed into different subfolders on the hard drive - exactly the same as with classes).

But your problem that SubVIs linked to dynamically called VI cannot be found. This is Application Builder issue. Try to reduce your project to 2-3 VIs and post it here, so we will try to found appropriate options for application builder.

Andrey.

[Ben]

The advice I recieved from Aristos Queue on this subject was to puta ll of my plug-ins a single folder with a sepearte folder for each Class with all associated VIs of that class living in the class folder. LVOOP could have troble finding the sub-VIs if the folder structure was to complex.

This screen shot is from a LVOOP app developed in LV 8.2.

What was nice about this was once the exe was developed I just had to copy new folders (CLasses) to the Plug-ins Folder and they were availabel in the exe.

I hope that helps,

Ben

[dsavir]

Hi,

I tried Ben's idea, but I saw that if my class uses additional VIs, even from vi.lib, the exe that is dynamically loading the subvi will not find them. I am in the process of creating a downsized version as Andrey suggested, so that I can post it and see if this can be solved.

For example, my subvi (that is loaded dynamically) uses a wrapper class of a TCP connection. Because the TCP files aren't in the same folder, the subvi fails to be loaded and doesn't run becasue "some vi's were not found".

Thanks,

Danielle

[Andrey_Dmitriev]

Hi again,

I have prepared pretty simple project (actually based on well known example from NI - "Dynamic Dispatching")

Here two classes, and each class contain the member "Get Cargo Capacity.vi":

I have also created two Build specs. One is for single "stand alone executable, and another one for exe + 2 llbs, so each class targeted to own LLB.

See what happened:

LabVIEW 8.2:

Stand alone executable:

 because LabVIEW unable to store both Get Cargo Capacity VIs together in exe, they stored outside of exe in \data directory

Executable with LLBs:

LabVIEW still unable to put each member in own llb.

Take a note that in Application Builder settings was:

I will classify this behavior as clear bug.

LabVIEW 8.6:

Stand Alone executable:

LabVIEW still have collision, but now we have Warning (in LabVIEW 8.2 such warning is missing).

Also take a note, that now Get Cargo Capacity.vi placed outside of \data folder.

Build with LLBs:

That is what I have expected: now each class stored in own LLB (they linked together due to classes hierarchy of course). Take a note, that no any conflict warnings appear. Application still working.

LabVIEW 2009:

Stand Alone executable:

Now LabVIEW able to store both member in executable together (even with same name). Great!

Executable with LLB:

No differences in comparison with 8.6

One more test: Stand alone executable with LabVIEW 8.x layout:

Also no differences with LabVIEW 8.6, and all warnings are here:

Not sure that information above was helpful for you, anyway thanks for reading... 

If you have another trouble, feel free to modify one of the attached example and post it here for illustration.

Andrey.

[Ben]

Hi Andrey,

First let me thank you for all of the work that went into that post then second appologize for not responding to the specifics since it will take some of my spare time to read and process all of what you posted. Please let me process this over my Saturday morning coffee when I am not distracted by those paying customers.

Thank you!

Ben

[Andrey_Dmitriev]

Hi, Ben,

Thanks for feedback!

Well, I have one more question for your Saturday Morning coffee..

Lets say - I would like to build "PlugIns" application architecture without static links between core application and LLBs. Each llb will contain one class and can be builded separately and replaced in application without recompiling whole app.

So, SubVIs from PlugIns will be called dynamically:

Of course, all names will be obtained dynamically depends from the installed LLBs, etc. Screenshot above - just simple example. 

But what can I do here:

????

Get Cargo Capacity.vi exists in both LLBs, and for dynamic call I should choose the instance - from which class? LabVIEW (LVOOP) does this job fully automatically - but how can I use this mecanism when memer called by reference?

So, if you will get good idea for architecture - how to combine Dynamic Dispatch with Call by Refs, then feel free to post it here.

with best regards,

Andrey.

[Ben]

Well I did work on my homework but I did not finish it.

I got distracted with trying to pull my big LVOOP app up to LV 2009 and got stuck on a class that would not open so I never did get to the bonus Q. (bummer).

What i was able to do is confirm the 2009 behaviour. AS far as using VI Server Call by ref on Dynamic dispatch VIs... this is teritory I have not explored. I'm not giving up just sliding back.

Ben