When did this happen?

[Neil Pate]

Wow, just spotted this menu today.

I right-clicked on a class wire and noticed a menu item with the same name as my class, and inside I got this automatically generated palette.

I guess someone is going to tell me it has been in LabVIEW for like 5 years or something?

[Darren]

I think @Aristos Queue added that in LabVIEW 2019.

[Neil Pate]

12 hours ago, Darren said:

I think @Aristos Queue added that in LabVIEW 2019.

Thanks Darren. Now I just need to remember this feature exists. I work with 2015, 2017 and 2019 regularly so it can be tricky remembering what things are available in which version. Especially interesting is your change to the menu ordering for clean up wire, I have been trying to remember this one for nearly a year now! (I know I can turn it off but eventually I will be using only greater than 2019 so I may as well get used to it)

[Aristos Queue]

In LV2019, I extended the right-click plug-ins to be able to attach a graphical palette so you can drop items from the menu. Then I added the right-click menu item to populate the palette for classes.

And I just found out (thanks, Darren) that LV2020 doesn't update this graphical palette for methods coming from parent interfaces. Haven't even released... already have a patch list. *sigh*

 

[Darren]

9 hours ago, Neil Pate said:

Especially interesting is your change to the menu ordering for clean up wire, I have been trying to remember this one for nearly a year now! (I know I can turn it off but eventually I will be using only greater than 2019 so I may as well get used to it)

I was already used to it because I used this right-click plugin from LabVIEW 2015 until the feature was added natively in LabVIEW 2019.

Also, for cleaning up wires, I find selecting one or more wires and pressing Ctrl-U to be faster than right-clicking each single wire and selecting Clean Up Wire.

[jacobson]

That's pretty cool, does the menu change based on method scope?

[Aristos Queue]

10 hours ago, jacobson said:

That's pretty cool, does the menu change based on method scope?

No. I didn't take the time to do that. Would be cool if it worked though. If you decide to patch it up (there's no passwords on those VIs), I'm happy to ship the revision. 

[jacobson]

On 4/20/2020 at 9:24 PM, Aristos Queue said:

No. I didn't take the time to do that. Would be cool if it worked though. If you decide to patch it up (there's no passwords on those VIs), I'm happy to ship the revision. 

Probably not too difficult of a change to make. My quick approach was to just ignore all private methods that are not part of the original class. This doesn't exclude Community scoped methods but I think you would need to get the LVClassLibrary reference to figure out who its friends are and I'm not sure how to get the reference from the information we get from the framework. From Set Palette for Class

All I did was remove items from the list which were private and not part of the class you right-clicked.

I didn't test it all that much but it seemed to work for the simple cases. Deleting elements from the array ended up being ~4 times faster but this way still works through 1000 elements in ~400us so I can't imagine anyone would have a hierarchy where it would really matter.

 

Class Methods Shortcut Palette.llb

[Aristos Queue]

I don't want to just remove the privates completely ... if you're working inside the class, you may need those. 

But there's an old compromise in the actual palette code... if a library is locked (not just read-only but actually locked) or password-protected, then hide the community and private scope methods. Our theory was that if a class is locked then its internal development is finished and published and any of its friended components are probably also done (or they know that they are friends and can go get that information). Similarly if all children are either non-existent or also locked, then remove the protected scope stuff. 

I don't know how hard it is to get that info without opening a class library refnum. 

I sooooo wish that getting a library refnum wasn't a performance death sentence. I had nothing to do with creating that code. In retrospect, I wish I had stuck my nose into that project. I've looked into refactoring it... it's a mess. 

[jacobson]

On 4/24/2020 at 11:35 PM, Aristos Queue said:

I don't want to just remove the privates completely ... if you're working inside the class, you may need those. 

The equals check should mean that private methods are not discarded for the class you right-clicked on but the private methods of any parent classes will be discarded.

On 4/24/2020 at 11:35 PM, Aristos Queue said:

But there's an old compromise in the actual palette code... if a library is locked (not just read-only but actually locked) or password-protected, then hide the community and private scope methods. Our theory was that if a class is locked then its internal development is finished and published and any of its friended components are probably also done (or they know that they are friends and can go get that information). Similarly if all children are either non-existent or also locked, then remove the protected scope stuff. 

I don't know how hard it is to get that info without opening a class library refnum.

It shouldn't be difficult but I don't know how fast it would actually be. From the class wire you can get the path to the .lvclass file and locked/password-protected libraries seem to just be defined by a single XML tag which isn't there for unlocked libraries. From my experience though, very few classes are locked.

<Property Name="NI.Lib.Locked" Type="Str">locked</Property>