Quick Access to a LVOOP Class Library via the Right Click Menu

[Alex.T]

We're all familiar with how fast programming in LabVIEW can be when using the right click menu to quickly access the associated palettes of the function we've right clicked over. Below, we can see that right clicking on the DAQmx Create Virtual Channels VI gives us direct access to the DAQmx - Data Acquisition palette. This is a lot faster than manually navigating to the Functions Palette to get the same result.

However, nothing similar exists for when programming in LabVIEW Object Oriented Programming (LVOOP). Development for LVOOP programmers would speed up dramatically if they didn't have to switch back and forth between their VI and the project window when making use of VIs from their class library.

The idea is shown below. On the left, we have the current Right Click context menu available in LabVIEW. On the right, the suggestion; the programmer is able to search through all of the VIs that are accessible to the class without having to scroll through the Project Window.

[Alex.T]

... A second 'Replace' menu tree is however not a part of the idea! 

[jcarmody]

I wonder how difficult it would be to convert this JKI RCF plugin to a Quick Drop plugin.  <famous last words> I've done it a few times and it was pretty trivial. </famous last words>

[Intaris]

How is this different froms imply defining a default menu for a class?  This is already possible under the properties of the class in the project window.

I do this all the time.

Double-check the properties for your class and note the setting "Default palette for class" or something similar.  Make a menu for this any link it to your class.  Voila, you have what you want.  This has been in LV since 2009 I think.

Shane.

[fabric]

"How is this different from simply defining a default menu for a class?"

I think the drawcard with this idea is that you shouldn't *need* to go through hoops to get at the class members via the built in menus. 

Editing class properties is a pain, especially in a med-large project when opening the properties dialog can take half a minute or more. A class is perfectly encapsulated, so it seems like a perfect candidate for a context aware menu. 

That's why it got my vote at least...

[Intaris]

Oh, I agree it would be cool if it's automatic but the idea states that this functionality is NOT POSSIBLE in LV, which is clearly a false statement.

Reword it for automatic context menus and I'll vote for it.

[Intaris]

Soooo are people voting for this feature to become automatic (because to me it's totally not clear that the original post is asking for this specifically) or are people unaware of the current implementation?

I personally would also LOVE to see the class menu being automatically generated as I feel having to manually create a palette for each and every class a PITA but I'm not really willing to vote here because I don't see that as being the original request...  Can someone enlighten me?

[drjdpowell]

I voted for automatic generation of the menu.  I would sugest the feature should work for any library, not just classes, and should filter out out-of-scope VIs (so if you clicked on a subVI in a VI outside the library, it would not show private members of the library).  It would be nice if the generated menu also allowed access to methods of parent classes.  And the same menu should be part of the "Insert" menu when one clicks on a wire of that class.

-- James

[drjdpowell]

Oh, and using the automatic generation should be an option of the "default menu" selector in the Library properties, so one can always override the menu with one generated (painfully) by yourself.

[Intaris]

drjpowell

This I would certainly vote for but am I the only one who sees the difference between what you just posted and what the original text asks for?

[drjdpowell]

The OP is unaware of the way of manually generating a menu for a class, true.  However, the tone of the idea is very much an automatic menu that "search(es) through all of the VIs that are accessible to the class".  The current manual method is hobbled by poor useability, and it is possible that an overhaul of menu creation could make this idea less needed.