Page 1 of 1
Two menu items (and commands) for search
Posted: 2013-09-06, 08:00 UTC
by Lefteous
The new search in background I don't really understand why there are two commands for search now. Why should I start a search the old way?
Wouldn't it be sufficient to have just the new command? Or is this just something for the early beta versions?
Posted: 2013-09-06, 20:34 UTC
by ghisler(Author)
Some things just don't work in the background, like searching on FTP servers (this needs the existing connection), or searching in search results. Also it's faster to launch, at least with some virus scanners, since no new process is needed.
Posted: 2013-09-06, 20:49 UTC
by Lefteous
2ghisler(Author)
Yes I know these current limitations. The question is if these limitations comes to mind when you open the menu containing the two commands. Difficult.
Anyone has an idea?
Posted: 2013-09-06, 21:18 UTC
by MaxX
Suggestion.
Add parameter fo config, which determines if outer process should be used.
Posted: 2013-09-06, 21:35 UTC
by ghisler(Author)
You get an error message when you try to start a background search from ftp, or from a search result.
Posted: 2013-09-07, 15:40 UTC
by Lefteous
After collecting the facts this is my suggestion based on the current implementation:
cm_SearchFor should do the following:
- When the user starts the search from an established FTP connection or from a search result display the old modal search dialog (same behavior as TC <8.5).
- Otherwise display the new search dialog.
cm_SearchStandalone
- No changes
- Command is no longer part of main menu
cm_SearchInternal
- New command to call the internal search dialog (current cm_SearchFor behavior)
Posted: 2013-09-08, 06:51 UTC
by Samuel
I also had this idea. Think this should be a nice solution especially for "default" users.
Posted: 2013-09-09, 19:09 UTC
by MarcinW
ghisler(Author) wrote:Some things just don't work in the background, like searching on FTP servers (this needs the existing connection)
Sockets can work in the background thread, but this thread must handle messages - like this:
Code: Select all
procedure TMyThread.Execute;
var
Msg : TMsg;
begin
while GetMessage(Msg,0,0,0) do
try
TranslateMessage(Msg);
DispatchMessage(Msg);
except
...
end;
end;
The code above is just an idea, it must be expanded to handle unicode/non-unicode windows and thread synchronization. I can provide more info if needed.
Regards
Posted: 2013-09-10, 14:17 UTC
by ghisler(Author)
It's not a background thread, it's a separate process. This is needed because many of the used plugins (packers, file system, content) are not thread-safe.
Posted: 2013-09-10, 18:21 UTC
by JimW
Lefteous wrote:After collecting the facts this is my suggestion based on the current implementation:
cm_SearchFor should do the following:
- When the user starts the search from an established FTP connection or from a search result display the old modal search dialog (same behavior as TC <8.5).
- Otherwise display the new search dialog.
cm_SearchStandalone
- No changes
- Command is no longer part of main menu
cm_SearchInternal
- New command to call the internal search dialog (current cm_SearchFor behavior)
+1
This sounds pretty reasonable to me as well.
Posted: 2013-09-18, 10:10 UTC
by Lefteous
2ghisler(Author)
So what do you think? I think my suggestion is a good compromise. Or do you see any disadvantages?
Posted: 2013-09-19, 14:05 UTC
by ghisler(Author)
I still think that these should be separate functions - search in the same process for quick file locations, search in the background for longer search jobs.
Posted: 2013-09-20, 07:09 UTC
by Lefteous
2ghisler(Author)
I don't think it's actually possible to say for a user if the search will a quick file location or a very long search job. First you wanna do a small search and then you realise the file is not there but somewhere else. now you have to close the search window and open the background search - really cumbersome.
And I don't see a reason to use the foreground search instead of the background search (beside the known limitations).
My suggestion also supports these explicit commands so everyone can use it as desired. But the common case should be the background search.
One small suggestion: As the foreground and background look the same there should be a way to distinguish them. My preference would be to label the search buttons respectively. Could be 'search in background' and 'search in foreground'. Other ideas are welcome.
Posted: 2013-09-20, 07:17 UTC
by Sir_SiLvA
Lefteous wrote:One small suggestion: As the foreground and background look the same...
They DONT when you use a custom TCIcon...