Within list search problem

D-Opus has a feature for searching filenames within a list. Once a string is found and that file highlighted, another instance of that string can be found by pressing the Tab key.

The problem is, that as the string is typed in, the cursor bar moves progressively down the list to new finds as each key is pressed. This is a problem because as each key is pressed the search does not start anew at the top of the list, causing matches higher the list to be bypassed.

For example, with my list sorted by date (newest at top) and searching for KRBD, "KR" takes me to a Kramer file dated September 6, and then typing "BD" takes me to a file dated September 4. However, the file KRBD file I was looking for was dated October 1 and had been bypassed.

Although Shift-Tab would take me up the list to that file, doing this is not intuitive. The need to search in both directions (down, then up) is cumbersome and unintuitive and very likely to cause search results to be missed. I think the search logic of this feature should be improved by making the search start anew from the top of the list each time a key is pressed. Is GP Software willing to make this change?

Do you mean if you type KR and then wait long enough or push Esc to stop the search, then enter BD as a second search, instead of entering KRDB all at once?

If you do two searches and don't want to resume from the current position, you can push Home before the second search.

Alternatively, using the filter mode instead of the search mode may work better for you, as that will remove non-matching files entirely so you can focus on just the matching ones.

Thanks for your reply, Leo.

I can't type fast enough to get, as an example, the KRBD search all at once. I'm only doing one search, not two.

Also I'm not using the Esc or Home keys. Home just takes me to the top of the list, from which point the same problem I described still exists.

Not sure what you mean by "second search" since I am doing only one search.

Filter mode may work, but the method I have been trying to use for this purpose is quicker and easier if it can be improved to give a reliable result. As it is, it is not reliable because instances high on the list can be bypassed and the user has no way of knowing that what should be a result has been missed. I think this is fault and that the feature should be improved in a future release. Can you relay this to the development team.

What is Preferences / File Displays / Find-As-You-Type: Close timeout set to? Try increasing it so you have longer to type.