Cannot dynamically launch Friended Community Scope Method? [screenshot + code]

[JackDunaway]

It appears that in LV2012, it is not possible to dynamically launch a Community Scoped Method from a class that has been friended by the launchee. I think the screenshot below paints the picture (it just doesn't show that LaunchMeDynamically has friended Launcher)... also attached is the example project.

As expected, we can launch a Public Method no prob; we get Error 1390 when attempting to launch a Private Method; but Error 1390 is unexpected when trying to launch the Community Method.

Is this a bug with my application or with LabVIEW?

DynamicLaunchScope.zip

[JackDunaway]

Short answer: this is expected behavior.

Longer answer, keep reading:

R&D member wrote:

This is a deliberate decision.

Short story: The solution to your problem is to create a member VI of the class that calls Open VI Reference and put that VI in community scope OR to use a static VI reference instead of Open VI Reference. Since friendship relationships are explicitly defined generally for specific functions, explicitly coupling the modules with an explicit subVI call or with a static VI reference is generally acceptable.

Longer story: Below in italics is the citation from the feature specification.

Dynamic VI Invocations

Friend VIs will always be able to use statically configured Call By Reference nodes and static VI references for VIs accessed through community scope. They will not be able to use Open VI Reference. Because the security model depends upon the existence of a linkref from one VI to another VI, we can only allow dynamic connections that are confirmed when we're editing the VIs.

Note that a VI which is in community scope, but could be reached through private or protected scope, can still be used with Open VI Reference. This means that to invoke a dynamic reference to a community scoped VI, the Open VI Reference call has to be done within the class and then passed out to the code that will use it.

Note: We did consider that Open VI Reference would be allowed to work in cases where Alice.lvlib did not have a password or where the password was already in the cache. However, that seemed like a really bad idea -- the user writes an application, gets everything working and, as a final step, adds password protection to his application. And now it breaks when deployed. That seemed like a recipie for disaster. We also considered changing the Open VI Reference call to have a password input, but that complicates a very commonly used function with an input for a very rare use case. Far better to just restrict the dynamic access to relationships that can be established at edit time. With the richness that the Call By Reference node and the static VI reference have brought to LabVIEW, we think that any use cases the programmer has for friendship can be handled easily enough.

My response:

R&D member wrote:

This is a deliberate decision.

Thanks for the response!

R&D member wrote:

With the richness that the Call By Reference node and the static VI reference have brought to LabVIEW, we think that any use cases the programmer has for friendship can be handled easily enough.

Except... when the goal is to remove static linkages, so that the caller (friended class) can exist before lazy-loading and dynamically calling the callee (friending class), thus loading its extensive hierarchy. The workarounds provided above require static linkages and prevent lazy-loading.

Any thoughts on another way to achieve this goal of lazy-loading through invocation of a community-scoped member?

And the response:

Yes, I have a workaround, but it's a bit convoluted. Friendship was designed as an extension to the thing being friended -- the original item should be able to be in memory without the friend, but not the other way around. Still, you could do it like this:

Current:

Class A friends Class B

Change to:

Class A friends Library C friends Class B

A library does not load all of its member VIs into memory. So give Library C two VIs:

VI X calls statically into community-scoped members of class A. X is private to Library C.

VI Y does Open VI Reference to load VI X. VI Y is community scoped and is called from Class B.

B is statically linked to C:Y. C:X does not load into memory until it is dynamically loaded by C:Y. When it loads, it loads B into memory (or B is already in memory).

So there you have it! This proxy library pattern is working fine for me as a solution, but I think for the majority of these cases it's easier just to use Public rather than Community scope on the dynamic callee. :-)