Using LVOOP DVR Based Classes within PPLs

[ak_nz]

Hi All,

 

I have a project where a LVOOP class is accessed by reference (using a DVR). The method of using a DVR was chosen because the object data will be modified internally by private methods, multiple clients need access to it and we are likely to need more than one of them, making LVOOP and DVRs a natural fit. This means that the object is only accessed by a DVR of the object class (with New, and Delete methods to create and delete the DVR). Built and tested in LV 2012 SP1 patch f3.

 

The object is intended to be reusable, so it was built into a Packed Project Library (eg. "PPL.lvlibp"). Using this PPL in another project works comfortably.

 

It is often useful for us to rename the original PPL filename to prevent conflicts (eg. "PPL Renamed.lvlipb"). Validation is not an issue here since we can programatically access the Oriignal Filename and Version of the PPL for verification. However if I attempt to access the class inside the renamed PPL, LabVIEW informs me I have a "class conflict". I assume this is because the qualified name of the class and methods inside it are now namespaced by the PPL.

 

If I attempt to run a top-level VI making the calls to the DVR class LabVIEW will frequently crash (often without the NI Error Reporting Service detecting the shutdown), sometimes with a variety of .cpp errors. Scary stuff, someone's telling me I'm doing something wrong.

 

Does anyone have any experience with this? If I don't rename the PPL, then things seem to work as expected (ie I can create, play with and then delete my new reference object). It seems interesting that renaming the PPL has this effect if there are no other dependencies, unless subVIs in the class can't be properly resolved. Is there any information on the stability of using LVOOP DVR classes within PPLs? Or the structure of PPLs that renaming the filename would effect? NI recommends using a renaming scheme in their white-papers regarding dependencies amd PPLs, but this strategy appears to cause more problems than it solves in this particular scenario.

 

Any help or guidance appreciated.

Edited June 18, 2013 by ak_nz