LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Cannot get dependency VI names from VI in packed library

Solved!
Go to solution

I'm trying to build a packed library that utilizes OpenG's Dictionary functionality. The VIs work from the development environment, and built executables that utilize the library work, but the .lvlibps do not. I've traced the (first) error to Dictionary Open Object Reference, which simply takes a VI name and opens a VI reference. 

Nokaroa_0-1712669962375.png

The Data Store VI Name simply runs the Dictionary Object Data Store VI (a FGV vi that doesn't do anything here) and uses the depreciated "Callees" property to get the name. 

Original Dict Data Store VI snippet.png

Simple enough, except when I build a lvlibp, even after double checking that the dependency is in the packed library, "Callees" comes up blank. I've made a modified version that uses "Get VI Dependencies: Dependency Names", but the same behavior is observed. It works in the development environment, but it's blank in the packed library.

Modified snippet.png

I have tried making sure to include the dependency in the build (it's confirmed by the build log), moving it from user.lib to the same directory as the caller, playing with settings in the packed library build. No use.

 

Ultimately, it's just returning a string name, but when I hardcode the name and try to run the call by reference with that, it cannot find the VI. I feel like solving this issue would solve that one so I am prioritizing this one.

 

0 Kudos
Message 1 of 6
(648 Views)
Solution
Accepted by topic author Nokaroa

Update

I have discovered that the subVI is a preallocated clone, and that seems to be what causes the issue. If I change it's reentrancy type, the expected behavior returns.

Message 2 of 6
(632 Views)

I haven't used the OpenG version, but nowadays you have Maps and Dictionaries in LV as standard, unless you're referring to something else.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 3 of 6
(607 Views)

I don't recall exactly why I went with OpenG's implementation over the built in. I think there was some functionality that was missing. Regardless, I could refactor everything but that isn't the issue that I posed the question about, and the behavior is something I'd like to understand since it isn't inherent to OpenG. 

0 Kudos
Message 4 of 6
(605 Views)

Wild guess: Since must data/information is lost when packing into a library such information is simply not there. If you activate the Debug flag that information might be retrievable?

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 5 of 6
(571 Views)

Nope, it is not retrievable even with the debug flag. It has something to do with how preallocated clones work and unfortunately I am not versed on LabView memory management. I solved my issue by just hardcoding the VI name so I am going to mark the issue as solved, but I feel this is a bug in the library packer. 

Message 6 of 6
(558 Views)