JackDunaway

The certification team should also keep tabs on this board.

Quite true -- missed the fact this post is under the "http://lavag.org/forum/44-certification-and-training/" Certification Subforum 

I'm impressed with how much quality traffic the Certification Forum (http://forums.ni.com/t5/Certification/bd-p/Certification) gets -- this is the location with the single highest information density about all things CL(?:A|D|AD). You'll find that both helpful experts and the NI Certification team keep close tabs on that board -- check it out!

After two years "leeching" content every now and then from the Lava community I think it's time to contribute a little bit.

Welcome! And +1 for the meticulous style.

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. :-)

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

How the heck did you figure out this workaround?

To adapt the $10k engineering invoice joke -- "$1 for the hammer strike, $99 for knowing where to strike it, and $9900 for all the recreational programming and nights reading LAVA, Darin.K, et al."

Can someone describe why Error 1 happens? It appears you cannot dynamically register an array of control references if the array is connected on the ConPane -- disconnect from the ConPane, and the error goes away. And it's just for arrays, not scalars. (LV2012 VI attached)

DynamicEventRegistrationForRefsOnConPane.vi

Mike: The problem is that Jack is building two separate packages that need to be built at the same time

Nope - two classes, from the same lvproj (co-developed), built into the same package, with the same VIPB build produces the error.

I've filed this as an issue that I need to look into and will probably be calling on NI for validation.

Thanks, Mike. Again, this lower-priority for me, a somewhat esoteric bug with a simple workaround, so don't twist any arms too hard for the sake of this thread

And as a final update -- I created a source distribution and did not see this error (it only happens with VIPB) -- though I'm certainly not beyond ruling out my own process error along the way that results in these errors.

It might be because you're not a premium member.

Ouch! Below the belt!

No, but I would vote for turning this feature off -- the main reason is when trying to reply to two separate veins of conversation within one thread. Having two discrete posts is more organized. (e.g., for linking to specific content, for readability in digestible chunks, for email subscriptions...) Anyone else have thoughts on this?

When posting a message, then soon after posting a second message on the same thread before another person posts, rather than creating a new message, the second message appends the first message as an edit. Can this behavior be disabled at the user level or community level?

And what rules govern this behavior? It seems that until N amount of time elapses, the next message will edit the first message -- what is N? (Anecdotally, it feels like an hour or so)

The funny thing about this statement is that .lvclass files ARE .lvlib files. Class LVClass inherits from class LVLibrary in the C++ code. So using classes means you're not avoiding libraries (same with XControls). But I'll accept that you're avoiding using sublibraries.

Right, yeah, to qualify, it's sublibraries that I ended up avoiding, for three reasons: 1) Edit-time performance 2) Crazy corruption and linkage problems 3) Architecturally -- to my understanding, loading a LVLIB member loads all the members, and I want members to be loaded ad hoc (lazy-loaded). The main reason I was investigating LVLIB is as an intermediate step to later investigate Packed Project Libraries, which *might* be acceptable in the third category (loading performance) -- just need to benchmark to test the theory.

You should be able to create both modules and then distribute them independently. There's a bug in VI Package Manager that gets in the way of doing this with VI Packages (it insists on packaging the friended library in with the friending library because it does not recognize the weakened dependency relationship), but ignoring that, it should work just fine.

What you cannot do -- and maybe this is what you meant when you said "distribute" -- is *develop* them independently. As I said before, friendship is intended to create a coupling between modules. You can almost think of them as a single module that can be loaded into memory in parts. But they have to be created with full knowledge of each other.

OK, I may have been inappropriately attributing this deficiency to lvclasses; I'm co-developing the classes (so we're OK there -- this friendly signage is probably occurring) and distributing using VIP (so here may be where the bug is introduced). The password protection is not existent in development; it's applied with VIPB. (I've alerted Michael of this thread, to weigh in)

To conclude, it's possible that I could further investigate at an academic level by creating a source distribution (rather than VIP) just to confirm password protecting is not a LV native hurdle to friendship; but this is kinda low on my priority list right now. (publicizing the few methods and moving along is way less painful)

[specifically for Jack's architecture]

I think what you want is this:

Create FlyFactory.

Create FlyPlugInBase. Add FlyFactory as a friend. Define some community scope members for FlyFactory to call. Those members wrap some protected scope members. Distribute both FlyFactory and FlyPlugInBase together.

Your users can inherit from FlyPlugInBase and override the protected scope members. FlyFactory always invokes through the FlyPlugInBase interface.

Yeah, but the one part left out of this sequence is password protection prior to distribution.

Once the two co-developed classes were password protected and co-packaged via VIPB, then installed to another machine via VIPM, FlyFactory was broken since it called community members of FlyPluginBase, since FlyPluginBase could not identify FlyFactory as a friend since FlyFactory is password protected.

To be clear, this is the problem I attributed as a LVClass deficiency, but you're saying it could be a VIPB issue.

> Does this imply that it's a bad design decision to distribute password

> protected libraries that have community-scoped members and friended libraries?

No. As a matter of fact, this is meant to facilitate doing this.

Wait... whaaaaa? "Facilitate" is like the opposite of what happened here

We'd, of course, need some way to override it to be able to continue to distribute additional classes as plugins

Wait... what? Plugins would be easier without strict filenaming convention defining hierarchical relationships.

You're right in that it's a workaround, but I wouldn't call that a solution.

Quite true. What I'm doing is not unlike the Flyweight Pattern, where the Flyweight friends the Flyweight Factory. The Flyweight would ostensibly mark many of its core methods as private, but since the FlyweightFactory (and only the FlyweightFactory) needs access, they can't be private. Friending seemed like the right implementation strategy (Inheritance is just wrong, and publicizing methods feels icky), but is incompatible with password-protecting the libraries.

So, the "icky solution" stands for now, but I'm up for re-evaluating design decisions for a better solution.

***EDIT: And again, to ensure minimal feather rufflage -- the title Community scope "unfriendly" to password protection -- bad design decision? was meant to ask if *I* am making a bad design decision; not to ask if it was a bad design decision by LabVIEW to not allow friending between password-protected classes. ***

I'm pretty sure I know what the answer will be from a certain NI employee whose name starts with Aristos and ends with Queue...

To be clear: there's no lvlib protecting the actual classes correct? It's just two classes with password protected member VIs?

Errmmm... yeah, about that (blush)

My first attempt at distributing with a "master LVLIB wrapper" was a dismal (personal) failure. Performance fell through the floor. Trying to pull classes back out of the LVLIB caused massive project-wide corruption in several classes. I'm pretty sure this initial attempt was my own fault... which essentially consisted of selecting a few dozen classes and dragging them all into an LVLIB at once (don't try this at home, kids). Perhaps a more gradual, graceful approach to building the LVLIB would have been more successful. But another technical hiccup would have involved the desire to lazy-load individual classes, and to my understanding the "master lvlib wrapper" would cause them all to load at once.

I still have my eye on LVLIB and even Packed Project Libraries as a distributable, but finer points such as this must be set aside for now. That was a long answer for your simple question, but "yes", I'm just trying to distribute two naked classes with a one-way friendship relationship.

And the current workaround: change scope of those methods from "Community" to "Public".

While trying to distribute two classes with password-protected class members, where the first Class A has friended Class B, I'm getting the following error:

"The first time you establish access to a community scoped item in a password-protected library, you must enter the password for that library. This can prevent users from replacing a friended class on disk with another class of the same name. Enter the password for the locked library in the Project Library Properties dialog box."

Does this imply that it's a bad design decision to distribute password protected libraries that have community-scoped members and friended libraries?

Season six of the guild starts today. If you haven't been watching it, I have been informed that your LAVA membership will be revoked.

OK, my LAVA membership revocation is no longer a threat... it was *borderline* painful to watch, but had some particularly clever humor/writing. And a comparison to The League (or Sunny) is not bad with the dark humor between the gang, not to mention Zaboo is about as unsavory as Rafi. Considering watching season 2 against my better judgment

Not a joke, we're trying to drill to the center of the earth: http://edition.cnn.c...sion/index.html

"It will be the equivalent of dangling a steel string the width of a human hair in the deep end of a swimming pool and inserting it into a thimble 1/10 mm wide" --Damon Teagle, University of Southampton, UK

(crelf: no TWSS jokes out of this quote are allowed)

I mean, if I can watch a season in 43min... will give it a shot. (Personally, can hardly wait for AHS to come out again in a couple weeks, so I'm leery about introducing anything new that might upset the show lineup...)

Can you give a teaser on why it's so good? (I've not seen you give such a strong endorsement since Arrested Development!) Kinda looks like... The League meets Big Bang Theory