Eliminate Quick Drop's Initial Launch Delay

[Darren]

As much as I love Quick Drop, I don't love this:

This delay occurs because we have to load all the palette information in the background to be able to drop objects by name.  You can choose Tools > Options > Controls/Functions Palettes > Load palettes during launch to front-load this delay during LabVIEW launch, but (1) a lot of you don't really like the longer launch time much better and (2) a lot of users still don't know about this setting.

I'm sure there's a way to solve this problem and make Quick Drop instantly usable, but I don't know enough about the underlying palette code to get it done.  Solving this problem, by the way, could have positive side effects on LabVIEW launch time, palette search performance, and maybe some other areas as well.

[MGiacomet]

And it's even slower when the Error List dialog box is visible...

Ideas, ideas, lots of ideas posted here and... NOTHING from NI to fix this problem (with exception of "explanations", a.k.a., excuses)

[AristosQueue (NI)]

> NOTHING from NI to fix this problem

It is a minor issue with no obvious good solution. All proposed solutions have tradeoffs, and none of them seem particularly better than the current behavior. Eliminating the tradeoffs would require a completely revised menu scheme. We do not judge it so bad as to warrant the time/effort allocation of multiple developers for a release. LabVIEW NXG is being built to address that kind of systemic change, where, indeed, a whole different menuing system allows much faster response.

[MGiacomet]

Oh... the NXG excuse. I keep forgetting that NI funnels support monies that we pay to fund new "features"... Sounds like LV non-NXG is dying.

>>"...completely revised menu scheme"

Who's taking about revising menus? All we are asking is to stop rebuilding the list every time the Quick Drop dialog gets launched.

A very simple solution is to, once built, keep the list in memory and don't rebuild unless the user commands so. A button on the dialog to refresh the list is all that's needed. The list is lost when the dialog closes? Don't close it! As simple as that!

In the amount of time spent so far trying to "explain" why it "can't" or "won't" be fixed, one could have it done.

[crossrulz]

>>"All we are asking is to stop rebuilding the list every time the Quick Drop dialog gets launched."

This is not a problem for me.  The only time I run into any loading issue is when I hit the QD before all of the palettes are loaded, which is the issue this idea is talking about.  Once that initial load is complete, QD is there immediately for me.

>"Sounds like LV non-NXG is dying"

I don't think NI has been shy about saying that.  NXG is a complete rewrite of the IDE so that a bunch of these types of ideas could actually be implemented instead of being kludged on, creating even more issues.  Once NXG meets feature parity with "classic" LabVIEW, you will see the countdown begin.

[AristosQueue (NI)]

LabVIEW NXG is a complete rewrite because there are limits in the existing codebase that cannot be repaired without major rewrites of the code. You want this bug fixed. It requires a rewrite of the menu system. That rewrite is included in LabVIEW NXG. Saying it is in LV NXG is no different from saying, "This bug will be fixed in LabVIEW 20XX" because, at some point, LabVIEW NXG will become LabVIEW 20XX. The existing LabVIEW is not dying, has not even entered "maintenance mode." You will continue to see both bug fixes and new features in the current platform for years to come. But there are areas that we are emphasizing more than other areas.

[wiebe@CARYA]

The biggest problem with the delay for me is that shortcuts are not handled by QD.

I press CTRL+SPACE, then CTRL+R to remove something. Boom, the VI starts running.

I press CTRL+SPACE, then CTRL+T to align my labels. Boom, full screen PF and BD... CTRL+Z, CTRL+SPACE, CTRL+T.

Note that this seem to happen once per VI, so it's not just once globally.

When I'm searching a VI, I can wait. But these key combinations should be executed by the QD dialog, as soon as possible. Even if it's loading, searching or whatever.

It's on the very short list of annoying QD things. Another one is that it updates it's list (delay) when you move the cursor (why?) but not on a paste (why not?).

[10Things_Rob]

I just started using LV2023.

It's time to re-open this Idea.

Except in 2023 the delay is WORSE since now it's EVERY time you open QuickDrop, not just the FIRST time you open it

[wiebe@CARYA]

>Except in 2023 the delay is WORSE since now it's EVERY time you open QuickDrop, not just the FIRST time you open it

IIRC, that does depend on this setting. You could have turned that setting off in older versions (to speed things up). while it's default on in a new version? 

EDIT: apparently it is slower, but this option might prevent being slow every time...

I'm not sure if populating the list can be faster (assuming they made an effort to make it fast 🙄). But while populating, the QD should respond to shortcuts (CTRL+T, CRTL+R, CTRL+K, etc.), and execute the shortcut and either abort populating the list or continue populating the list in the background.

[Darren]

The slow Quick Drop launch time in LabVIEW 2023 Q3 was a bug (reported to R&D as Bug 2468882) that was fixed in LabVIEW 2023 Q3 Patch 1.