PPL and Class Community Scope Bug

[vhamm]

I am seeing a issue within a ppl build. I have a lib that contains a class with community scoped vi's. The lib is part of the class' friend list. I have one vi in the lib that calls a community scoped vi in the class. When I compile the PPL, the vi is broken. The name of the vi was "Close Plugin.vi". When I renamed that vi to test and compiled the PPL, the vi is no longer broken in the PPL. I added a test vi in the lib called c.vi and reverted the other back to "Close Plugin.vi". I compiled the PPL. Now, c.vi is broken and Close Plugin.vi is not.

I have an example of this in the attached zip file. This is for LV2017.

[RichieTheBard]

Hi vhamm,

I was unable to reproduce this behavior when I tried doing this from a blank project and trying to follow the steps you described as I understood them, would you be able to provide more on the steps you followed to see if we can reproduce this exact result with other projects.

Regards,

[vhamm]

---

@RichieTheBard wrote:

Hi vhamm,

I was unable to reproduce this behavior when I tried doing this from a blank project and trying to follow the steps you described as I understood them, would you be able to provide more on the steps you followed to see if we can reproduce this exact result with other projects.

Regards,

---

Did you look at the example project/vi's in the zip file I attached?

This example is strictly just some named vi's in the main lib along with a vi in the class that is community scoped. There is no source code in these vi's. I can build the PPL using the saved ppl spec in the project. Then, open the PPL and open the "c.vi". It should appear as being broken.

[RichieTheBard]

Hello vhamm,

I actually did look into the files you attached and I could see the behavior in there, however when I tried reproducing it from a blank project with the same elements, I was unable to reproduce this same result, which is why I would like to clarify those steps to see if I obtain the same result document it correctly.

Regards,

[vhamm]

I see now. I created the project. Added the lvlib to the project. Then, added the lvclass to the project. Add a vi to the class and set the scope to community. Add two vi's to the lvlib both starting with "c". Then, I added the community scoped vi from the lvclass to both vi's and saved them. Finally, I created the PPL build, added the lvlib to the PPL build, and compiled the PPL.

Of note, I found that, if you set the PPL to allow debugging, the vi will not be broken.

[RichieTheBard]

Hello Vhamm,

Sorry for taking so long getting back to this, I tried following the steps you described multiple times in both LV 2017 and 2018 but I've yet to be able to reproduce the error, and I've verified that the hierarchy in my projects is the same to the one in the project you created, and yet both VIs in the PPL are able to run without issue.

Additionally it is very curious that you mention that the VI in the class has to be scoped as community, as this does result in broken VIs immediately and the example you sent uses a public scoped VI, so I'm unsure if that may have a mix up or if I'm missing something related to that.

[vhamm]

The vi in the class is scoped as community in the example. One thing I failed to mention is that the lib containing the class must be set as a Friend in the friends list of the class properties. If not, the vi's in the lib will be broken if the vi in the class is changed from public to community.

The vi should only be broken in the compiled PPL, and insure debugging is turned off in the PPL build specs.