I am facing the problem that one of my LabVIEW-classes, contained in a packed library, can't be loaded dynamically when the overall program runs as a exe in the LabVIEW Runtime Environment (Error 1498 from "Get LV Class default value.vi"). If I run the main.vi of the program in the development environment, it loads the class from the packed library without failures and there are no entries on the "load and save warning list".
Also I don't see any errors when I open the unpacked library.
So I assume that there is some kind of error in the packed library version of the class which gets repaired automatically by the development system but not by the runtime.
Is there some way to get informations about the auto-repair things the development system is doing (some log file ...).
Additional information I am using the Professional Development System 2014. The specific class is part of a class based framework consisting today of about 200 packed libraries depending on each other and containing one or more classes each. All the other packed classes work fine.
Therefore I would need some help on methods HOW to find the error more than specific help on the potential errors themselfes.
Which developping environment are you using ?
I never packed LV-classes into PPL but did you try to include LV-classes into PPL build ?
thanks for the fast reaction - I have added the information in the original post.
Wow it is hard enough when i am working with 20 PPL (max i did) but 200 !!!! I am impressed and wonder which kind of project need that much !
Can you say if your LV-classes are "always included" in your PPL build source ?
Debbugin applications with PPL is not trivial. You have to open each PPL and check if there are dependencies not expected, no misssing items.
Regarding the behaviour your explaining i can only see one LV-classes not included.
One option which could save you time debugging is to look at "Source File Settings" category, tick the "Set save settings for all contained items".
You won't be able to modify code when oppening your VI but you could see code below.
Hope this help.
I were able to track down the error to including a typedef cluster from a parent class in the private class members. So at the end it helped to check the option "Remove Typedefs from build" in the build-properties (this was a hint from the NI support).
To find the problem I first deleted all class members and methods and then inserted them one by one, compiling and testing the packed class each time and removing the typedef connection after inserting the cluster to the private member cluster.
There seems to be no logfile of the runtime or somthing else which gives more specific error description on loading failures.
I also forgot to give one information on the error here in the forum - after the primary error message occurered and the program stopped (not closed), the "Starting button" was broken. When pressing it again, the error 2208 occurerd multiple time (filling the complete dialog box). This didn't help to find the error, but maybe it helps someone else to find errors like that.
Thanks for your help,