Double-clicking on OpenEXR file has no effect

[franzb]

I've been a happy user of xnview for more than 10 years, and had no problems until today. I'm setting up a new machine running 64-bit Windows 8.1 professional, and I installed xnview 2.25 (small) with the OpenEXR plugins.

Everything seems to work fine, *except* one thing: When I double-click on an OpenEXR file in Windows Explorer, xnview starts but doesn't display the image. Double-clicking on PNG files works fine. Drag & dropping OpenEXR files to xnview's window works fine.

Any idea?

[franzb]

I managed to fix the problem by editing Windows' registry:

For some reason,
HKEY_CURRENT_USER\Software\Classes\exr_auto_file\shell\open\command
was set to
"C:\Program Files (x86)\XnView\xnview.exe"
instead of
"C:\Program Files (x86)\XnView\xnview.exe" "%1"

Changing it to the latter fixed the problem.

I don't know why the association wasn't properly done (but I would love to know).

[omniplex]

I don't know why the association wasn't properly done (but I would love to know).

Indeed, I just tested this some hours ago, and I got a working exr_auto_file association. It was presumably created by explorer, because I didn't start XnView with admin rights.

Oddly XnView 2.30 lists this extension twice on my box <topic mode="off">--it appears to be some kind of commercial format disguised as "open" with a notability factor below zilch--</topic> Maybe I have one add-on too much for this cruft.

Generally I emulate what XnView would do with assoc, ftype, and regedit, example:

Code: Select all

assoc .pam=XnView.pnm
assoc XnView.pnm=NetPBM formats pam, pbm, pgm, ppm, and pnm
ftype XnView.pnm="C:\program files (x86)\XnView\XnView.exe" "%1"

In regedit at HKLM\.pam I'd add PerceivedType=image and Content Type=image/x-pam (or whatever the last Wikipedia editor said, MIME types with proper IANA registry entries are rare.) I'd also add an empty XnView.bak, because this entry wasn't really added by XnView, and the best way to "undo" it would be to delete it. No old entry to restore, I kill everything with xxx_auto_file as garbage.

OTOH I'd carefully protect critical extensions (PNG, etc.), noting the last known good state as XnView.bak. Then I'd check if the MediaInfo extension supports the type, and add it as "shellex" (copy+paste of the cryptic CLSID number from another working file extension.)

For .exr I'll pick XnView.Image as type instead of exr_auto_file, that's for "all other business" wrt images. I have similar catch-all types for _archive (go to 7zip) and _media (go to MPC-HC). The underline sorts the catch-all types just below extension .zip before the real ftype names without dot.

And all XnView.this and XnView.that types are at the end of the list together with my homebrewn Xiph.this and Xiph.that types, because the original Xiph types turned out to be too fragile (Windows Media Player clobbered what it rightfully considered as its own entries for .oga, .ogg, .ogm, .ogv, .ogx, .spx, .flac, .opus, etc., and WebM also tried to muddy the Xiph.org waters without my consent.)

[franzb]

Got the exact same problem again with XnView 2.35 on a fresh Windows 10 installation. Same solution...

[omniplex]

I think I found and fixed the root cause of this issue with regedit. When explorer suggests to open a file extension with something it uses the HKCR\Applications, that is HKCR\Applications\XnView.exe\shell\open\command value (RegSZ) "C:\Program Files (x86)\XnView\xnview.exe" "%1", where the path depends on the installation, e.g., no " (x86)" on a 32-bits Windows.

For unknown reasons the "%1" was AWOL in my registry, i.e., XnView was started without a clue for which file or folder it was started.
REG-file suggestion:

Code: Select all

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Applications\xnview.exe\shell\open\command]
@="\"C:\\Program Files (x86)\\XnView\\xnview.exe\" \"%1\""

Update: Simpler solution suggested by Mixer three days ago in the XnView opens browser instead of image thread.