With the DF Image viewer, I've went ahead and linked it to work with PDF files. I'm having some issues.
I'm using Foxit PDF Editor to handle previewing the PDF files. I got thumbnails working through it's shell extension. Further, opening the .pdf file in the viewer works fine, AND it has zoom functionality.
My issues are as follows:
Dopus skips over .pdf files when using my mouse's forward/back button from the viewer. I have already modified the .pdf files to be in the category "Images" under "File Types". This occurs when the first image I open, which launches the viewer, is a non-PDF file.
The next/previous image buttons tied to my mouse's forward/back button cause dopus to crash when launching a PDF file as the first image in the viewer. I don't know exactly what function these buttons are trying to perform by default (e.g. next file vs next picture???), but it appears to be consistent. Simultaneously, the buttons from the viewer toolbar for next / previous image DO NOT cause this crash to occur, and work as intended.
Dopus Version 13.1 x64
Microsoft Windows
Version 23H2 (OS Build 22631.3007)
The viewer's next/prev list is only really meant for images at the moment. While documents can be viewed in the standalone viewer window, it's really just a side-effect of supporting them in the preview pane (since viewer and preview pane share most of their functionality).
We figure that people will use a separate document viewer (e.g. Foxit itself, not just Foxit's preview handler inside of Opus) if they want to view documents in a separate window.
That said, we may expand this at some point, especially with thew new Lister-Linked viewers making it more likely people will view other file types in a separate viewer window. (Videos are another big one.)
Please submit the crash logs if you haven't already. We should be able to use those to fix the crash (unless it's the PDF viewer that's crashing, but it's probably our bug in this case).
You can use Help > Submit Crash Logs from the default toolbars. If your toolbars are from Opus 12 and don't have that item, you can drag it (or the whole Help menu) out of Customize > Default Toolbars to get it.
Regarding the crash logs, I may have used improper terminology. It causes Dopus Image viewer to freeze until I force a restart, and thus no crash log has been generated.
From what I can see, it's trying to load a new file, which first involves closing the previous viewer (FoxIt PDF in this case).
The previous viewer looks like it's hanging while processing a right-click message. (Although it's strange, as it's being delivered via WM_APPCOMMAND instead of the usual mouse messages. It's possible I'm misinterpreting the parameters.)
Snapshots of the docsvw64.exe (or docsvw32.exe as appropriate) process and, if there is one, FoxIt process, might reveal something more, perhaps. Apologies for not thinking to ask for those before. Probably no need to make multiple of them in this case, as it looks like it's stuck in a stable way that isn't changing between snapshots.
It doesn't look like FoxIt is at fault here, as it's just letting the WM_APPCOMMAND message I mentioned be handled by Windows' default processing, which is then trying to send it to another window that is not responding (likely the window it came from, which is waiting for the original send of the message to complete).
I suspect it's all tied into the way the viewer (when showing PDFs) has multiple threads and processes interacting.
We might be able to fix it by simply filtering those messages.
I'd like to try and reproduce it on my own machine so I can try some things. Could you tell me the edition of FoxIt you're using so I can install the same thing? (e.g. PDF Reader, PDF Editor, etc.)
Seems there's a free trial going on right now. Honestly, I'm probably going to switch editors soon, as it's difficult for me to advocate an app that doesn't support a one-time payment model (aside from Dopus, your new plan is the most generous I've ever seen).
However, I must admit, I know of no others that support interacting with Dopus AND with zoom functionality.
A fix for the freeze will be in the next beta. Many thanks for all your help tracking this down!
Wasn't FoxIt's fault, either. More an unusual situation we hadn't accounted for. FoxIt was handling the Back button itself, and sending the event back to us while waiting for us to respond. We then asked FoxIt to close so we could load the next file, but FoxIt couldn't close until we'd finished processing the message it sent us, and we couldn't finish processing the message until FoxIt closed... Fix is to handle the message asynchronously on our side.