Change in find files search in

[sekular]

At the moment the alf+f7 find files window locks the total commander application when it is open.

I would to request that an option be added to make the find files window always on top. At the same time allow for the total commander to be completely usable. An additional feature. When changing location it automatically changes the "search in" location.

This improves use of the find files in my opinion. At the moment i have to find the location i want to search then go to alt+f7 and if i want to change the location i can click the button and browse with the directory tree or i can change the path or i can press cancel and browse to a new location and then alt+f7 again.

It could improve searching speed if you have to do a lot of searching.

edit: i see this is already been requested a few times before after doing some searches. had to do a lot of searching a few days ago and just had the idea. sorry.
I was reading another thread would it be possible if when a search is going it locks the window but when a search is not going the window is usable as suggested above?

[sekular]

Do you think this feature is possible?

Basically it just allows the search in field to be changed by where the active panel location. By making search box always on top and only locking the interface when it is searching.

[Stance]

Hi sekular
This feature was often requested, even a poll exists. Please use the forum search for: "Non-modal search window" and the like.

The current workaround is: Just start a 2nd (or more) instance of the TC and work with the non-blocked TC in the meantime.

Do you think this feature is possible?

I'm sorry but this is technically impossible. Most unpackers like the external unrar.dll do not work correctly or even crash when called multiple times, e.g. for unpacking and searching at the same time. The same is true e.g. for plugins.

[sekular]

I am sorry to repeat an already posted request, I read some threads and i thought my request was slightly different. But I was mistaken.

Would it not be possible then to prevent other features from working, like unpacking and only have the ability to navigate through folders and set the search in field.

You could make menus and non file list panel non clickable and then disable all keyboard shortcuts and prevent context menus. Maybe even a message when doing alt+f9 for example, packer not available in search mode.

Just throwing some ideas around

[ghisler(Author)]

Would it not be possible then to prevent other features from working, like unpacking and only have the ability to navigate through folders and set the search in field.

This would be very difficult because plugins and packers can be used in almost every function, including e.g. the multi-rename tool, synchronize dirs, file panels etc.

[Flint]

ghisler(Author)
How about possibility to open external Find Files dialog as a separate process, just as SyncDirs and Lister can now be started? With command line arguments similar to SyncDirs, e.g.

Code: Select all

totalcmd.exe /S=F:SettingsName /O=list_name <search_dir>

the parameters SettingsName and /O being optional. I think it would be useful when extensive communication with the main window is not needed. If the problem is in implementing the Feed to Listbox function, it can be disabled (though the list could be transferred via pipe or similar mechanism into the parent TC process).

[Balderstrom]

Autohotkey fix, to easily toggle the "Modal-ness" of the search window, with the Search hotkey, ALT+F7.

Alt+F7::
1) Make the find dialog non-modal, AND
2) If a Find Dialog exists, and is active, Alt+F7 minimizes it.
---- Can then use TC as normal.
3) If a Find dialog exists, and is minimized, Alt+F7 restores it.
---- Find Window becomes modal again.

Compatible with TC7.56 and TC8.0beta, Win2K and Win7 (tested), WinXP should be fine.

[ghisler(Author)]

How about possibility to open external Find Files dialog as a separate process

That could be done, but then it couldn't search on an open ftp connection or file system plugin. Also "Feed to listbox" wouldn't be possible.

[Flint]

That could be done, but then it couldn't search on an open ftp connection or file system plugin.

Well, that's the case for SyncDirs too, and it did not stop you from implementing it.

Also "Feed to listbox" wouldn't be possible.

Even without it, external Find Files will still be useful. But is it really too hard to implement sending the list of files via a pipe, or something like that?

[Samuel]

Support!

Also "Feed to listbox" wouldn't be possible.

Even without it, external Find Files will still be useful. But is it really too hard to implement sending the list of files via a pipe, or something like that?[/quote]
Or even create a new TC commandline option to feed the files to one panel.
This could be reused for search results from other programs as well.

[Flint]

Or even create a new TC commandline option to feed the files to one panel.

Thanks for supporting the idea, but unfortunately your method will not work. First, command line length is restricted to 32768 characters (and even 8192 in Win2000); for long search results lists this limit will be reached instantly. If you wish to pass all the results via command line it's better to put the whole list into a file (like %L in TC does for external programs), and then read this file from the target application. But sending the same data via pipe will be much faster because of absense of disk I/O.

Second, even when you start a new instance of TC with the search results passed via command line, you still will have to make some specific call from this new instance into the old instance to send search results from the command line of the new (temporary) TC into the file panel of the old (main) TC. Why then an additional step with the new TC instance? Why not make absolutely the same specific call directly from "Find Files" into the main TC instance?

What about external applications, sorry, I don't think they can be useful in this situation. To achieve the same result you just need to send the search results into TC panel, and then call any application you need with %P%S or something like that. The Find Files dialog is simply not designed for running applications from inside it; trying to squeeze such functionality into it will make the dialog overloaded because of numerous parameters needed for starting apps.

[Balderstrom]

Without a command-line parameter. There could easily be an internal command, called from a button on the "external" Find Files that does a WM_CopyData (no character limits) to it's parent (i.e. TC) which does a feed-to-listbox.

It wouldn't even be much code, as the FindFiles already does a FeedToListbox --- maybe one additional function or two, to send/receive the message and call the already existing FeedToListbox.

It would also be one step closer to enabling native Messaging to TC from extenal scripts (e.g. AHK).

[Flint]

There could easily be an internal command, called from a button on the "external" Find Files that does a WM_CopyData (no character limits) to it's parent (i.e. TC) which does a feed-to-listbox.

Yes, this is a good idea.

It would also be one step closer to enabling native Messaging to TC from extenal scripts (e.g. AHK).

Beta 10 introduced one step in this direction already. (Though I don't know whether AHK will be able to benefit from it, since a window with message procesing is required for making use of the new WM_COPYDATA functions…)

[Balderstrom]

AHK has message processing. And with AHK_L these days - Objects and Structs; #Debug mode returns all kinds of niceness