So, I had a few use-cases for some features that GPSoft graciously added in recent beta's... Here's how I've decided to use some of those features to achieve what I think is better than either the default Find Panel feature or the old "Find Window" in v9 which various folks have bemoaned the loss of...
First, for things to work - I've switched <Ctrl+F> hotkey (bound to the Tools-Find Files menu button) from running the default "Set UTILITY=Find,Toggle" to instead run:
my_gofind {s}
...where my_gofind is a user command created to run the following - with the current folder path ( {s} ) passed as an argument to the user command:
go findtitle=Find runembeddedifnotfound
[
@ifset:listertitle=Find
go "&PATH&" newtab=findexisting
set source format=find utility=off
find loadprev=no showresults=tab
@ifset:else
go "&PATH&" new=800,186,799,541,notree
[
set source format=find listertitle=Find
find loadprev=no showresults=tab
]
]
...now, to explain. This is more than just a different way to launch a 'Find Lister' such as some people may have worked out using a find "Layout". Rather... it's an attempt to use the fact that the find panel is in fact operating in a regular lister window rather than a dedicated old Find Window, to bring some other features into the picture. This WON'T be for everybody, but I'm digging it...
The user command is using the lister title feature that was recently added to set up a framework so that I'm not always opening multiple 'Find' listers... so it's first checking to see if any listers with a title of "Find" are already open, and if so - to call it to the front. The rest wasn't possible until the 10.5.0.5 beta which added support for the embedded command system (also added fairly recently) to work with the 'Go FINDTITLE' command. Another required feature was to allow the embedded command block to continue even if NO lister with the specified title was found - which GPSoft provided in the form of the runembeddedifnotfound option...
From there, the embedded commands are checking to see if in fact a 'Find' lister was indeed found and brought to the front... if one was NOT found, then a new non-maximzed lister is launched and it's title set to "Find". Otherwise some additional common actions are taken in either the new or existing lister:
[ul][li]A new tab is opened to the folder that was passed to the command from the previous lister, if an existing 'Find' lister was found - I'm also looking to see if the folder I want to search is in fact already open in a tab in the 'Find' lister (newtab=findexisting)[/li]
[li]I load a particular format in the new tab thats adjusted better for the lister size I've settled on, you can omit this of course - but a bit more on this later[/li]
[li]If an existing lister was found, the utility panel is turned off, but in both cases - I then reload the panel by calling the 'Find' command with my preferred options - again, more on this later[/li][/ul]
Other notes:
Several motivating factors sent me down this direction... some may chuckle - but I more or less came to grips with the find panel. But I still just don't like the relative intrusion of it in the lister even though I can dismiss it fairly easily. But I realized amidst all the passionate debate that took place here on the forums that it's difficult to make a compelling argument for or against a personal preference. You either just like something or you don't - and there's not much point arguing about it. Still, I wanted to find some way of making the whole separate 'Find Window' idea do something useful beyond just breaking the find panel out of the current lister. So what do I like about this method? A few things:
[ul][li]Less interesting than just breaking the find panel out of the current lister... I get my results as well as the folder I was searching out of the current lister as well. I like this because for anything other than very specific searches, I often find myself doing only part of what I wanted to do with the results - and then either have ~other stuff to do or get bored or something.[/li]
[li]Similar to above, I sometimes find myself re-running the same search after switching folders and doing ~other stuff. With this method I'm often keeping the 'Find' lister open for quite awhile and I've found it pretty natural to switch back to it to revisit previous search folders there instead of the lister where doing the ~other stuff.[/li]
[li]Especially with the previous points, I'm finding it helpful to keep a sort of ~history of search folders as tabs instead of using other means... since I'm opening new tabs when calling this 'Find' lister - my previous search folders are readily at hand and mean a bit more to me when I switch to them and view the contents... it just helps me better recall why I was doing what I was doing as opposed to the 'Select folders to search' drop down list history in the panel itself. Switching between tabs in the 'Find' lister also uses the 'Lock Folder' so that the folder to search in is reset back to whatever tab you switch to without other action.[/li][/ul]
But really, this is in fact just a ~framework for other ideas I think I'm going to find useful... I've added a hotkey definition that I'm still wondering wheter or not it will cause unexpected problems - but so far, NOT. I've mapped <Escape> to run:
@ifset:listertitle=Find
close
@ifset:else
...which lets me close the 'Find' lister when I'm ready by hitting <Esc> key... 
. So far, it hasn't gotten in the way - and still works properly in any dialogs (even inline rename) in the 'Find' lister itself.
In a much more elaborate turn... I'm also weighing the benefit of using this to mock up more contextual search functionality. For instance, based on certain workflows - I am working on some 'Find' specific toolbars that are different depending on what type of lister I'm launching the search from... and pre-populated find args that I may also load if running a search from a particular folder path or ~other lister title (I've created several purpose-built listers that use the title in different ways). I may then also load a different format into either or both the tab being opened in the 'Find' lister as well as the Find Results (or other named collection I may send the results to).
I've attached a zip file with the actual user command I'm using as a base - since the code alone above doesn't make it work - the user command also has to include a PATH template to be specified so that the command understands the {s} path that the <Ctrl+F> hotkey is passing to it... You can extract the .ouc file from the zip and drop it into the /dopusdata\User Commands folder. You'll probably have to exit and restart Opus for it to be available though...
Other thoughts:
This whole thing (as well as other use cases) would benefit from: