Set Control Value Error 91

[SteveChandler]

I am attempting to use set control value on a dynamically called vi. The control is an object.

Everything works unless I dynamically load the vi from a packed project library. When I do that then Set Control Value returns Error 91 "The data type of the variant is not compatible with the data type wired to the type input"

[JÞB]

Probably not just an object --- but the object of type ? for a dynamically dispatched vi.  Close?

[SteveChandler]

The object is from a library (LapDog Messaging Library) that I downloaded and put into vi.lib. I have written my own class which contains an LDM queue as one of it's data members. The vi that I am calling dynamically has a control of the LDM Queue type. In the caller I get the queue from an accessor and set the control in the called vi with set control value.

It works unless the dynamically called vi is in a packed project library. I tried calling the vi from an llb and that works as well.

[SteveChandler]

I have two objects on the front panel of the dynamic loaded vi that look like this.

When I build the main vi into an executable and load the vi into a subpanel it looks like this. I can still use set control value on them and talk to the objects in the loaded vi from the caller. But I get error 91 if I try to load the vi from a packed project library.

[Paul-D]

Hey Steve,

I've been reading through your problem, and am not sure if I have complete grasp of it yet, however I'd like to work with you to get this resolved.

If I'm understanding correctly, you are only getting this error when compiling to an .exe, correct?  This throw flags that you haven't properly included this lapdog library in your build specifications.  Check out the following document:

http://zone.ni.com/reference/en-XX/help/371361G-01/lvconcepts/packed_libraries/

The part that specifically drew my attention was:

'If a stand-alone application, a shared library, or a packed library calls a VI in a packed library, include the called packed library in the same directory as the other build specifications. When a build specification calls a VI in a packed library, you can replace the library with an updated version only if the connector panes of the updated packed library are compatible with the build specification."

If that document doesn't help, maybe we can work together to get some more info so that this can get resolved.

Thanks,

Paul

[Michael G]

Hi Steve,

Like Paul, I'm not sure I know exactly what you have set up but beyond the references he pointed out you may also want to have a look at this: Caveats and Recommendations for Packed Project Libraries.  Specifically I am wondering if the last bullet point in that document may have some impact on this situation:

"If an exported VI has a connector pane with inputs or outputs of type definitions or classes, include the type definitions or classes in the top-level project library. When you right-click a project library and select Replace with a packed library from the shortcut menu, LabVIEW does not replace type definitions and classes, only exported items of the packed library. As a result, VIs in the packed library might break when you replace the project library with the packed library."

Please let us know how you're coming on this issue.

-Michael G

[SteveChandler]

Thanks Paul and Michael. I posted the question on Lava and got some input from Aristos Queue. I think I will be able to get to the bottom of this with help from all of you. I will be working on resolving this either today or later this week and will post back what I find.

[SteveChandler]

One quick question. From the document

To replace a project library with a packed library in a project, right-click the project library and select Replace with a packed library from the shortcut menu. When you select Replace with a packed library, all caller VIs of the project library in the LabVIEW project update with the qualified names of the packed library.

I can't seem to find a way to do the reverse - replace packed project library with library. That seems dangerous.

[Paul-D]

Steve, hate to keep dumping articles on you, but I haven't had much experience with packed library's yet, so I'm learning as we talk about it more.

Check out:

http://zone.ni.com/reference/en-XX/help/371361G-01/lvhowto/converting_packed_libraries/

Also, it appears that someone has posted a suggestion for dealing with these, that may be something you're dealing with also:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Need-a-Way-to-Reverse-Replace-Packed-Project-Library-w...

Hope, you're on your way to figuring it out.  Let us know how you are coming along.

[SteveChandler · Accepted solution]

Thanks Paul. Here is where I am at.

I am writing a main application that will be built into an exe. The exe will load plugins from a directory. I want the plugins to be one file so I was originally putting source distributions into llbs. That works fine until you have two files with the same name even if they are in their own libraries. That lead me to packed project libraries.

The issue as Aristos explains on Lava is that the class I am using in my main application and in the packed project library are not really the same class because one is in a lvlib and one is in a lvlibp. So I have to put my class into a library and build a packed library from that. I then use this packed library in both my main app and the plugins. Since the main app and plugins are using the same lvlibp they are using the same class and everything works. So I am going to mark my own post as the solution since Aristos don't post here.

That is kind of a pain though. The class I am using for communication is an object messaging class called LapDog Messaging Library that Daklu created. It is just like a normal queue except that the datatype is a class. That means that I will have to put all my message classes into a packed project library. Because of that I am going to rethink sharing classes between my main application and plugins. Maybe I will use something else such as the AMC library.

Fortunately it is still early in the architecting of this application. I just discovered the difficulty by doing a proof of concept prototype.