I'm not sure this is any worse than before, but it *feels* worse.
Often there is no indication that a background search is in progress.
The only way to know is to open the file dialog and see if the "Stop" button is enabled.
When the search is launched there is a particularly long delay.
This can be highlighted by searching a slow filesystem - like a file share.
If sgrep hangs, Slick is ever patient and won't ever kill it or complain how slow it is.
Speaking of which, sgrep.exe has hung on me - where should I upload a minidump?
It hung, apparently while just scanning for filenames - not even reading anything (PROCMON shows zero activity).
Hangs everytime I repeat the same search of the fileshare.
Doing a "dir /s \\the\same\share" works just fine.
Seems like there should be a top-level UI indication of a background search in progress, and a top-level way to stop it. Reopening the find-in-files dialog to hit STOP isn't very intuitive.
While the search is running, clicking the clock on the bottom right gets me:
---------------------------
SlickEdit Pro
---------------------------
There are no active background processes.
---------------------------
OK
---------------------------
Slick V20 would show the background search in the Background Processes dialog - though this dialog doesn't offer a way to stop the background process.
Slick V20 doesn't hang on the same exact search.
If I uncheck "Look in ZIP files", then sgrep doesn't hang -- procmon shows it making plenty of noise.
