On auto-generated class palette, properly scope available VIs

[_carl]

Let's say I have a class with a few public VIs, and several private VIs and typedefs:

Assuming I'm not working on a VI within the class, If I'm using this class on a block diagram, I can only use the public VIs.

However, if I right-click on the class wire, and go to the auto-generated class palette, it shows everything.  This can be absolutely overwhelming with larger classes.  Why not scope this palette appropriately?

[IlluminatedG]

I'll add that as this is the only way to get to VIs in parent classes of items pulled into PPLs, the class member palette could really use some love. (Unless an option is added to export items pulled into PPLs). I'll pull down some code on my new machine and post a screenshot of one of my worst offenders later.

[JimChretz]

Also, the context help should not display private data content when hovering on a class wire.

[Jacobson-ni]

I think you might be able to implement this behavior yourself following what I did in the following post. I didn't test a lot of scenarios but the general approach is probably still correct.

https://lavag.org/topic/21514-when-did-this-happen/#comment-131576

[BertMcMahan]

I'd expand this idea to let this be settable in the Class Properties by folder. For example, the QControl toolkit duplicates ALL item settings for a given reference with OOP wrappers, which is super helpful, but makes the right click menu completely useless. Those methods do have to be public, but you generally don't want them in the right-click menu because there are a thousand of them.

If you could designate folder options to have a box for "Visible in right-click menu" (or better yet, have your virtual folders be auto-generated subfolders in the right-click menu) then it would be REALLY easy to make custom right-click menus without having to generate and maintain .mnu files. IIRC, VIPM does this when you make menu files. You can tell it to ignore certain folders or auto-create the mnu file based on the on-disk folder structure.

[IlluminatedG]

Well I was digging for some other stuff and came across the plugin that does this. How about adding another tier to the class palette entry to see scopes, so there's be another level of menus for public, protected, community, and private. And then those would expand into appropriate palettes. Fewer edge cases to worry about hiding VIs unnecessarily, just need to know what submenu to look in. Still requires the developer to know what scopes they're allowed to access from the BD they've right-clicked from but at least it would pare down each scope's menu a fair bit.

[BertMcMahan]

@IlluminatedG  Could you link to the plugin you found? Sounds useful.

[IlluminatedG]

It's at <LabVIEW>\resource\plugins\PopupMenus\edit time panel and diagram\Class Methods Shortcut Palette.llb