Frequently, I like to search the same set of directories by putting multiple directory paths into the find dialog. Essentially I would like to save that set for later reuse, meaning I sometimes want to do an ad hoc search and sometimes I want to search that set of directories.
Seems like the answer would be a custom button where a find dialog is launched and the list of search directories pre-filled.
This is where I need some help. I've made a few buttons but am not ready for this problem.
In addition I would hope this list of searchable directories did not pre-fill the standard find button.
You can't modify the Find dialog via commands at the moment.
What you can do is create a button/hotkey which run the Find command with various arguments, e.g. a fixed set of paths. Those are limited to using saved filters and/or searching by filename.
So if you just want a button to run a pre-defined search on pre-defined folders, then you can do that. Or if you want a button to ask you for a filename/pattern and then search for that on pre-defined folders, then you can do that as well.
Only mention these threads because setting 'everything' you 'might' want to search on in 'special' find cases might not be easy to do in button form? Maybe I'm wrong, but if you wanted to perform complex multi value searches, then I think you need the dialog... Anyhow, food for thought.
seems to be what I need to prepopulate the find dialog. Good!
On the next issue: If button1 is the standard find command and button2 is the find command above then using button2 results in button1 having the same set of directories when launched ("c:\dir1" "c:\dir2") which must be deleted one-by-one.
I read resource.dopus.com/viewtopic.php ... hlight=osd about clearing the find dialog on launch but I believe they are using a 32bit program which might be why it is not working for me since I'm using Dopus x64 - is this true?
In any case, I have created a button with this command:
Find in {allfile}
Its a little quirky but might be acceptable for now. Thank-you.
Find.osd must have become corrupted because I could not prevent high cpu usage during a find operation without deleting find.osd and recreating it via a search. Editing find.osd for pathstring requires more than a simple find and replace. Seems solvable via something like perl.
Rewriting the find.osd file on every find launch appears to be a kludge at best. Perhaps in Opus 10 we will get a clear pathstring command word.
You could use Find IN {sourcepath$} I guess... Still doesn't clear it, though, just sets it to something you're likely to want.
If you can reproduce the high CPU stuff with the corrupt XML file, could you upload the file (zip & attach it to a forum post)? It might be worth looking at why it's causing high CPU and fix it, even if the file is invalid/corrupt. Or it might turn out to be caused by something else...
Thank-you Leo - I had settled on Find in {sourcepath} and that's good enough for me.
The one line autohotkey command:
Contents := RegExReplace(Contents, ".*", "")
took this section of find.osd
D:\data\install
D:\data-old
E:\down
and changed it to something like
Was that the reason for the high CPU usage, I can't say. I uninstalled autohotkey and toss the compiled OpusClearFind.exe. No desire to revisit it right now.