JackDunaway

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!

Welcome! And +1 for the meticulous style.

Short answer: this is expected behavior. Longer answer, keep reading: My response: Thanks for the response! 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: 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

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."

Here's a new fix that is much better than the Variant fix: it looks like the "Always Copy" node once again pulls through as the CAR-buster:

Thanks, James! I've chimed in and cross-posted on that thread. (Bad news? This is kinda great news, for my sanity....) And here's a janky workaround, instead exposing a variant on the ConPane then converting inside the SubVI:

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

Chris Anderson recently interviewed Elon Musk -- great conversation between two real-life "LabVIEW Champions"* here: http://www.wired.com...on-musk-qa/all/ Brief intro to these two, and how they are connected to LabVIEW: Elon Musk founded SpaceX and Tesla Motors (both companies use LabVIEW extensively) after selling Paypal. Chris Anderson showed support in the LabVIEW community championing a lower-cost LabVIEW, spurring an IdEx Idea with 400 supporters for a new version of LabVIEW that would increase market penetration of graphical programming.

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

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.

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)

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

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

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

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. ***

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".

I'm having a separate GChat about this issue, and will copy what I just wrote moments ago: "the main prob is that filenames (rather than embedded GUIDS) are used as identifiers in class hierarchies. it's frustrating. same thing bites you with Dynamic Dispatch VIs -- they must have the same filename (which I personally find annoying)... filenaming convention should be abstracted from class functionality" So, I think we're independently coming to the same conclusions here, crelf *** EDIT: and this is not a bash against the current convention, I'm sure it exists for good reason. It's just that I'm running into problems, and just trying to flesh out the best practice ***

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?

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