How many need Delete Option on Context Menu?

[Naveen2411]

For LabVIEW users,

How many of them need "Delete Option" on Right Click Context Menu?

I feel providing an delete option in right clicking context menu for any Indicator or Control deleting will make developers easy and fast assessable and avoid too-much use of keyboard.

We use our left hand for control and Shift more offen but for pressing delete button which is at right top corner in keyboard, all of a sudden we will remove our right hand from mouse and press Del which is uncomfortable.

So, Developers share your point of view for the same and request to add Delete Option in upcoming version.

Later we will ask even Cut Copy Past... He! He! He!

[RavensFan]

---

@Darin.K wrote:

> I don't want things like delete on there because it just clutters up the menu for the things that deserve to be there.

One more submenu really pushes the clutter over the edge?  What are you guys continually reaching for down there, View as Icon?

I noticed the lack of RCM functionality (moreso copy/paste than delete) when trying to use my graphics tablet, you know, LV being graphical and all.  Transitions to the keyboard are just disastrous, much worse than even awkward context menus.

If clutter is the issue, the solution is prioritizing and nesting menu items, not eliminating items.  Do one-time options like View as Icon, Description and Tip, and Representation really need top-level real estate?  I wouldn't think so.  Other programs pack a lot into the menus, and the well-designed ones give you complete functionality along with the convenience of putting the truly common functions in easy reach.  So much wasted motion in many of these menus.

---

Except it is never just "one more item" or "one more submenu".    Already here in this thread,  it went from "Delete", to oh we need Cut, Paste, Copy as well because they are all realted. (With some debate as to whether Paste even made sense in a context menu).  So one item became 4.

And no one is suggesting eliminating an item.  I'm just arguing against adding an item.  The objective of Naveen's idea was to debate whether "Delete" should be a context menu item.

I think View as Icon is worth the real estate.  I use it a lot when looking at the VI's posted on line (because I don't like the icon view.)  Description and Tip, I could do without.  If I need them, I get them through the properties dialog.  Reresentation, I feel is worthy of the top level.

As for sub-menus, I'm not a big fan of those.  Having 1 level of submenu's is okay when it groups things that belong together, and any given item in it isn't among one of the top 10 used menu items.  I dislike it when submenus get nested.  Often by the time I drill down through submenus,  (think of the property node and invoke node menus)  I will have fallen off the string of menus causing them all to disappear, or run out of screen space having things jump back to the left to start following, before I get to where I want to go.  (As annoying as the property node menus are because of the numerous submenus,  there are a lot of them and they have a hierarchy,  I don't think you can do much else with them unless you change the interface.  Possibly have it jump to a dialog box with a tree type of interface.)

[Darin.K]

As I have said twice already, a single submenu is totally acceptable, so 4 items or 3 items can go back to 1.  As for paste, give me BD paste-replace.

[M_Peeker]

I must say I've never thought about this until now. But what has been seen can't be unseen.

I would suggest that we have an "edit" RCO, with sub-RCO that allows you to do everything you can do from the menu '"edit" on the chosen object. Also, make evrything available in both these locations, so that you e.g. can copy/paste data from the menu selection as well. All "Data Operations" would be moved to the "edit" RCO.

Another option is to remove all selection specific alternatives from the menu "edit" (today therse is a mix of general and specific scope) and let us use a RCO "edit" for everything selection specific. As I think about it, this may be even better and more intuitive as the scope of the menus don't change depending on selection.