I'm looking for an IPC call to abort an ongoing search operation. For example, when the search term is too broad, e.g. the user searches for *.* across all drives by mistake, "Everything" is blocked for several minutes gathering the data (before a single byte is returned to the calling app).
The only hint I could find in the SDK is the following:
#define EVERYTHING_IPC_IS_DB_BUSY ... // db is busy, issueing another action will cancel the current one (if possible).
However, when I try sending another query with SendMessage(hwnd,WM_COPYDATA,...) it hangs until the first search completes.
Ideal would be a simple IPC call in the form
SendMessage(hwnd,EVERYTHING_WM_IPC,EVERYTHING_IPC_ABORT,reply_copydata_message);
with reply_copydata_message the id set in EVERYTHING_IPC_QUERY.
Is there such a call? Or is there any other way to abort the long search operation?
Aborting a search?
Re: Aborting a search?
Everything watches the IPC caller thread and if it ends Everything will abort the query.
Please try putting your Everything IPC calls in a separate thread and end the thread if it takes too long.
You can also send a new query to abort the current query.
Try sending an empty query to abort the current query.
Calling any other IPC call will cause the DB to block until the query completes. Please make sure you call Everything_Query(FALSE) and process the results when they arrive.
Please try putting your Everything IPC calls in a separate thread and end the thread if it takes too long.
You can also send a new query to abort the current query.
Try sending an empty query to abort the current query.
Calling any other IPC call will cause the DB to block until the query completes. Please make sure you call Everything_Query(FALSE) and process the results when they arrive.
Re: Aborting a search?
Unfortunately putting the search query in a separate thread and terminating that thread didn't help. Everything rermains busy for several minutes, and doesn't even stop when I close the calling program (which terminates all threads). I cannot even launch Everything.exe while this query is busy. And if it's already open, it sits there grayed out with "(not responding)" in the title bar.
My guess is that it doesn't hang in the actual search query, but when preparing the data buffer with the results to send back via WM_COPYDATA, because the query for *.* itself is very fast within Everything.exe. Pseudo code:
results=Query("*.*");
SortResults(results);
for (int i=0;i<results.count;i++) {
ReallocateSendBufferIfNeeded(buffer);
CopyToBuffer(buffer,i,results);
}
Either SortResults or the "for" loop hangs because there are 4.5 million entries, and you don't check within these functions whether the query should be aborted. It would be nice if you could add this in one of the next versions.
My guess is that it doesn't hang in the actual search query, but when preparing the data buffer with the results to send back via WM_COPYDATA, because the query for *.* itself is very fast within Everything.exe. Pseudo code:
results=Query("*.*");
SortResults(results);
for (int i=0;i<results.count;i++) {
ReallocateSendBufferIfNeeded(buffer);
CopyToBuffer(buffer,i,results);
}
Either SortResults or the "for" loop hangs because there are 4.5 million entries, and you don't check within these functions whether the query should be aborted. It would be nice if you could add this in one of the next versions.
Re: Aborting a search?
Is limiting the number of results returned useful?
In your SDK call you can specify the max results with the Everything_SetMax call. If you are showing results in a window, please consider setting this to the number of visible items in your window.
Sending all the results over WM_COPYDATA is quite slow, it was designed to only send a few hundred results.
Sending one million files should only take about 3 seconds (if only the filename was requested).
Building and sending this information cannot be aborted, as you have seen.
Another note is highlighting is really really really slow. What request flags do you use?
I have on my TODO list to add support for SHLockShared which would basically use shared memory between Everything and your process.
In your SDK call you can specify the max results with the Everything_SetMax call. If you are showing results in a window, please consider setting this to the number of visible items in your window.
Sending all the results over WM_COPYDATA is quite slow, it was designed to only send a few hundred results.
Sending one million files should only take about 3 seconds (if only the filename was requested).
Building and sending this information cannot be aborted, as you have seen.
Another note is highlighting is really really really slow. What request flags do you use?
I have on my TODO list to add support for SHLockShared which would basically use shared memory between Everything and your process.
Re: Aborting a search?
Limiting the number of results via max_results sounds like a good idea - currently I'm using EVERYTHING_IPC_ALLRESULTS. As I understand it, I can then request more results via offset field.
I have just tested this, and limiting the results to 10'000 gave an almost immediate response. Thanks for the hint!
I have just tested this, and limiting the results to 10'000 gave an almost immediate response. Thanks for the hint!