Hello! My apologies if I'm missing a setting somewhere, but I saw this thread and it looks like it's not currently available?
It would be very helpful if the Contents field in CTRL+F Find could leverage Windows Search (perhaps as a checkbox?). For example, for a large folder of PDFs (iFilter is installed), it doesn't return contents, but the Quick Search field does, which can feel like a rather confusing inconsistency and greatly limits the power of the Find feature for those of us for whom the vast majority of the files are PDFs.
Possibly, although the Find Files > Contents field will use IFilters as well, so it should find contents of PDFs if an IFilter is installed, it'll just be slower than using indexing.
Thank you, Leo. Is there a setting that determines whether iFilters will be used for Find Files? It doesn't seem to work that way for us with the Containing text: field (sorry, I mislabeled it as "Contents" in my original post): we get search results for PDF contents in Quick Search, but not when using Containing text. I thought it might be a wildcard issue or something, but I've tried it with/without (and * in various places), but the same search that returns results in Quick Search always returns no results for a folder of PDFs when using Find Files > Containing text.
IFilters are always used, as long as they're installed and nothing (e.g. permissions, antivirus) blocks Opus loading the IFilter or opening the files being searched. They don't need to be turned on.
They probably need to be 64-bit as well (assuming 64-bit Opus), but I think that's true in general for Windows, too.
You can get a list of IFilters installed on your system using NirSoft's SearchFilterView tool, and if you go to where the DLL is the General > Description column in Opus will tell you if it's 32-bit or 64-bit. It should say "AMD64" at the start of the description for a 64-bit DLL.
Make sure the other search criteria you have set up aren't excluding the files. It sounds obvious but it's very easy to overlook.
Thank you, Leo. I will confirm whether Acrobat 2020's iFilter is 32-bit; DOpus version is 12.30 x64. I had Reset the search prior to performing a new one, but will check again if there are criteria I may have missed.
So you're saying it's possible there's a scenario in which Quick Search (and Windows Explorer) would load a 32-bit iFilter and return results, but Containing text: won't return results because it's looking for an x64 iFilter? I had the understanding from this comment from Jon that Opus's internal Find command doesn't use Windows Search, and I thought that explained why we were seeing different results between Quick Search and Containing text.
I was wrong, it is apparently using Windows.Data.Pdf.dll, which shows AMD64, so it would appear the bitness of Opus and the PDF iFilter match. Are there issues with specific iFilters, such that one might work with Quick Search but not Containing text:?
It looks like the issue is the Windows.Data.Pdf.dll iFilter. After a lot more testing, it appears to produce very inconsistent results, including in Explorer.exe. Very strangely, it would sometimes fail to produce hits even for words in the filename itself. There also seemed to be some inconsistent behavior with native PDFs and OCR'd PDFs. I was going to put together a test matrix, but given it wasn't even producing hits on filenames, it seemed pointless.
After switching to SumatraPDF's iFilter, it looks to be searching as expected, including in the Containing text: field. I was going to install Adobe's instead, but all the links to their iFilter seem either broken or perhaps no longer supported (last update I could find to PDFFilter64installer.msi on their FTP site was 2008).