Leaderboard

Thanks for the kind words Felix. I showed your post to my wife and she said, "I like this Felix guy." I thought maybe it was because of the nice compliment. Silly me. It's because you have Johnny Depp as an avatar.

Because some people like to think of NI as the Sith Lords of the Empire constantly oppressing the LV users, while the LAVA jedi fight for freedom and openness. It's a bad comparison... after all, you couldn't pay Emporer Palpatine enough to treat you well. NI, on the other hand, has a well defined price list for good treatment. :-)(And now I need to get back to testing the driver software for this new Purple Lightening Generator that NI will be releasing soon. I wonder what we plan to use this for and why we seem to go through beta testers so quickly...) The packed library should be a good way to create a plugin, but you have to play by the rules. (I say "should be" -- I haven't done it myself, but I've heard testimony from others.) 1. A packed library absorbs all the subVIs and other dependencies needed to support its public VIs except 2. VIs and dependencies owned by other packed libraries. That means that you need to make your root class be a packed library so that when you make a single plug-in into a packed library, it doesn't absorb the parent class. Instead, it uses the parent class in the packed library. Then you write your entire framework in terms of that parent class in the packed library. To put it another way: 1. Write Parent.lvlib:Parent.lvclass 2. Build packed library of Parent.lvlibp:Parent.lvclass. 3. Write framework using Parent.lvlibp:Parent.lvclass 4. Write Child.lvlib:Child.lvclass. 5. Build Child.lvlibp:Child.lvclass. Any other class that is going to be used by both your Parent class and your child classes needs to be inside that Parent.lvlibp.

So, ash69 came by my desk to talk about this, then asked me to write up what's going on so he can keep his "one hit wonder" status. He likes being wonderful. Your problem is pretty straightforward. The class in your project is x.lvlib:y.lvclass. The class in the packed library is x.lvlibp:y.lvclass. That single letter "p" is critical -- these two classes are not the same class. There is no guarantee that they have any internals that are the same -- in your case, they happen to have the same private data definition, the same function list, etc, but they are two completely distinct classes, and you cannot just convert one class into another class. We can discuss at length why LV packed libraries are designed this way, but that's not going to help you with your problem. The solution is easy to explain, and a pain in practice. You should build your class -- and only your class -- into a packed library. Then build your current packed library using the class packed library -- it will use the class packed library as a dependency, but won't suck it inside itself. Then use the class packed library in your project. After all that, you will have the same class in your project as in the packed library, and then passing data will work. So, there you go. I hope that helps.

In general I agree with you. However, LV disallows more than just editing when a vi is locked. I can't copy-and-paste code or controls from a locked vi to the vi I'm working on. I can't right-click >> Find All Instances of a locked vi. (That one really irritates me.) Personally I enable those options on my dev computers, but I think it's a tougher sell to make it a default setting.