Two menu items (and commands) for search

[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?

[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.

[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?

[MaxX]

Suggestion.
Add parameter fo config, which determines if outer process should be used.

[ghisler(Author)]

You get an error message when you try to start a background search from ftp, or from a search result.

[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)

[Samuel]

I also had this idea. Think this should be a nice solution especially for "default" users.

[MarcinW]

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

[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.

[JimW]

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.

[Lefteous]

2ghisler(Author)
So what do you think? I think my suggestion is a good compromise. Or do you see any disadvantages?

[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.

[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.

[Sir_SiLvA]

One small suggestion: As the foreground and background look the same...

They DONT when you use a custom TCIcon...