Why "Actor Framework" menu in Project Explorer is removed for non-public Access Scope?

[Nate@UT]

The pop-up menu option "Actor Framework -> Create Message" on a method.vi in the Project Explorer disappears when the Access Scope of the enclosing folder/lvlib is set to Community or Private.  Is this a bug or is this by design?  I have to change the Access Scope to Public, generate my Message class, and then change it back to Private (which is cumbersome).  Leaving the Access Scope as Private during run-time does not break anything because I have other "wrappers" which expose the actor-related functionality in a public fashion. 

Thanks!

[CaseyM]

While the message class itself can be private, the payload method that the Do.vi targets can't be. The message class is not a part of the actor class and therefore the method it targets needs to be public. If you make the payload method private, you'll find that you get a broken run arrow. 

[Nate@UT]

@CaseyM, the access scope requirements for run-time operation and access are understood.

But my question is why the menu item to Create Message is removed when, for example, the owning lib or folder is in Community or Private scope. 

I can't see any reason that the Message creation script needs to be disabled in this situation... for example, all classes and VIs could be in the same library at Community scope and should all be able to access each other, but in order to run the Create Message script, I have to change to Public (so the menu shows up), run the Create Message script, and then change it back to Community. 

I would like to keep the folders with scope limited (i.e. not public) so that they don't appear in the hierarchy when I build a PPL, for example. 

[CaseyM · Accepted solution]

I think I see what you're saying. I still don't think it makes sense for privately-scoped folder contents, but I could see an argument for community-scoped.

While I can't guarantee this will be accepted, I'd post this as an issue/feature request on the Actor Framework repo:

https://github.com/ni/actor-framework/issues

In the meantime as a workaround maybe you could consider making a public folder for scripting messages. Drag the community scoped payload method into the public folder to make a message and then drag it back into the other subfolder. That's at least a lot faster than manually changing the scope of the individual VI.

[justACS]

---

Nate@UT wrote:

@CaseyM, the access scope requirements for run-time operation and access are understood.

But my question is why the menu item to Create Message is removed when, for example, the owning lib or folder is in Community or Private scope. 

---

The scope of the owning library/folder transfers to its contents.  If your target method is in a private folder, then it, too, is private.  Any message you create for that method will break, as Casey has described.

Since the result would be broken code, the provider blocks message creation for anything but public methods.

[Nate@UT]

@justACS  actually, the scope of the owning folder does NOT necessarily transfer to its contents... I have a private folder (which I want hidden from PPL hierarchy export) with classes that inherit that private scope from that folder, but that class's methods are Public (not inheriting the private scope of the class).  I feel like I should be able to 'Create Message' for those public methods without changing the entire parent folder hierarchy back to Public scope first.  

[Nate@UT]

Thanks for the AF github link @CaseyM

[justACS]

---

Nate@UT wrote:

@justACS  actually, the scope of the owning folder does NOT necessarily transfer to its contents... I have a private folder (which I want hidden from PPL hierarchy export) with classes that inherit that private scope from that folder, but that class's methods are Public (not inheriting the private scope of the class).  I feel like I should be able to 'Create Message' for those public methods without changing the entire parent folder hierarchy back to Public scope first.  

---

I didn't realize that distinction exists.  Still, the providers only inspect the *method's* access scope (via a call to VI.Get Library access Scope), so VI Server thinks your "public" method in a private class is actually private.  Is your message class broken after you've restored your access scope?

[Nate@UT]

@justACS   No, the message class works fine without complaints when the access scope to the enclosing folder is restored to Private or Community.   Sounds like the VI Server query which uses the library or class's access scope (instead of the method's) is the source of the "bug".  Thanks for the feedback; I'll make a note of this behavior on the github site mentioned above.