Total Commander

Sometimes searches take up to 2 hours (especially on network drives) and I cannot use TC that time...

Open another instance of TC

I rarely use TCs search because I usually know where my files are. (And I use locate in some other cases)
But I also support this approach too.

I TOTALLY support this I wrote something about this a while ago.

ghisler(Author) wrote:Unfortunately this would require a major redesign of all the various unpacking functions. One alternative would be to start the search in a separate program instance (launch a hidden TC with just the search window), but then "feed to listbox" would no longer be possible.

Sorry to dig this thread out, among all the other Modal/Non-Modal search discussion.

I just found out the possibility to Sync non-modal by doing this

TC Help wrote:/S=S Start "Synchronize dirs" directly, accepts two paths as parameters, or alternatively a settings name in the form /S=S:SettingsName
If the parameter begins with an equal sign "=", e.g. /S=S:=SettingsName, the comparison will start immediately. If the equal sign is the only parameter, e.g. /S=S:= , the comparison will start with the passed directories and last used options.

Can the search option not be implemented similar...
I know this wont work if you want to click the file to open the corresponding folder in TC and the feed to list box as well as you said.

But sometimes i just search for a file and its enough for me to know where it is.

If it is no big effort for you, can this be implemented?

thanks anyway

While standalone sync or lister are useful, a standalone search dialog would be quite pointless. Just open a second copy of TC if you need to perform such a long search.

ghisler(Author) wrote:While standalone sync or lister are useful, a standalone search dialog would be quite pointless. Just open a second copy of TC if you need to perform such a long search.

I strongly disagree. First, starting another copy of TC is simply not enough. You need to reopen the same directory, reselect the same files/subdirs, reenter (or select from history) the same file mask, also (if you search by text contents) you'll have not only to check the checkbox but also get the search text from the history combobox. All this makes using the new TC instance very unpleasant.

And, second, it's really very frequent situation that I started a long search, but suddenly remembered I needed to do something else while search is going. Now I would have to either stop the search, reopen another TC instance and restart search there (and do all the steps mentioned above), or I should leave the first TC searching and open another TC instance to do what I needed… just to suddenly remember that I have to do it in a different directory which was opened in the first TC but not yet saved in wincmd.ini, so it's not present in the second TC. I'll have to reopen it, switch to the sorting mode I need, select the custom coulmns I need, and so on, and so forth. All this is extremely unefficient way of spending time.

Non-modal search dialog would be a great advantage.

Perhaps a "clone this TC instance" option on the Search function would be a useful enhancement.

I also disagree. A standalone or non modal search dialog would be very useful.

I concur. A standalone search dialog would be very useful.

Roman

And what would you do with the search results? Stare at them and think "Eeureka"?

You can't
- go to the file
- feed result to a listbox
- copy/move/delete whatever the file

Christian,
Well, we assume there would be some communication between the processes to enable the usual functionality after the search. We could already go to a file using the existing command line parameters. The only thing remaining would be the feed to listbox, for which TC would have to accept a command line parameter to say load a list of files from a list file.

Roman

ghisler(Author)
In addition to what Hacker said, we can also press F3 on a file to view it, and in many cases nothing more is needed. But I don't believe you think that all functions you just named are absolutely impossible to implement.

This is a no brainer - every window should be able to work in background and not interfere with file browsing. This includes searches but also unpacking/packing operations (at least in queue if not possible to do at the same time.)
How easy or hard to program it in TC is entirely different matter. But that should be done, is no question. The sooner it is done, the better for TC and his author.

Performing operations one by one is very much obsolete. Today's file managers (even free ones) have this possibility.

I am finding myself using other file manager every time I need to perform search function which says enough about this.

Why not make it simple:

How about making the dialog non-modal (via a button a la 'Background') and returning the same dialog whenever user tries to search again before the previous dialog is closed?

This avoids the issues of plugin thread safety and any inter-process communication too.

vladputin,

This avoids the issues of plugin thread safety

Not really, since you can do more with packers / plugins than search.

Roman

Hacker wrote:vladputin

This avoids the issues of plugin thread safety

Not really, since you can do more with packers / plugins than search.

Roman

Correct. Well, then the archive and plugin search must be turned off anyway.

Not so cool, but at least it shouldn't be too hard to implement and you avoid having to open a new instance and having to navigate the the search location whenever you don't want to search with plugins (95% of the time in my case)