From 11:00 PM CDT Friday, May 10 – 02:30 PM CDT Saturday, May 11 (04:00 AM UTC – 07:30 PM UTC), ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Quick Drop Enthusiasts

cancel
Showing results for 
Search instead for 
Did you mean: 

Proposed Quick Drop Behavior Changes in LabVIEW 2013 (prototype included)

Darren wrote:

I'm just moving the scrollbar so the selected item is at the top

---

Any way to scroll down until the selected item is in view?  If the item is highlighted then I don't see the advantage of putting it at the top of the list over seeing items at the very top of the list and being able to scroll in only one direction.


Certified LabVIEW Architect
TestScript: Free Python/LabVIEW Connector

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
0 Kudos
Message 11 of 19
(868 Views)

LabBEAN wrote:

Any way to scroll down until the selected item is in view?  If the item is highlighted then I don't see the advantage of putting it at the top of the list over seeing items at the very top of the list and being able to scroll in only one direction.

I don't understand your point. Remember, this prototype does nothing with changing sort order. When you type something in the text box, the stuff you see in the list is exactly same, in the same order, as it always has been. But now that the text box is a filter (instead of an autocompleted exact representation of the object you're dropping), the list always has something selected. By default, it's going to be the first item (since usually, you'll type a filter to the point that it returns the most relevant item at the top of the list). The only time it won't be the first item is when the text is an exact match to something in the list, but that list item isn't the first thing in the list (like the 'add' example I mention above). In that case, I'll select the exact match in the list, and scroll so that you see it at the top of the list.  Again, this shouldn't be happening very often at all. But when it does, I think the current behavior is the most intuitive.

Let me know if you have a specific example (using the prototype, if possible) of changing the way the selection occurs to be more intuitive.

0 Kudos
Message 12 of 19
(868 Views)

Darren wrote:

I don't understand your point.

---

No need to scroll if the highlighted, exactly matched item is already visible.  I see scrolling being typically detrimental in that case.  Idea » Only scroll if the highlighted, exactly matched item is not visible in the list and then only scroll until it becomes visible.


Certified LabVIEW Architect
TestScript: Free Python/LabVIEW Connector

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
0 Kudos
Message 13 of 19
(868 Views)

Darren wrote:

Unfortunately, messing with the list sort order isn't quite the low-hanging fruit that the other stuff was.

Would you like me to send you my code? It works quite well and placing it in QD is very cheap (assuming of course that NI would be willing to give up the DLL call).

Darren wrote:

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.

Natural search results should work not only when you have an exact match, but as much of the time and as magically as possible. I really like it when I type something and the first (or second, or third) results happens to be what I want even if I didn't bother to type in the full correct name and I don't have to think about how to do it.


___________________
Try to take over the world!
0 Kudos
Message 14 of 19
(868 Views)

I'm having a little trouble with the drop-something-if-nothing behavior. If I'm typing very fast, there is just as good a chance that I will accidentally type two more characters than just one in which case the last item selected has a good chance of not being what I wanted. Would it be possible to "eat" the enter button when nothing matches the filter so when I hit enter I'm still in the dialog and can back up some number of characters to get back to my selection and THEN hit enter? I certainly don't like the dialog that was there before, so just forcing me to fix the filter instead of responding to enter would be nice.

0 Kudos
Message 15 of 19
(868 Views)

I just posted another update. I went ahead and implemented the request where objects whose names start with the search string will be filtered to the top of the list, regardless of their type (shortcut, palette object or project item). Let me know what y'all think of this change. At this point, I think I've got all the requested functionality in this thread and on the Idea Exchange post, except for the "popular items bubble up" stuff.

0 Kudos
Message 16 of 19
(868 Views)

Thanks so much to everybody who gave me feedback on these proposed changes. When it's available in a few months, please sign up for the LabVIEW 2013 beta to try out my implementation and let me know what you think (on the beta forums).

0 Kudos
Message 17 of 19
(868 Views)

Been using this a month now -- it's been working like a champ. Thank you, Darren 🙂

Message 18 of 19
(868 Views)

Words fail to express how awesome this prototype is. You're my hero of the week!

____
Ryan R.
R&D
Message 19 of 19
(868 Views)