I am trying to create a button on the toolbar that brings up the Find dialog box and prepopulates it with my search options and then waits for me to click the "Find" button to initiate the search.
I have the button on my toolbar and the command I have associated with it is as follows:
Find FILTER "myfiltername" IN "c:\dir1" "c:\dir2" RECURSE ADVANCED
The command selects the proper filter and sets the search directories correctly. The issue I am experiencing is that it automatically starts searching before I can modify the criteria of my filter in the "Advanced" tab to specify what folder name it should be searching for. The search starts immediately when I click my button and then I have to tell it to stop, tweak the search criteria, and then initate the search. How can I get my command string to tell the Find command not to actually initiate the search until I click the "Find" button?
I have already tried searching the dopus forums (and the web) for an answer but haven't found one. I appologize if this has already been answered and I just haven't found it or if this is not the appropriate place for this question. Thanks in advance!
I tried adding a few args that require 'values' withOUT specifying the 'actual' value to see if I could trick the Find dialog into NOT executing the find - but it still runs. There's a generic @confirm modifer that prompts you before running the rest of the commands in a button/hotkey/etc - but that doesn't present you with the Find dialog in order to then tweak anything before it executes... So:
a.) You'd probably need to submit a program suggestion to GPSoft
b.) If there's just one or two arguments that you think you'd need to tweak on most Find operations, then you could substitute some of those options with a string dialog: i.e. change your command to something like Find FILTER "myfiltername" IN {Rs|c:\dir1|Specify search paths...} RECURSE ADVANCED... but 'multiple' values for a single 'argument' might be a pain to get right...
c.) another option might be to try running the find operation such as you've done above to set the "usual" options that you'd always want to be pre-populated, then copy the /dopuslocaldata\State Data\find.osd file to some other filename like find.org, and then just your button or hotkey or whatever to run something like this:
dopusrt /cmd Copy FORCE FILE "/dopuslocaldata\State Data\find.org" TO "/dopuslocaldata\State Data" AS find.osd
Find ADVANCED
This will take the settings of your preferred pre-populated search stored in the referencefind.org file (that you'll keep there) and put it in play as the live file (find.osd) each time you run a new find operation, in essence "resetting" whatever may have been the previous search criteria to your preferred settings, and yet still leave the Find dialog open for tweaking...
Really though, this is kind of a hack... and the best thing would be for you to request Opus to adda NORUN argument or something that would intentionally leave the dialog open.
steje, thank you for your quick and thoughtful response!
Option B...
It seems that my problem is happening because I am specifying both a filter AND the directories to search in. If I only specify one or the other I don't run into this problem. It looks like the dopus logic assumes that once you have both the filter and search directories defined then the search can be performed and you won't want to tweak anything - this is by no means unreasonable, just unfortunate for what I want to do. FYI, the crux of what I am trying to do is 1) specify the directories for a common search I do (because there are about 13 directories and specifying them becomes tedious), 2) specify to only match against folders (ie not files, hence the need for the filter) and 3) specify the actual pattern to match against (via the filter). I tried your suggestion of using the Rs Control Code, but while this did delay the search from executing in that it required me to fill out a text box before the search would happen, that text box only allowed me to specify the search location and not the pattern to match against which is what I would really need it to do.
Conclusion - I don't currently see a way of making this option work.
Option C...
It seems like once I replace the .osd file I would be telling all future Find operations to use these settings as well. I could manually reconfigure the first search I do after using my button to get rid of these settings OR I could create another button that toggles the Find settings back again by replacing the .osd file used for my custom search with a copy of the original .osd file. Does my analysis sound correct to you or am I misunderstanding how this would work?
Conclusion - This would work but would require me to either manually fix the Find dialog box after using my button OR I would need to create another button to return the Find dialog to its usual settings.
Right now it looks like I may have to go with option A if I want it to be exactly the way I want it. Thank you again for your response!
I guess you just have to play with it to see which way makes the most sense to you. I'm not sure what you mean with your comments about Option C though... it "sounded" like you wanted to "always" have these search criteria entered in for Find operations... If that's NOT the case, and you only wanted these settings pre-populated for certain searches that you perform often, but that you want a "clean" Find dialog for most "other" searches, then I'd say you would want to have two Find "buttons" or hotkeys... perhaps like:
Button 1 (normal search):Delete FORCE QUIET FILE "/dopuslocaldata\State Data\find.osd"
Find COLLNAME "Find Results" SHOWRESULTS tab IN {s} Button 2 (special search):dopusrt /cmd Copy FORCE FILE "/dopuslocaldata\State Data\find.org" TO "/dopuslocaldata\State Data" AS find.osd
Find ADVANCED
The first buttons applies the same logic as what we talked about above for Option C. By DELETING the find.osd file, ALL of the search criteria is cleared for the ensuing Find operation and Opus will create a new find.osd file based on defaults. Or... as in my example above filled in with whatever command line options you pass that DON'T otherwise provide Opus with enough info to actually 'execute' the search (which is what you've found happens when you pass location and filter info - i.e. where to search and what to search for).
The second button does what we've talked about to pre-populate the Find dialog with your preferred search criteria...
The 'first' button is actually what I use for both the <Ctrl+F> hotkey and my Find 'button' based on some conversation we had over in this other thread, which will give you another way of doing things as well using a little tool written by deleyed...
steje - I wanted to be able to have the Find dialog work as it normally does for most searches, but then have it have a custom setup for this particular type of search when I need it - sorry I didn't make that clear. Overall, we are on the same page and I understand how to solve my issue the way you are explaining it. Thank you again for the help!
Christiaan - I thought about using an AutoHotkey script but was a little leary about doing so. I will definitely give it a try if for some reason I can't get the other way to work. Thanks for the advice!
If you want "regular" searches to NOT use some 'different' set of default values that you could force it to put in place before running similar to how you want this specific "custom" search to do, then it get's kludgey. For instance... THIS doesn't really work:
dopusrt /cmd Copy FORCE FILE "/dopuslocaldata\State Data\find.osd" TO "/dopuslocaldata\State Data" AS find.org
dopusrt /cmd Copy FORCE FILE "/dopuslocaldata\State Data\find.sav" TO "/dopuslocaldata\State Data" AS find.osd
Find ADVANCED
dopusrt /cmd Copy FORCE FILE "/dopuslocaldata\State Data\find.org" TO "/dopuslocaldata\State Data" AS find.osd
Where the idea here would be...
save whatever the LAST "regular" search criteria was to a .org file
copy the specific "custom" search criteria into place so it pre-populates the dialog
open the Find dialog without executing
restore the 'original' LAST "regular" search criteria so the next "regular" search (i.e. <Ctrl+F>) picks up where it left off...
Really, this would best and properly be handled by submitting a feature request/program suggestion to GPSoft to add a NOEXECUTE type argument to the Find command...
steje -
I was thinking of doing it either one of two ways. The first way I was thinking of was exactly as you described. The second way I was thinking of would be to create an additional button that handles copying back the original "normal" search for when I don't want to do my special search. This way the first button would not have to copy back the original osd file in between launching the Find dialog and actually performing the search. Is this why you were saying the way you described would NOT work... ie because you could probably get the Find dialog to launch the way I want but then immediately copying back the old osd file would cause the search to use the wrong setting once I click the "Find" button? Also, yes, I realize my second option would be a little annoying since to perform a "normal" search I would have to press this other button (at least for the first time after running my special search) - but I am assuming I could set up a hotkey, etc from within Dopus to make this easier, or even setup the regular Ctrl+F key to do this. Thanks again!
Ya know... I think with lots of file copying and all that it could just get too kludgey. I think it might make sense to consider submitting TWO feature requests to GPSoft:
NOEXEC/S
Would allow you to fill in ALL of the options you want to for a find operation, but would cause Opus to NOT execute the actual search. I think this is cool to allow you to set LOT'S of info you know you search on often but still let you slightly customize it before firing the search...
NOSAVE/S
Would tell Opus NOT to save any of the search criteria either passed on the command line, or resulting from opening the dialog and entering manually (and exclusive from the option above).
Combining the two would do what you want to do gracefully, and the second option idea would be good for the various Opus users asking for such info never to be saved in an MRU list at all... Personally, I probably wouldn't use the first one... but I would definitely use the second one we just came up with...