Jump to content

Set Control Value On Object Control Returns Error 91


Recommended Posts

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?

Link to comment

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.

  • Like 1
Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.