10-03-2012 05:23 PM
Based on user feedback, I am proposing the following behavior changes for the Quick Drop window in LabVIEW 2013:
Please try the attached prototype, which includes these changes, and let me know what you think of them. To try the prototype, back up your copy of [LabVIEW 2012]\resource\dialog\QuickDrop\QuickDrop Launch Window.vi, and copy the VIs attached below to the same folder. The prototype is currently only available for LabVIEW 2012. To "uninstall" the prototype, remove these VIs, then replace the main VI with your backed up copy.
Unless I'm missing something, these changes should not have any adverse effects on the workflow of current Quick Drop users (*please* let me know if there's something I'm not thinking of). I will be using the prototype extensively over the next few weeks to see how I like it. If you are interested in seeing these changes get into LabVIEW 2013, I ask that you do all your LabVIEW 2012 development with the prototype as well, and let me know if you encounter any problems.
10-03-2012 06:26 PM
First thoughts:
I wholeheartedly support these changes, thank you for your efforts Darren!
10-03-2012 07:30 PM
Thanks for the quick reply, Thoric. I agree that it was a little awkward to have nothing showing in the list, but still get a valid drop object. So I updated the prototype so that, if the filter text doesn't yield any valid results, then the last valid selected item will be shown in the list, but in gray text. I hesitate to use italics because of issues I've had with italics on non-English LabVIEWs. Let me know what you think of the latest version.
10-04-2012 03:48 AM
10-04-2012 04:00 AM
I'm sure I don't have to repeat how I think that this behavior is much better.
One thing I don't like about this prototype is the sorting of the results. It seems that the logic is to place items with shortcuts at the top of the list and then there's a secondary sort which is sort-of alphabetical but not quite. In my experience, a much more natural sort is to give a lot of weight to a match found in the beginning of a word, particularly if the match is at the beginning of the string (e.g. if I type "ind" then "Index Array" should be the first result, not "Quotient & Remainder", which happens to have a shortcut that's earlier in the alphabet. The same applies to "nd", which gives me "bbn (Bundle By Name)" as the first result, when the first result should be "ndx").
I also use the frequency-of-use data as a factor in the sorting, but I think that the previous mechanism is responsible for most of the natual feel of the sort order.
10-04-2012 04:23 AM
If the ordering can be tweaked, then I'd also like to the see results that come from my Project tree at the top - especially if frequently used. I often drop type-def constants or subVIs from my Project onto my block diagrams with QD, but unless I type a lot of the filename to shorten the results list the items are always off the bottom of the visible window. For example, "check_digital_input_channel.vi" might be best found by typing the initial characters of each word, such "ch dig in", but there are 15 results including some very obscure ones such as "IviDigitizer Fetch Multi Record Waveform Int8 [MRA].vi". It would be great if my stuff was shown before the poorer matching stuff.
10-04-2012 12:23 PM
tst and Thoric,
Unfortunately, messing with the list sort order isn't quite the low-hanging fruit that the other stuff was. Here's how the list is currently sorted:
For the palette objects, they are currently sorted (by default) with the NI-SEARCH algorithm, which is relevancy based, and isn't necessarily alphabetical. In case you didn't know, there's an INI token you can use (QuickDropFastSearch=True) that turns off the NI-SEARCH functionality, and replaces it with a simple string search algorithm. I added this INI token because I didn't like the slight delay that occurs when performing the NI-SEARCH query, which is out of my hands. A simple string search provides results much faster (resulting in much better responsiveness in the UI), so I use QuickDropFastSearch, but I doubt many other people do.
With QuickDropFastSearch, I could potentially mess with the order of the 3 categories with minimal effort. But the default setting (which I imagine 99.9% of Quick Drop users have) is to use NI-SEARCH, which magically returns search results to me from the NI-SEARCH DLL...it would be considerably more work (and would take up precious milliseconds) to try to mess with the order once I've gotten the NI-SEARCH results back.
As it stands, I've got code in the prototype that will highlight a non-zero item in the results list if the text that is typed is an *exact* match for something in the list. For example, if you type 'add', and you have a shortcut for "Add Array Elements", then the "Add" palette entry will be selected in the list, even though there's a shortcut above it. I'm about to upload an update to the prototype that actually scrolls the list so that, in this situation, the selected item is at the top of the list in terms of what you first see.
All this to say, I don't actually have time budgeted to work on any of this. Is the prototype in its current state a good enough improvement that y'all still want to see it in 2013, or is it not worth the change in behavior if I leave the sorting mechanism unchanged?
10-04-2012 12:30 PM
Darren wrote:
I'm about to upload an update to the prototype that actually scrolls the list so that, in this situation, the selected item is at the top of the list in terms of what you first see.
---
You're going to "scroll" the items that would be above "Add" in your example to the bottom of the list (instead of hiding them), correct?
10-04-2012 12:33 PM
LabBEAN wrote:
You're going to "scroll" the items that would be above "Add" in your example to the bottom of the list (instead of hiding them), correct?
No, I'm leaving the list order unchanged, I'm just moving the scrollbar so the selected item is at the top...if you up-arrow (or shift-tab) from here, you'll still get to the (actual) top of the list that has the shortcut:
10-04-2012 01:01 PM