AQ's workaround for a deployed application (always my situation) is to add the .lvclass files to specific paths inside the built EXE, then provide a path to the class file using the Application Path primitive and a relative path inside the EXE. It doesn't actually pull an instance of the object from the application's memory space using the qualified name, but it's a workable approach since the EXE path can be obtained using a prim.
To specify the location of the .lvclass file inside the EXE, add it to the "Always Included" list in the build spec, then create a "Destination" for it with the full path. For XYZ.lvclass, an example Destination Path would be C:\build\MyApp.exe\XYZ\. When you want to load an object of XYZ at run time, you provide the path C:\build\MyApp.exe\XYZ\XYZ.lvclass
Is there any reason this method would not work in a Shared Lib DLL? I've built a test project with build specs for both an EXE output and a DLL. Both use the method described above, using the appropriate name (...\MyApp.exe\XYZ\ or ...\MyApp.dll\XYZ\) for the Destination Path. The EXE loads the class fine, but the DLL still gives Error 7 on the "Get LV Class Default Value" call. Anyone have ideas/thoughts on this one? Has anyone successfully loaded a class dynamically in a Shared Lib (from memory, not from disk)?
"Get LV Class Default Value" from memory, not from disk
in Object-Oriented Programming
Posted
Is there any reason this method would not work in a Shared Lib DLL? I've built a test project with build specs for both an EXE output and a DLL. Both use the method described above, using the appropriate name (...\MyApp.exe\XYZ\ or ...\MyApp.dll\XYZ\) for the Destination Path. The EXE loads the class fine, but the DLL still gives Error 7 on the "Get LV Class Default Value" call. Anyone have ideas/thoughts on this one? Has anyone successfully loaded a class dynamically in a Shared Lib (from memory, not from disk)?