Quick Drop Keyboard Shortcut - Nattify VI

[jashcroft]

Not directly related to this thread but I recently found some strange behaviour with the JKI SM quick drop shortcut (see here)

DNat I noticed that you used a llb for you're supporting files. How does LabVIEW search for executable quick drop actions? Having the JKI llb in the quick drops plugin folder seemed to really slows down any button presses when ctrl is also press (namely ctrl + Backspace which I don't have assign to a QD shortcut but use to delete whole words as per windows). Is this just me or is this a JKI thing, LLB thing or LabVIEW thing?

(running LV2023 Q3)

[Darren]

---

@jashcroft wrote:

Is this just me or is this a JKI thing, LLB thing or LabVIEW thing?

---

It's a bug in Quick Drop. It has been reported to LabVIEW R&D as Bug 2089884, but hasn't yet been prioritized by R&D to get fixed. For now, I have attached a VI to this reply. Replace your copy of this VI with the one attached (VI is saved in LabVIEW 2020, backup your existing VI first just in case):

[LabVIEW 20xx]\resource\dialog\QuickDrop\QuickDrop Read QDKS INI Info.vi

Mass compile the QuickDrop folder above and you should find the Ctrl-key presses to be more responsive. Let me know how it goes.

[jashcroft]

This is incredible. For the last 3 year's I've been dealing with this issue. Thank you for the help 😄

You don't by any chance have a magic VI which fixes the populating list? I've seen your post on the idea exchange 

[Darren]

---

@jashcroft wrote:

You don't by any chance have a magic VI which fixes the populating list? I've seen your post on the idea exchange 

---

Unfortunately no, the palette loading is performed by C++ code in LabVIEW.exe, I don't have any magic VIs to fix that. 😛

I will say that if you select Tools > Options > Controls/Functions Palettes > Loading > Load palettes during launch, Quick Drop will be instantly usable on first use, at the expense of LabVIEW itself taking longer to launch.

[Taggart]

Anyone else occassionally seeing issues with the FP like this. Seems to be sporadic and always seems to involve a class terminal.

[felipefoz]

---

@Taggart  escreveu:

Anyone else occassionally seeing issues with the FP like this. Seems to be sporadic and always seems to involve a class terminal.

---

There is an issue with this Arrange VI Windows. It seems to be sharing some code between the iterations and it causes this issue. I solved by calling by reference in my formatter.

---

https://gitlab.com/felipe_public/lv-dev-hooks

I posted in the Arrange VI Windows post, but it seems there was not important enough to trigger any further action.

https://forums.ni.com/t5/Quick-Drop-Enthusiasts/Quick-Drop-Keyboard-Shortcut-Arrange-VI-Window/m-p/4...

[Taggart]

Thank you. I will check it out.

[Taggart]

That appears to fix it. Can't be 100% sure since it was a race condition. I'll post back here if it pops up again, but for now it appears to have gone away.

[felipefoz]

---

@Taggart  escreveu:

That appears to fix it. Can't be 100% sure since it was a race condition. I'll post back here if it pops up again, but for now it appears to have gone away.

---

Good to hear. It is a workaround, but for now seems effective.

[Darren]

I found a couple of feedback nodes in the code that I think could explain errant state being kept between one run of the code and the next (which should only happen in situations where you are programmatically calling Nattify... it should never happen when using it interactively on one VI at a time). Anyway, I have replaced those feedback nodes with initialized shift registers, which I think fixes the problem. I've updated the original post with the fix. For reference (if anybody has copies of the code they want to manually fix themselves), make the following changes to these plugin subVIs:

Nattify - Arrange FP Controls Columns.vi

Nattify - Arrange FP Controls Rows.vi