Community access scope of a VI inside a packed library differs between TestStand and LabVIEW

[codcoder]

Hi,

This is actually a re-post of a message I posted in the offical forum but since I've failed to receive any answer there I'm going to try my luck here as well.

So I am having an issue with the community access scope of a VI inside a packed library (hence the title...) and I can't figure out if I have actually stumbled upon something noteworthy or if I simply fail to understand what the community access scope implies.

Let me exemplify:

 

Image 1

I create a library with two sub libraries. I set two of the vi's to public, one to private and one to community access scope. And I create a build specification for a packed library. This is of course an example but it resembles my actual library structure.

 

Image 2

I also let library A be a friend of B (although not doing this doesn't seem to affect anything). In practice I want library A to access certain VI's inside library B but they should not be visible to the outside world.

 

Image 3 and 4

If I now make a build of the packed library and open that build either stand alone or load it inside a new LabVIEW project the packed library behaves as I expect. Only the public vi's are accessible from the outside world but the private and community are not. And, to be clear, this is what I want to achieve.

 

Image 5

Now this is the strange part: if I load this packed library into TestStand, and open it to select a VI, the public VI's are accessible and the private is not (as expected) but also the community VI is accessible. This is not the expected behaviour, atleast not according to my expectations.

So to all of you who knows more than me: Is this an expected behaviour? Is there something about the community access scope I am not understanding? Is there some setting I should or should not activate? Or have I actually stumbled upon a bug?

BR, CC

 

Edited December 19, 2022 by codcoder
Spelling error

[LogMAN]

While community-scoped VIs are only accessible from VIs in the same library and friends, they are still exported.

To see the complete list of exported members, use Get Exported File List.vi or open the library from the Getting Started Window.

Attempting to execute community-scoped VIs results in a runtime error. Here is an example using Open VI Reference.

The same error should appear in TestStand (otherwise it's a bug).

LabVIEW simply hides community-scoped members in Project Explorer for convenience. Looks like TestStand does not do that.

[codcoder]

Thanks for your answer!

So the hiding of community scoped vi's in LabVIEW is cosmetic only?

I guess it makes sense that a VI that must be accessible from something outside the library, let that be the end user through LabVIEW/TestStand or another library, will be treated diferently.

But I still think it's bad ux that TestStand doesn't hide the community scoped vi's like LabVIEW does.

[Rolf Kalbermatter]

On 12/20/2022 at 9:02 AM, codcoder said:

Thanks for your answer!

So the hiding of community scoped vi's in LabVIEW is cosmetic only?

I guess it makes sense that a VI that must be accessible from something outside the library, let that be the end user through LabVIEW/TestStand or another library, will be treated diferently.

But I still think it's bad ux that TestStand doesn't hide the community scoped vi's like LabVIEW does.

It's guessing but I could imagine that there is actually a situation possible where the Test Stand Editor doesn't know about the Friendship of objects but the user may want to select a Community scoped class anyhow. If that class is then executed in a context that has friendship relationship it still succeeds. Otherwise it gives a failure.

Bad UX maybe. A feature that makes things possible that should be possible, quite likely. Fixing that may require to teach TestStand about LabVIEW implementation specific details and present its test adapters in a way that forces dependencies into the TestStand paradigma that it doesn't really care about otherwise. Likely weeks or months of extra work and a brittle interface that can fall flat on its nose anytime LabVIEW makes subtle changes to something in these implementation specific private features. Much safer to leave this inconsistency in there, save time, sweat and money and call it a day.

Edited December 21, 2022 by Rolf Kalbermatter

[codcoder]

On 12/19/2022 at 9:07 PM, LogMAN said:

Attempting to execute community-scoped VIs results in a runtime error. Here is an example using Open VI Reference.

(...)

The same error should appear in TestStand (otherwise it's a bug).

I can confirm that I was unable to execute the community scoped VI inside the packed library from a TestStand sequence.

I didn't fill my VI with anything special, just a dialog box. TestStand reported an error that it was unable to load the VI. Can't remember the exact phrasing, something general, but it was unrelated to the scope of the VI.

So yes, good that the VI with commuty scope atleast can't be executed. But still bad UX that it is accessible.