04-09-2024 08:51 AM
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.
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.
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.
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.
Solved! Go to Solution.
04-09-2024 09:14 AM
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.
04-09-2024 09:57 AM
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.
04-09-2024 10:01 AM
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.
04-10-2024 04:50 AM
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?
04-10-2024 08:27 AM
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.