Proposal: Ship QD Object Shortcuts in LabVIEW 2016

[Hooovahh]

You make some good points.  But again I'd say the reason for poor adoption could be attributed to the fact that there aren't any shortcuts installed.  It does take a decent amount of time to come up with shortcuts that are easy to remember, then add them.  Having the common ones Darren made is a good starting point.  And if we are going to make suggestions for new ones where should we mention them?  In the linked thread?

I don't think QD is going away because of right clicking.  In my mind one reason QD came about was because t is faster than a right click in most cases.  But with right click you can get contextual feedback which can make some operations faster.  So today we have QD, right click, and the Tools menu, for launching a VI in the IDE to perform some operation.  I suspect that in the future we will still have these three options because not one option covers all the uses of the others.

As for your comment about OpenG and MGI, I couldn't agree more.  OpenG has been around since at least 5.x and has so many useful tools.  Some of which NI has copied implemented over the years but usually not as well in my opinion.  Having OpenG be part of LabVIEW would certainly be more beneficial in development then QD shortcuts, but that might be a different discussion.

[jcarmody]

1. I do agree.
2. I've got nothing to change.

I'd like to remind the community of this in the Idea Exchange - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/quick-drop-shortcut-context-help/idi-p/2531518

[Patur]

1. YES !!!
2. No.

[comrade]

1. Great idea, go for it. Despite the well-phrased opposing words by bsvare, which are mostly true.

2. A couple of thoughts here.

• Actively inform the user about what happens during the installation with respect to QD usage. That way awareness of the feature might be raised to those who don't know about it.
• Ask whether any old shortcuts should stay (not for each one but one time for all existing shortcuts) instead of installing the shipped ones. That way some people might be tempted to switch to the shipped ones and stay with them which means more cross-machine compatibility in using QD over time. Excessive QD-users like me are likely to stop working on a machine at once when QD is not working as expected... This might include helping novices in the company...
• standardizing the shortcuts is, IMHO, a good thing, even if it means I have to change my learned-by-heart ones
• localization issues might occur, as I pointed out here,
  https://decibel.ni.com/content/docs/DOC-39335#comment-38144
  because easily memorizable shortcuts are usually created by the name of the function/VI/structure/node to place. And "sel" for "Select" is probably natural for English localization, but it would hardly come to mind for the German "Auswählen", unless you frequently use both localizations.

============

*Set Flaming TRUE*

As for adopting OpenG code - we all know what the answer from NI will be: Declined code support. There is a whole bunch of undocumented functionalities which Darren and others repeatedly point towards, while never omitting that (kind-of-) killer aspect of those not being officially supported and therefore not documented, as they might change or cease to exist/work properly in future releases...

*Set Flaming FALSE*

[X.]

Sounds good.

BTW, Check the "New" menu above and scroll down to "Poll". That may have been an appropriate tool for this kind of question.

Not sure what the QD shortcut for this one is, though...