7 replies to this topic

[SteveChandler]

I have written a class which contains LapDog Message Queues as two of it's data members. A vi that I am calling dynamically has two LDM queue controls. In the caller I get the queue objects from my class with an accessor and set the controls in the called vi with set control value.

It works unless the dynamically called vi is in a packed project library. Set Control Value returns Error 91 "The data type of the variant is not compatible with the data type wired to the type input" I tried calling the vi from an llb and that does work. I can send messages to and get replies from the called vi.

What I want to do is to use packed project libraries in a plugin system. I look in a directory for "file.lvlibp" files then look in each of those for a "file.vi", set it's LDM queue controls, and then run the vi. Is this a correct usage of packed libraries?

One more thing. When I build the main vi into an executable and load the vi into a subpanel from an llb everything works but the LDM object controls in the subpanel are missing their icons. They show up as a gray cube with a question mark in them.

I posted this question on "The Dark Side" but have not gotten an answer. I just figured out what The Dark Side is. Why is it called that?

[ash69]

Is there a typedef involved?

[SteveChandler]

Is there a typedef involved?

I think that class controls are all typedefs.

[Aristos Queue]

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.

[SteveChandler]

So, there you go. I hope that helps.

That is going to take a little bit to digest. But thanks!

So is a packed project library a good way to create a plugin? I have not gone beyond simply sending messages to and from the plugin vi so I am not sure what other issues I may run into with dependencies. I want the plugin to be one file that I can drop into a directory. The reason that I don't want it to be an llb is because I discovered dynamic dispatch and llbs can not have two files of the same name.

Maybe it is easier to just stick with a standard source distribution.

[Aristos Queue]

I just figured out what The Dark Side is. Why is it called that?

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

That is going to take a little bit to digest. But thanks!

So is a packed project library a good way to create a plugin? I have not gone beyond simply sending messages to and from the plugin vi so I am not sure what other issues I may run into with dependencies. I want the plugin to be one file that I can drop into a directory. The reason that I don't want it to be an llb is because I discovered dynamic dispatch and llbs can not have two files of the same name.

Maybe it is easier to just stick with a standard source distribution.

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.

[SteveChandler]

Awesome. That really cleared things up. Mostly about the dark side but the other stuff is making much more sense too.

[SteveChandler]

Aristos, I was able to test and understand your solution. So thanks again!