Filter and sort text search results

[gmart]

When searching for text, the results are returned as a comma delimited string. If you are interested in finding a result based on location or type, you have to eyeball the results to find what you want. Since the data is already delimted, each piece should be placed in its own column which can then be sorted. Also, the ability to filter the results based on an expresssion would further help narrow down the results.

[tst]

Yes, please! 20 Kudos.

Also, the "Item #" column could do without a header or with just "#". The word "Item" takes up valuable width. And of course, the columns should have the width applied automatically based on their content.

[JackDunaway]

Perhaps, the results could be grouped in a hierarchical tree? The grouping could be selectable on either containing VI, or type. Kudos.

[gmart]

I'm not a big fan of hierarchical results. I find it easier to navigate a flat list where all my information is present rather than drilling down groupings. I definitely can see the benefit of a tree so it's a personal preference on my part.

[TurboPhil]

Yes. Yes. A thousand times yes. This is one my biggest pet peeves with LabVIEW, and one of the areas that wastes the majority of my time.

[gmart]

Ideas with the most kudos have a good change of being implemented. So tell all your friends about this idea and maybe it will make it in 🙂

[Davidson_D]

This "Filter and sorting" is very useful for me to refine my searching without going for find again.

Hoping to see this feature in LabVIEW.

It would be good to have "Finding objects based on the text entered"

Filtering will also help..

Thanks,

Davidson

[X.]

To begin with, the "More Options..." button of the Search Panel should be complemented with an "Even More Options..." one:

 

Here I thought I was going to get string constants only, but nope:

I get description strings, case strings, etc... It certainly would be nice to filter results after the fact, but much better to be able to filter beforehand.

[gmart]

What additional options in the "Text Search Options" dialog would you like to see?

[X.]

Well, since you are asking...

On the Options side:

- the existing (selected or unselected) options should result in what they are supposed to do: for instance in the above example,

      * even though I unselected "Visible Labels", I got four hits in the search result (items 5,7, 23 & 26)... [these are free labels, but labels nonetheless]

      * I selected "Block Diagram" only and I got items  1,2 & 8, which are refering to the VI History...

      etc...

- I can hardly go through all possible kinds of objects that contain strings, but ideally, each time NI adds a new one that contains strings, I would like to see it added as an option (how easy is that for an answer?). But a few come to mind:

      * Property Node property name (long/short)

      * Bundle/Unbundle (long/short)

      * Type of string constant display (to look for string-formatting strings, for instance)

As for "after the fact" filters, I would suggest giving access back to the first options selection window (as in "Modify Search"). My point is that if I discover that the search results is a list of many dozens of hits I don't want to click through to avoid having my screen cluttered with useless VIs, I'd rather perform a new search.

If you want to be sophisticated and give something challenging to grind to new programmers, maybe offer a preview a la Google... (Hover over the item and it provides a local preview of the string in its VI environment).

I am sure others may want to chip in. Without asking for an unnecessarily complicated tool (for both NI developers and users), the question is what is the usefulness of a list of say, above 10-20 items. To me, none, since I am typically searching for ONE string occurence (las in "where the heck did I force the ASCII output to be a 3 digit precision float?").

My 2 cts.

[X.]

BTW, I'd be curious to know what these forbidden items are. For instance, if double-click item 9, I am brought to an empty part of the diagram after a brief flash of a rectangle that then disappears... Very enlightning.