Darren's Weekly Nugget 04/27/2009

[InternationAL]

Am I correct in assuming that "DI_DI Search For Matches.vi" is the VI I am supposed to look at?  It also appears almost ready for use as a subVI, no?  I would just wire in previously selected indices, the array of names, and the query, and out pops the filtered list?  I guess I'll have to figure out what the "Preferences" input and the "Function IDs" output are, but that shouldn't be too hard.  A quick look makes me think that "Preferences" allows the user control over the display of the results and "Function IDs"... well... let me look some more.

Thanks tst (Yair)!

[tst]

Here's the search VI as 6.1, with the function preferences and IDs inputs removed. The loops on the left still have some references to it, which can be deleted.

As for the function IDs and preferences - I did this when I saw an initial prototype for Quick Drop, but I had to keep a list of the functions to drop somewhere. That's the function IDs which are simply indices in the array of strings (I couldn't just use the i terminal because I also had aliases, or shortcuts as they're called in QD). 

One of the things I figured would be cool was if the tool remembered your previous selections and gave each match a higher score the more times you use it. That's the preferences input.

I couldn't attach the entire thing, because 6.1 did not support filter events, which are crucial to how this works. You will need to find some workaround to make it work without them.

[Darren]

---

InternationAL wrote:

Don't you have to turn on the "Update value while typing" for the combo box, or else the filtering of the listbox won't occur with the value currently displayed?  But, if you turn that on, the autocomplete turns off.  How do you get both autocomplete and "Update value while typing" to be on at the same time?  On my end, I seem to be able to get only one or the other.

Plus, what's the search function being used?  I like how in Quick Drop, you can search for two different string chunks, like "rect" and "pola", if you type in "rect pola", and you'll find, for example, the "Rectangular to Polar" and "Polar to Rectangular" functions.  I am currently using the "Match Pattern" LabVIEW primitive.  Should I be using a different one, or is the Quick Drop search a little more complicated than can be implemented with a single LabVIEW function?

---

To get what is currently typed in the text box in order to match object names, I use the Text.Text property of the combo box.  This property returns the visible text in the combo box, not the combo box's value.  By using Text.Text, along with the Selection.Start and Selection.End properties, I can tell what the user has actually typed in the combo box.  Here's a screenshot of the code from Quick Drop that does this:

 

As you can see, I take whatever you've typed, break it into separate space-delimited strings, and send them into a queue for processing.  Here's the parallel loop that consumes those queue values and does the actual search:

 

I use the Match Pattern function to see if each string that was typed in the text box matches every object name that I have (including Quick Drop shortcuts).  Any matches that are found are built into an array and sent into a User Event, which is used to populate the listbox once the matching algorithm is complete.

Message Edited by Darren on 04-28-2009 10:55 AM

[InternationAL]

Darren: 

The middle two tunnels in the consumer loop:  my assumption is that the top tunnel passes in an unadulterated list of all available controls/functions.  The bottom tunnel passes in a list of the same thing, only with the case converted to all lower, to facilitate a case-insensitive search.  That's why it's combined with a lowercased version of the Shortcuts.  Am I close?

If I could also make a minor request.  Could you turn on junction dots briefly before making any screenshots?  I know you hate them, but double clicking on the PNGs to trace the wires doesn't seem to work.   Then you can turn the junction dots right off.  For a minute there, I thought the local variable "Shortcuts" was being wired into everywhere!  It's easy enough to figure out with a little logic, but would be a little clearer with the dots.  No biggie if you don't want to bother.

Thanks very much for all of the great info!  This is turning into a great nugget!  Thanks to Darren and all who posted.

Message Edited by InternationAL on 04-28-2009 12:56 PM

Message Edited by InternationAL on 04-28-2009 12:57 PM

[Darren]

I find that the dots at wire junctions actually hinder my ability to tell wire crossings vs. junctions because they take up extra space, which can be detrimental in areas of high wire concentration (and thicker wires).  I find the difference in appearance between vertical wires and horizontal wires, along with the 1 pixel of whitespace surrounding an overlapping wire, to be more than enough of a differentiator for discerning wire crossings vs. junctions.

And yes, you are right about the comparison of lowercase strings.  We want to make the Match Pattern easier by using lowercase strings, but we want to use the actual strings with correct casing for display in the listbox.