Leaderboard

HEY!!! I have a perfect example for everyone of stuff to not go poking around in! The "Get LV Class Default Value.vi" ... if you pop it open with your favorite password cracker, you'll find a Call Library Node. You pass into that Call Library Node a path and an app instance refnum and out comes the LV class. And now you're thinking, "HEY! Aristos Queue didn't put that app instance refnum on the conpane of the VI! He's hiding functionality from me! I can use this to get the value of a class in another application instance!" And so you wire up a different application instance. And you run your VI. Now, sometimes you crash right away. Other times, you don't crash until you try to close the project. Other times you just get a crash on exiting of LabVIEW. In any case, you've thrown off the reference count for LV class data because -- ha -- it is an ILLEGAL OPERATION TO PUT CLASS DATA FROM A CLASS INTO THE WRONG APPLICATION INSTANCE. You have to marshall the data from one app instance into the other app instance, because the *class itself* might not exist in the other instance, or might exist with a different definition (i.e., in one app instance you loaded c:\x.lvclass and in the other you loaded d:\x.lvlclass). And, hey, if you want to go indexing off the end of a pointer into undefined memory, this is a great way to do it. I swear, by all the nodes and wires in Heaven, none of this stuff has any business being on any block diagram except for the one that it is on and that we password protected. It is either useless to you or subject to change in a future version of LV because we're still refining it and have no intention of supporting the current version (unless it passes testing and we decide to make it official, but we might not have time to do that in a given release, so it may take a while, so just because it has been there and private for a few releases doesn't mean it will be there forever).

Yeah... I misunderstood. And I've run into the same problem. I've already been working on LV 2013 to add these functions. In the meantime, I gave Staab a workaround. If it works for him, I'll let him repost it here. (an unfortunate but workable workaround for limited use cases).

It was a huge leap from CS101. CS101 was about 3-4 hours of lecture a week and maybe 5 hours of homework. CS212 was (by my recollection) 6 - 8 hours of lecture and it was taking me 12 - 20 hours to do the homework. My main difficulty was familiarity with the libraries in Python and how to use (exploit) them. I had to call it quits at week 2 (of 7) as I didn't have that kind of time to dedicate. I didn't use the forums for CS101 and started using them for CS212 (they really helped with a couple of questions). I just checked and I'm still taking the course despite it being past the exam. I'm planning on going back and at least watching the lectures as there was good content in there.

Badly in need of vacations . and btw i'm old enough to have earned the right to be grumpy every now and then. While I understand his desire to dig deeper in some other posts he did, I have to say that I do not see any sense in trying to see a specific intention in a pattern on screen that was chosen over 20 years ago, for some reasons, that might be obscure or not. And I would also like to have a peek at the LabVIEW source code, except that I would most likely have to realize that it is just way over my head, so I pass that opportunity and keep myself in the illusion that I might understand it.

I think NI shares a lot with the community. There are a lot of internal details about LabVIEW in the NI KB. There are special INI tokens documented, how we flatten data, how LabVIEW behaves in a lot of solutions. You might want to look through some of our KB articles if you're curious about the internal workings of LabVIEW. However, I do not think that alpha releases are for incomplete features. Just because we have a feature that's half-done doesn't mean that everyone should be able to use it. There are good reasons we don't finish some features -- they aren't stable enough, they're too resource-expensive, they don't meet the needs of our customers, etc. If we release a feature, we will support it. We still support some decade-old hardware. NI has great technical support. But we can't support everything. I don't speak for NI, but I suspect we would rather support everything we release rather than release everything and have holes in what we support.

And you use of course TypeDefs??? Maybe it's the combination of Removed Compiled Code and TypeDefs beloning to a library/class?!?! I've never experienced this before I removed the Compiled code, and I have been coding LV daily, between 8-16 hours day for the last 17 years Next time it happens close the VI and remove the Object Cash and see if that fixes the problem.

I've missed this post Congratulations! They are beautiful. Hope your nights are not too noisy

I hereby resurrect thee... Was looking for this today myself. This is what I came up with: Added benefit is if you supply a variant, the VI will make sure that the returned GUID has not already been defined as an attribute key. It of course generates an entirely random number which doesn't conform to any specification that places significance on certain bits etc...but it suits my needs just fine (creating positively unique keys).

Lava. Without it nothing else would have mattered for me. Yeah, it's not really an *official* Labview design feature, but it's the best learning/documentation resource that's available. The Blues that freely share their insights here are a big part of that.