Ability to leave QD open if wanted after dropping node/VI to BD

[GregFreeman]

A coworker asked me about this today, and I wasn't sure if there is a way to do this already. Is it possible to open quickdrop so after you select a node and click the BD to drop it that QD remains open? If not, would this be functionality that people may find useful? I personally don't mind pressing ctrl+space every time, but that's probably just because it's become habit. I could see how this constant opening and closing could be seen as tedious, especially if you know of 4 or 5 different VIs you will need to drop and wire up.

[Thoric]

I would especially like this feature because there is one minor flaw in Quick Drop that gets me every time:

• I press CTRL+Space
• I start typing my shortcut
• I press Enter
• I get the wrong thing - because the first few characters that I typed weren't recognised because Quick Drop hadn't launched quickly enough (ie, it missed the first two characters of "dds" (diagram disable structure) and registered only the "s" which gives me a Search 1D array function).

Having to pause before being able to type my shortcut characters is a minor, but frequent niggle. It gets quite tedious having to use QD twice, once to get an error, a second time (after a bit of swearing) with caution wating for the panel to appear before typing my shortcut.

The delay is probably much less than a second, and is quite possibly the fault of Windows, but one can quite easily type their entire shortcut within that time.

Soooo, if the QD panel was always open, then after pressing CTRL+Space to make it the focus window, it will be ready instantly! This will save me much frustration

[GregFreeman]

Or, maybe ctrl+shift+space opens and leaves it open like context help. Then, if open, ctrl+space will bring it into focus. But, if not open Ctrl+space opens then QD will function as it does currently. This gives the user some flexibility.

[GregFreeman]

Just noticed we do have some limited control over this for custom plugins. There is a boolean in the template which allows QD to remain open or closed after executing a shortcut. But, obviously this doesn't totally alleviate the problem thoric is having.

[crossrulz]

Just so people know, here is a similar idea on the LV Idea Exchange.

[Darren]

> Is it possible to open quickdrop so after you select a node and click the BD to drop it that QD remains open?

I tried prototyping this a while back, because I thought it would be a cool option for dropping lots of items in a row.  Unfortunately, I had some trouble getting the window activation of the Quick Drop window after the object drop to work just right...so I abandoned the effort, as nobody other than me (until now) asked for this functionality.  Maybe I'll give it another shot sometime soon, now that I know I'm not the only one.

> Having to pause before being able to type my shortcut characters is a minor, but frequent niggle.

Argh!  I've been wondering for a while if anybody has been experiencing delays upon Quick Drop load that result in lost keystrokes.  Assuming all the palette stuff is already loaded, and you don't have a huge project open that I have to parse, it *should* be instantly usable without a delay.  Have you tried using the 'QuickDropFastSearch=True' INI token?  The purpose of that INI token is to have the QD text box be slightly more responsive as you type (at the expense of getting relevancy-based search results)...but with this INI token, there is one less subVI that executes when QD initializes, which might make a difference for your speedy typing.

[GregFreeman]

Darren wrote:

" Maybe I'll give it another shot sometime soon, now that I know I'm not the only one. "

Let me guess, LV 2013?

[Darren]

> Let me guess, LV 2013?

At least.  It's too late in the 2012 game for me to try to get new features in.

> Having to pause before being able to type my shortcut characters is a minor, but frequent niggle.

I just discovered a bug in Quick Drop that may also be contributing to this behavior.  Try this...after you launch Quick Drop for the first time after starting LabVIEW, move the window a little bit before closing it.  I have some faulty logic in my initialization code that is causing the first launch QD code to run every single time if the QD window position stays the same as the value stored in the INI file from your last LabVIEW session.  If you move the window just a little, then a flag gets set properly and all that first run initialization code doesn't have to run every time anymore.  Let me know if this helps as well.  I filed CAR 356581 to get this fixed in 2013.

[Thoric]

Darren wrote:

I just discovered a bug in Quick Drop that may also be contributing to this behavior.  Try this...after you launch Quick Drop for the first time after starting LabVIEW, move the window a little bit before closing it.  I have some faulty logic in my initialization code that is causing the first launch QD code to run every single time if the QD window position stays the same as the value stored in the INI file from your last LabVIEW session.  If you move the window just a little, then a flag gets set properly and all that first run initialization code doesn't have to run every time anymore.  Let me know if this helps as well.  I filed CAR 356581 to get this fixed in 2013.

I thought I'd try the two ideas you've stated today, both the ini token and also moving the window, but ironically my QD window is opening up virtually instantaneously (before applying either of the ideas) and catching my typed characters perfectly.

[Darren]

Thoric wrote:

I thought I'd try the two ideas you've stated today, both the ini token and also moving the window, but ironically my QD window is opening up virtually instantaneously (before applying either of the ideas) and catching my typed characters perfectly.

I've noticed occasional mysterious LabVIEW editor slowdowns over the years that I can never track down consistently enough to CAR.  This has manifested itself in Quick Drop, where the QD window takes way longer than usual to open after pressing Ctrl-Space.  When I find that I'm in that state, a LabVIEW restart always speeds things up again.