Application Builder 6.1 and dynamically loaded VIs

[Serge @ BCO]

Recently I've created plug-in based application and it works fine in design time. It works fine as an executable as well, but it is really necessary to explicitly say which VIs are dynamically loaded, EVEN if I am distributing my plug-in containing *.llb along with the executable. Is there any way around this problem? I see poor sense in plug-ins in the case if the complete application is going to be rebuilt. I am using plug-ins stored in *.llb and VI server's "call by reference (strict type)" node to load them. My plugins are also using GOOP stuff but I do not think it makes any difference to the problem described. LabVIEW version is 6.1 and all the stuff got mass compiled. Any suggestions and opinions are very welco
me, Thanks,

Serge Musteata (serge@bco-inc.com).

[JeanPierre]

Serge,
I can talk about 6.0 but i don't think it has changed in 6.1.
If you want to implement the plug-in architecture, calling by reference VIs in other LLBs, you do NOT want to include the VIs as dynamic VIs during the build.

Dynamic VIs in an application is a convenient feature that allows to easily include in the build libraries the VIs that are not include in the Top Level VIs hierarchy. VIs checked as Dynamis are stored in the executable internal LLB (in the .exe) and that is the first place that is search for when you try to open a reference to a VI not currently in memory. If a VI with the same name is found there, the actual path is ignored and the internal VI is opened. The effect is that if you also include these VIs in an external LL
B they can't be opened at all.

For a plug-in architecture, not only it is not necessary to include dynamic VIs in the build but you must not include them at all! If you provided the correct path to a VI in a plug-in LLB the VI will open, no need to set it dynamic.

Probably you found that it worked fine when including them as Dynamic VIs but you didn't realize that the VIs opened were the internal copy in the exe, not the VIs in the LLB. Try to modify the LLB with a new version and you'll see it doesn't work. The old internal version of VI is always loaded.

With the plug-in architecture, you don't need to recompile and rebuild for every new version of the plug-in. Just replace the plug-in LLB. This can't be done if the VIs are included as dynamic VIs.

If you have more questions, post again.

[Serge @ BCO]

Jean-Pierre,

thanks for your answer, "not to include" rule was essensial. Now another question (if you don't mind and if I am not way too annoying 🙂 ) - in the case if my plugin (which is dynamically loaded VI) contains another subVIs or LabVIEW primitives which has never been used by static VIs from my application, what happens then? Well, I beleive that all primitives are compiled and stored in the RTE dlls, but really, how about subVIs? Does VI Server looking for them in LLB-s or in the current application directory? Let's say i have 3 plugins in 3 different LLB-s using the same subVI, which I want to share between plugins and store in separate LLb for this purpose. Will it be found by VI server in this case or will I have to include this subV
I in all 3 LLbs? I'll try to narrow the question: will the VI server be looking in all LLb-s from current application directory or will it be just browsing existing VI-s? If to narrow the question even more then finally I'm coming up with a real brief one:

What is the search algorithm in this case?

Thanks in advance, all responces are highly appreciated,

Serge.

[JeanPierre]

Serge,

You are right about primitives, you don't have to care about them.

The first place which is looked at when loading a subVI is the relative path e.g. look for that VI in the same directory or for that VI in that llb in the same directory. If your plug-in llbs are put on the target machine with the same relative paths as where you saved them before deployment, you won't have search VI problem.
If the VI is not found there, I think that then it is searched at its absolute path and after it is searched in the VI Search Paths list in the order defined in the application options.

[Greg_McKaskle2]

Just to add a few point.

The first place that LV looks is in memory. At the current time, the VI
name is the thing the linker uses to uniquely identify each VI and
subVI. If a VI by that name is already in memory, that is what it used.

Next is the relative path from the caller to the callee. Then the .ini
settings for search path is used from top to bottom. The special items
like are symbolic in that they stand for possibly many
directories, in this example, the other directories that the search
succeeded or where you point them out.

Greg McKaskle

[Serge @ BCO]

Thank you, guys,
It's exactly what I wanted to find out

Serge

[JeanPierre]

To summarise, especially for built executable:

1) The first place that LV looks for a VI is in memory. If found there the path is ignored.
2) Then (for exe) in the internal LLB. VIs stored in the exe internal LLB by the Application Builder are those set as "Top Level" and "Dynamic VI" (These VIs' subVIs are stored either in internal LLB (single target file) or the external LLB (small target file+external LLB). Again if the VI is found there the path is ignored. That is also true for dynamic loading.
3) at the relative path from the caller to callee
3b) I wrote above that I thought the absolute path was also looked but Greg doesn't say so. I'll believe Greg.
4)in the ini settings for search paths and directories whe
re VIs were successfully searched and found.

[Greg_McKaskle2]

....
> 3) at the relative path from the caller to callee
> 3b) I wrote above that I thought the absolute path was also looked but
> Greg doesn't say so. I'll believe Greg.

Good summary. It may sometimes look like LV is using an absolute path,
but the only time that really happens is when the relative path is to
another volume or drive. At that point, the relative and absolute path
are the same.

Greg McKaskle