Home / SumatraPDF + Directory Opus Open With menu. Error

1.Install latest version of Directory Opus v12.6 on Windows 7 Ultimate:
https://www.gpsoft.com.au/DScripts/download.asp?file=Opus12/DOpusInstall.exe

2.Install latest version of SumatraPDF x64 and make it the default handler of .pdf files.

3.Install latest v9 of Foxit Reader and make it the default handler of .pdf files.

Installing Foxit Reader and making it the default handler of .pdf files is a must (maybe other pdf reader could be used too), otherwise there will be no error.

3.Using Directory Opus open any .pdf file using right mouse click context menu - Open With - SumatraPDF.

Note that if .pdf file is opened from SumatraPDF itself using File - Open… dialog no error is produced.

If .pdf file is opened using Windows Explorer context menu - Open With - SumatraPDF, no error is produced.

Error is only produced when the file is opened using Directory Opus context menu - Open With - SumatraPDF.

3.SumatraPDF displays this error:

I’ve tried googling for similar issues, the only closer cases I’ve found were these ones:

“error loading c:\windows\system32\1” on Terminal Server (archive.org)

https://resource.dopus.com/t/lister-viewer-pane/20075

How can we solve this issue?

Additional links to different, but maybe somehow related issues considering SumatraPDF and Directory Opus.

https://resource.dopus.com/t/sumatra-pdf-preview-window-grayed-out-on-multipage-files/26315

https://github.com/sumatrapdfreader/sumatrapdf/issues/803

When you say “latest version of Sumatra”, is it the latest release version 3.1.2 (from https://www.sumatrapdfreader.org/download-free-pdf-viewer.html) or latest pre-release version (from https://www.sumatrapdfreader.org/prerelease.html)?

It looks like Directory Opus invokes sumatra with just the file name instead of full path of the file and so if current directory sumatra uses doesn’t match the directory where the file is, we have this issue.

Latest stable SumatraPDF v3.1.2 x64.

Also checked SumatraPDF v3.2.10766 x64 pre-release.

Same error.

Directory Opus seems to invoke other pdf readers and editors successfully from open with context menu.

Why does Directory Opus have a specific mismatch with SumatraPDF?

Should I contact developers of Directory Opus?

I would agree this is an issue for GPSoft to resolve

Normally have no problems using context “open with” (prior to using DOpus)
Installed latest DoOpus on win7
I was able to get a similar error under similar conditions to above
DOpus seems to mess with windows default behaviour (there are way to many powerful options)
I was able to clear the error message in DOpus by going to settings file types then looking for PDF under system filetypes I was able to set
context menu >new Action to a copy of “drive:my path\SumatraPDF.exe” “%1”

that direct editing of DOpus “new action” ensured it behaved when using “open with”

Step 3. in the first post above doesn’t require installing any other pdf software. No change in default handler of .pdf files is needed. There simply needs to be more than 1 program to open .pdf files (other than SumatraPDF) in Directory Opus Open With menu. Add Notepad for example and try opening .pdf file using SumatraPDF. Error will be produced.

Edit Windows registry and make SumatraPDF the one and only handler of .pdf files, so there is no Directory Opus Open With menu, just the Directory Opus Open With… command and SumatraPDF will produce no errors.

I’ve tested Context menu - Open With - SumatraPDF behavior on stock Windows 7 Explorer and 3rd party explorer replacements (Total Commander, XYplorer, xplorer², Q-Dir, Directory Opus) and only Directory Opus produces the mentioned Context menu - Open With - SumatraPDF error. Therefore, one could say that it’s up to the developers of Directory Opus to fix this issue.

However, I’ve also tested Directory Opus Context menu - Open With - SumatraPDF alternatives behavior with Adobe Acrobat Reader DC, Adobe Reader XI, Foxit Reader, PDF XChange Editor, Nitro Pro and only SumatraPDF produces this error.

Moreover, on this type of error SumatraPDF always opens 3 tabs.

Let’s say C:\test.pdf is opened.

1. In the first tab the actual test.pdf file is opened successfully.

2. In the second tab *Error loading C:* is displayed

3. In the third tab Error loading C:\Windows\system32\test.pdf is displayed.

SumatraPDF opens .pdf file in one of the tabs successfully, therefore I assume Directory Opus invokes SumatraPDF with a full path of the file.

There is something unique between Directory Opus Open With menu (when there’s more programs than SumatraPDF alone) and SumatraPDF behavior.

@kjk Should I contact the developers of Directory Opus to address this issue?

It would be great if we could avoid that ping pong game scenario between developers where both sides see the ball being on the opposite court.

Thank you.

Hi,

@student13371 Have you found a solution to this problem yet?

I have exactly the same problem with Sumatra 3.1.2 64Bit and Directory Opus 12.

It is strange though that in Windows File Explorer it does not happen so I actually agree that it might be a Directory Opus issue. Nonetheless I have not found a solution yet.

Thanks in advance

@DrBones No, I haven’t found a solution for this problem.

It’s true that this problem is unique to the combination of Sumatra and Directory Opus.

I’ve tried various other PDF software with Directory Opus and had no problems. On the other hand, Sumatra worked just fine with other file explorers too.

Could you please report this issue to Directory Opus forum possibly giving a link to this thread?

Maybe the developers of Directory Opus could provide some insights on fixing this issue…

Are you using Win7 too? Can both of you use Task Manager, Process Explorer, Process Monitor etc. to see the full command-line i.e. exactly what parameters SumatraPDF.exe is being invoked with by Directory Opus?

While you’re at it, try opening PDFs in different locations and not just residing in C:. For example try other drives/dirs, try paths without spaces (i.e. no dir in the path to the file and the file name itself should contain spaces) and so on.

Finally, is Directory Opus being launched with admin rights, and in turn is it running Sumatra as admin too?

@DrBones

I no longer have Dopus installed and am not likely to reinstall due to other demands, however I thought I had solved clearing the error message as described above

sorry cant add anything more to that observation at the time

@SumatraPeter I’ve tested this issue on both Windows 7 (initially) and Windows 10 Enterprise 2016 LTSB (now).

Different drives (tried C and D) and spaces in paths or filenames don’t make any difference.

I have UAC disabled, therefore cannot say whether programs run with full admin rights or not.

Let’s say I’m using Directory Opus to open D:\a\b.pdf with right mouse button open with menu and choose one of these PDF tools: Sumatra, Foxit, Adobe reader, PDF Xchange.

Only Sumatra has an issue. Here are the full command lines for those programs:

“C:\Program Files\SumatraPDF\SumatraPDF.exe” “D:\a\b.pdf” D:\a b.pdf

The comand line above is clearly abnormal, because of D:\a b.pdf part

“C:\Program Files (x86)\Foxit Software\Foxit Reader\FoxitReader.exe” “D:\a\b.pdf”

“C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe” “D:\a\b.pdf”

“C:\Program Files\Tracker Software\PDF Editor\PDFXEdit.exe” “D:\a\b.pdf”

All these command lines are normal.

Once again, there is something unique in the combination of Sumatra and Directory Opus.

It’s very clear that DO is sending incorrect params to Sumatra. Now why only to Sumatra and not other PDF readers? That is obviously an answer that the DO devs have to give. Since this is such a long-standing issue, has it even been reported to them and if so, have they even bothered to respond?

P.S. Have any of you tried GitHubRulesOK’s workaround yet?

@SumatraPeter I haven’t tried @GitHubRulesOK method yet, but I have created a topic in Directory Opus forums with a summary of this issue:

Directory Opus forum topic

I hope Directory Opus developers will shed some light on it.

Here’s a reply from one of the developers of Directory Opus:

"I’d say this is the problem:

HKCR\SumatraPDF\shell\open\command: “” is REG_SZ:
““C:\Program Files\SumatraPDF\SumatraPDF.exe” “%1” %*”

HKCU\Software\Classes\SumatraPDF\shell\open\command: “” is REG_SZ:
““C:\Program Files\SumatraPDF\SumatraPDF.exe” “%1” %*”

HKLM\Software\Classes\SumatraPDF\shell\open\command: “” is REG_SZ:
"“C:\Program Files\SumatraPDF\SumatraPDF.exe” “%1” %"
The “%1” % on the end means:

“%1” – add the first selected file path in quotes, then…
%* – add all selected file paths (including the first path again).
I think that string in the registry should only have one of those, not both."

Will SumatraPDF address this issue?

Thank you.

I’m not the developer, however that syntax has been standard practice since the good old days of DOS (before SumatraPDF existed), As an example here is the standard windows 10 entry for passing a batch file to COMMAND

Untitled.png1040×265 14.8 KB

Here is the standard registry entry for passing parameters for any unspecified .exe (the same dual values are used for cscript and wscript etc. )

SumatraPDF (and many other apps that accept CLI calls need to follow that historic convention in order to work)

exe.png856×244 10.3 KB

I am unsure why there is a specific issue passing calls from DOpus (but not other commander / explorers) to SumatraPDF, however as DOpus is only feeding one file at a time via the context entry, in my solution I suggested that Directory Opus simply needs to be amended to match that requirement by supplying the first parameter and for this specific case ignore the secondary global catch all entry

set context menu >new Action to a copy of “drive:your path\SumatraPDF.exe” “%1”

NOTE both parts need to be wrapped in paired " s

Sorry for my late reply,

thank you @SumatraPeter and @GitHubRulesOK for your help! I am a little confuses though where the problem should be fixed. As I see it, SumatraPDF does not handle the “tried and true” command syntax well which causes it to choke. However, the Directory Opus developer regards the %* as not necessary and somehow all other PDF readers do not use that syntax.

Soooo…Who is setting the commands in the registry? And why is File Explorer using only "%1% while DOpus uses "%1" %* ? Can I just change those values?

Please forgive me for so many questions but I have tried GithubRulesOk’s workaround to no avail. Maybe I have done it wrong, it seems a little odd to just add a “New action” and then also the “Open With” is fixed but I gave it a shot

Just for confirmation, the context menu now looks like this:

Using this action works as expected and opens the selected PDFs but the “Open with” option is not changed.

I would very much prefer to not have an additional entry in my context menu. It is cluttered as it is

Cheers

P.S.: I am also on Windows 10 Pro

Addendum: I deleted the %* in the entry Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\SumatraPDF.exe\Shell\Open\Command and for now it seems to have done the trick…

Hopefully nothing breaks!

Adding Context Menu New Action as only
“C:\Program Files\SumatraPDF\SumatraPDF.exe” “%1”
was what I originally found worked in the past, glad to see it still seems to be the answer, so slightly confused when you say my workaround does not work?

I would avoid removing the %* in the main registry entry since that’s what SumatraPDF and other related explorer apps expect for command line usage, however if removing it works for you whilst only calling from Directory Opus then so be it.

Ah. Yes. I thought it was weird that that action should change the default “Open with …” menu . In that case, yes, your workaround does work!

Thank you for your advice regarding the registry, I am not fully comfortable messing with it. Since it works for now and it was a simple change, I will monitor if something else breaks and then maybe reverse it. I use SumatraPDF mainly when writing latex documents which is something I hope I will not be doing very much of after my thesis is done

Latex set-up usually uses a direct call to SumatraPDF so probably NOT affected by a registry change
it is more likely to upset a batch file used say for printing where multiple arguments are needed

UPDATE

following the DOpus thread above from @student13371 SumatraPDF + Directory Opus Open With menu. Error

Per Leo “Anyway, the Open With menu will work correctly with SumatraPDF in Opus 12.9.2 and later versions.” I thus encourage DOpus users to wait and test the next Opus Beta

Kudos to student13371 (Luthcase) and @DrBones for progressing this issue