EDIT: Although my original question remains (see original below), I discovered the reason for the problem that ultimately led me to that question, so in that sense my problem is resolved. I'm still curious to know the 'best practice' for using lvlibp, i.e. for a given VI if I need to call a subVI that's in an lvlib, I can either place down the version inside the lvlib, or the version inside the lvlibp. What's the rule of thumb?
=====
I have an executable I distribute and it makes use of a plug-in architecture. For this to work, I used a PPL in the plug-ins, and functionally everything is fine.
As I developed more features, I found that a value I was setting in my global variable in the main program was not reflected in the same global in the PPL. I researched and learned (here: https://forums.ni.com/t5/LabVIEW/How-to-access-common-global-variable-between-different-Packed/td-p/3324410) that because the plugin VI has its own namespace, it creates its own copy of the global.
I sought to rectify that situation by creating a new PPL consisting solely of the global variable, and then using this lvlibp across my entire project. This works, but the problem is - let's say I need to change the contents of the lvlib used to create this lvlibp...it won't let you simply right-click the build specification and rebuild it, because it says the PPL already exists at that location. But nor can I easily delete the existing PPL, because its listed as a dependency. I can delete it from the disk, and then re-open the project, but at that point it searches for the lvlibp and can't find it, so then I have to deal with all those warnings.
The surface solution to this problem, from my standpoint, would be to only reference the lvlib in the 'parent' code, and only reference the lvlibp in the 'plugin' code, but like I said, then they have their own namespaces. Is it ok to use the lvlibp in both, and if so, how do I manage the headache of changing the contents of the lvlib and regenerating the ppl ??
thank you in advance
