Is it possible to make Find-you-type in Opus search for words within filenames, rather than just the beginning of the file?
For instance, I have all my music named as "artist - song name" and separated into folders by album. If I know the name of a song, but don't remember what album it is in, my first instinct is to put my whole music folder in flat view, and type the song name to find it using FAYT, but this doesn't work because FAYT only searches the beginnings of filenames.
Is it possible to make FAYT search words within a filename, or even just straight string matching within filenames (closer to the way the actual find dialog works)?
That at least allows me to do what I want, although I'd still prefer it if FAYT could find substrings within files. Maybe I'll post it as a feature request.
For now, how do you clear out a filters entered this way? (as *[string] )? If I type * and then a string and hit enter, the filter bar goes away, and files get hidden according to the filter. If I type * again, it does not show the filter currently in use or allow it to be changed or deleted. The only way I've found to get rid of a filter entered this way is to change folders, or type *, enter a new string, and then backspace it out. Is this by design? I don't use filters often, am I missing something obvious?
I'm probably misunderstanding something there, but doesn't typing *whatever (where "whatever is your substring) in the FAYT field cause FAYT to "find substrings within files"?
Only if that substring is at the beginning of a file. For example, I have music from a Japanese singer named Kuraki Mai. FAYT will highlight her folder if I type "Ku", "Kura", or "Kuraki" but not if I type a substring within her name that is not at the beginning, like "raki" or "Mai."
What I would like is if DOpus's FAYT worked more like Firefox's FAYT (or had a preference to make it work this way) - IE finding an instance of a string, as entered, no matter where it occurs in the filename.
Sorry, missed that you were talking about filters, not FAYT. Yes, filters work the way I would like FAYT to, and so does the actual find dialog, but it's cumbersome for what I'd like to do.
I can create a filter, find the file I want, and then remove the filter, or I can invoke the actual find dialog, which finds string no matter where they occur in filenames, but if FAYT worked the way I think it should, I could just type and find a file without having to open up any extra windows or doing any "cleanup" afterwords.
My point wasn't that there was no way to do what I want. My point was that the way FAYT currently works is probably counter-intuitive to a lot of people (like users of Firefox's FAYT) and could potentially be made more useful.
Tbone, it's not a toolbar field or textbox I made, it's the optional "Find As You Type" tool that Opus has. To enable it check the box indicated in the screen grab below. Then to use it with the focus in a lister press * to activate the filter. Then SLOWLY type a few characters. When the filter you want is in place, press ENTER to lock it in.
Note the filter stays locked in until you change folders or type ** to reset it.
Although I primarily use it for its find as you type capabilities, it's much more than that. Instead of initially typing a * to activate the find as you type filter, you can type : instead and Opus will select all files/folders that match the characters you are typing. Or you could type a > and enter a command, or ? and enter a DOS command.
Hmm, I just noticed Opus doesn't open the field box if I initially type a ?. I'll have to investigate that and if necessary, submit a bug report on it.
Why slowly? I can type quickly and it still seems to work without problems.
Seems fine here. ? opens the field in Command mode. Were you in a virtual folder like My Computer or Desktop when you tried? None of the Find-As-You-Type stuff works in virtual folders that are controlled by Explorer, which still confuses me sometimes until I notice. (Using /desktopdir instead of Desktop solves the problem for me, though.)
Because that's the note I made when the FAYT feature was first introduced.
I don't remember why, but it sticks in my mind in the beginning it was suggested we type slowly. You're right though, now I can type fairly quickly and Opus keeps up.
I wasn't in a virtual folder, just plain ol' C:\temp. I'm at my office now on my Vista laptop and it behaves the same way here. I have to type a different starter character and then change it to ? in order for that tool to work.
Weird. I wonder if it only happens with certain keymaps? I'm using a UK keymap and typing ? opens the field on both XP and Vista. (Though I've only tried Vista via Remote Desktop from my XP machine, so far.)
John, that's the filter box that's shown in your screenshot, not the find box. The FAYT (find as you type) box is the one that appears if you just start typing (without typing an asterix first).
The filter box hides files and folders that don't match the string you have entered.
The find box works differently, it highlights the first file in the list that matches the string without hiding anything, and you can hit F3 to highlight the next matching file. However, it only searches for the string you've entered at the beginning of a filename (not in the entire filename).
There's a screenshot attached showing what I mean. In the screenshot you can see that the find bar fails to highlight the file with the string "example" in it because it only looks for the string at the beginning of the filename.
Actually, the colon-string thing you mentioned in your post (which I also didn't know about) is closer to what I'm looking for, but it highlights ALL files that contain the entered string.
The way the regular find as you type works now is inconsistent with how find from the actual find dialog works. I think it would be nice to at least have an option for regular find as you type to search entire filenames.
Personally, I dislike the way the Basic Find dialog does substring matching whether you want it to or not. I'd rather it was changed to require people to type string if that's what they want, because if they don't want that then they have to use the Advanced Find dialog. (But GPSoftware seem to disagree. )
Going back to FAYT/Filter/etc., what's your objecting to using the * filter mode to hide non-matching files? Do you need to find files containing substrings, one-by-one, but also see them in relation to files that don't contain the substring, or something?
Remember where the FAYT feature came from. Although the interface is partially modeled on the one in Firefox, the actual "type to find" string matching feature already existed and was based on the standard system listview behavior (as exhibited by Explorer.)
Not saying I object to the idea of an option to do substring matching, but I disagree that the current behavior is inconsistent - this is really how it's always worked.
My complaint is just about the unnecessary difficulty of the use case of "I want to find a file that I know part of the name of, and execute it." Currently you can't do that at all with FAYT unless the part of the filename you know is the beginning.
Doing it with the find dialog requires invoking the dialog, typing the string, running the file (by clicking), and then closing the window.
Doing it with a quick filter requires entering a filter, running the file, then invoking the filter bar again to remove the filter to get the original view back. Since the filter doesn't highlight the file, even if it's the only result, you can't just hit enter to run the file you've found either, it has to be clicked, which will dismiss the filter bar (meaning you can't simply backspace out to remove the filter, you have to type ** - enter).
If FAYT worked the way I would like it to, doing this could be a few keystrokes and hitting enter. Worst case you might have to hit F3 a few times if the file you want isn't the first in the list that contains the substring you've entered. This wouldn't effect FAYT's current functionality, and if it's implemented as a preference then people who don't like it could just leave it off anyway.
I think I'm beginning to understand the point here.
Correct me if I'm wrong Paradox52525, but I think you want to simply locate in the file listing a file whose name contains a string rather than restrict the display to only files whose name contains the string.
Is that one way of stating what you are looking for?
)