PDF file preview generation eats mouse clicks

[Blake]

Both of these scenarios still happen.

In the first one there is no delay set, preview is triggered, doubleclick fails.

In the second one there is a delay set, first you first click once to trigger preview generation, then you doubleclick to open the file - doubleclick happens after preview starts being generated - doubleclick fails.

Delay is irrelevant to the issue, the issue is that clicks are not registering when preview is generated.

[admin]

I think it is relevant that you got an easy solution (preview delay) to your original problem (double-clicks fail). The fact that mouse clicks are not registered is likely due to the Adobe preview handler, which is known for its unusual behavior.

[highend]

Get the PDF-XChange Viewer: https://www.tracker-software.com/produc ... scontinued

During installation you only need to select:
[x] PDF-Viewer files
[x] Shell extensions

Configuration | Preview | Previewed Formats
User-Defined Preview Handlers
pdf>{CF822AB4-6DB5-4FDA-BC28-E61DF36D2583}

2026-02-03_12-53-00.png

Afterwards you can still configure your Adobe as the default app for everything pdf related while the preview is done via the XChange Viewer...

[Blake]

I think it is relevant that you got an easy solution (preview delay) to your original problem (double-clicks fail). The fact that mouse clicks are not registered is likely due to the Adobe preview handler, which is known for its unusual behavior.

But that's not a real solution, since it only covers one specific case, and fails in all others.
Still had cases with clicks not registering even with delay set during just normally using the program.
I'll try replacing the preview handler then as suggested.

[Blake]

Configuration | Preview | Previewed Formats
User-Defined Preview Handlers
pdf>{CF822AB4-6DB5-4FDA-BC28-E61DF36D2583}
2026-02-03_12-53-00.png

When I set this, its probably the wrong GUID, since even if I change GUID to a random one, previews are still shown.
What's a way to check which GUID is actually needed?

Results from testing:
If there is any custom preview handler entry for .pdf,
even with the wrong guid, the clicks not registering issues are gone.

As soon as the custom entry is removed, the issues are back.

[highend]

Code: Select all

text "Prev. handler:" . <crlf> . get("previewhandler", "pdf") . <crlf 3> . "Associated app: " . get("assoc", "pdf");

and from a command prompt:

Code: Select all

reg query "HKEY_CLASSES_ROOT\.pdf\ShellEx\{8895b1c6-b41f-4c1c-a562-0d564250836f}"

And if you've installed v2.5.322.10 of XChange Viewer as suggested, that CLSID is the correct one
There is a fallback if the CLSID is wrong but it should normally only show the first page / thumbnail of that pdf (which is also the thumbnail handler of XChange Viewer^^)

http://www.nirsoft.net/utils/shexview.html
To see everything related to those handlers...

[RalphM]

I can confirm the CSLID:

Code: Select all

Prev. handler:
Preview handler for pdf files
GUID: {CF822AB4-6DB5-4FDA-BC28-E61DF36D2583}
DefaultName: PDF-XChange PDF Preview Provider
DisplayName: PDF-XChange PDF Preview Provider
Associated app: PDFXEdit.exe

It states PDFXEdit probably because I have the editor installed as well but after every update of the editor I reinstall the viewer as well and make it the default app for PDF because otherwise the preview is only very tiny on hover and it doesn't blow up if clicked for MDBU.