I figured out that it was drastically slowing down queries, so I now pick only flags relevant to the query.
But if for example I don't pick EVERYTHING_REQUEST_DATE_MODIFIED then I can't retrieve the modification date through the results.
Do you have any clue on how to optimize the selection of flags for a query and still offer enough information in the results?
And by the way is there any reason why searching for creation date is so slow compared with other date queries?
why searching for creation date is so slow compared with other date queries
I could be totally off, but could it be because date created is not indexed where modified / accessed are?
Everything | Options | Indexes -> Index date...
If the requested information is indexed it will be returned instantly.
If the requested information is not indexed it will be gathered before returning (this could take several minutes).
Please check the Everything_IsFileInfoIndexed call (currently undocumented)
Pass the EVERYTHING_IPC_FILE_INFO_* to check if the information is indexed.
Please check the Everything_IsFastSort SDK call (currently undocumented)
Pass the sort type to check if the information is indexed and has fast sort enabled.
About the scenario when the information is not indexed, is the time spent to gather data done on every such query?
And still about index information, in the added methods to your SDK I didn't see anything about ID3 tags and image data (width, height, bpp).
is the time spent to gather data done on every such query?
Yes. I've made a note to keep the SDK reply hwnd open for the next Everything release, this would keep the file information cached between queries.
And still about index information, in the added methods to your SDK I didn't see anything about ID3 tags and image data (width, height, bpp).
This information is not available to the SDK, yet. It will most likely be supported in Everything 1.5.
Currently you can only search for this information.