Directory Opus Open With menu + SumatraPDF. Error

This issue was first discussed in SumatraPDF forums until conclusion that the developers of Directory Opus should be contacted regarding this problem.

Link to the original thread:
SumatraPDF forums

How to reproduce the problem:

1.Install Directory Opus on Windows 7 or Windows 10

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

  1. There must be at least 2 programs associated to open .pdf files in Directory Opus Open With menu. To accomplish that, for example, add Notepad to open with menu for .pdf files

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

SumatraPDF displays this error:

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.

  1. I’ve used Process Explorer to see the full command-line i.e. exactly what parameters SumatraPDF.exe is being invoked with by Directory Opus Open with menu.

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.

  1. 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.

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

Why does this particular combination of Directory Opus open with menu and SumatraPDF cause problems?

Thank you.

On a machine where this problem occurs, please do this and attach the zip file it generates:

  • Settings > File Types
  • File > Diagnostic (i.e. the File menu at the top-left of the File Types dialog)
  • Enter PDF as the extension and click OK.

Here you go, Sir!

Opus_FTD_File_PDF.zip (35.3 KB)

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.

Thank you @Luthcase and @Leo for taking on this problem.

I have the exact same issue and albeit not a major dealbreaker, it is slightly annoying. I would like to understand how this works exactly. What does DOpus do when using the "Open with ..." entry? Since I cannot edit that behaviour from within DOpus it must be a Windows thing. Then again, I am confused why SumatraPDF writes those commands to the registry although it does not understand that syntax AND File Explorer uses the exact same registry entry as DOpus but produces somehow different results.

Do I see it correctly that it could be fixed by a simply registry change?

Thanks in advance

We have a fix/workaround for this coming in the next update.

I'm not sure why the %* is there in the registry, but Explorer seems to completely throw it away (as does Opus in places, and most other software, when they run the command via the shell). With the Open With menu, Opus runs the command itself, and supports using %* to add extra information which apparently is only added in some situations and blank in others.

All of this is not really documented by Microsoft, unfortunately.

We aim to be compatible with Explorer where possible, so we will do the same thing and throw away the %* part, as if it was not in the registry at all (except in the cases where we know the %* needs to do something extra, where Open With menu items aren't included).

It'd be interesting to know why the %* is there in the registry and in which situations it's meant to do something extra, to fully understand how it's being used. Unless it was just copied from some other registry entries as "the way to do things" and is always meant to do nothing.

Anyway, the Open With menu will work correctly with SumatraPDF in Opus 12.9.2 and later versions.

@Leo
Thanks for your understanding,
I am not the developer but would like to point out that %* is not just for files
SumatraPDF (along with DDE) can allow complex command line parameters of thousands of characters if necessary for foward/reverse search, printing variables and multiple settings, dropping a whole folder or hundreds of files etc. (up to %255)

Most Directory Opus users will probably only need to pass a single file at a time to be opened, however you may need to allow for some other customisation of the command to allow for secondary parameters

Is the way that works documented anywhere? I couldn't find the exact details anywhere.

As far as I can tell, there isn't any situation where the extra non-filepath parameters would be used if Opus is launching the program, and there's no way to specify what they should even be.

SumatraPDF is open source, and as im not a programmer it would take me some time to try and ferret out the relavent lines of code.

In short most of the commands are here https://www.sumatrapdfreader.org/docs/Command-line-arguments.html . There are two significant ones undocumented, one is related to portable use (-appdata) and the other to text extraction (-extract-text 1 $file)

The Sumatra side is normal and no mystery, but there's no way I can see that anything that runs it using the %* string from the registry will know those command line arguments or when to insert which ones at the end of the command. That's the part which makes no sense to me.

I cannot think of any situation where the %* could actually be used, because anything using it would have to know about Sumatra explicitly, and anything that knows about it and wants to pass special options to it can generate a command line by itself, without needing a template with things like %* telling it to put the arguments after the filepath.

I frequently compose .BATch or .ComManD files that pass those CLI strings however have never had cause to question what happens to %10 onwards
Many third party Latex editors can call SumatraPDF via a block of direct DDE calls or be configured to run / start / call the CLI, however I guess most of those would not exceed %9 at a time.
As you observe SumatraPDF accepts a single filename "%1" OR breaks down the long %* chain into constituent parts, possibly ignoring a doubled entry, you would need to query the developer to find out why they used the archaic double format (however I think from their side may be if it worked, ...)

The registry template for Open With won't be used by anything running the program via .bat or DDE. The %x stuff is specific to how software like File Explorer and Opus build command-lines for programs they know nothing else about using only the information in the registry. It's not really tied to the way Sumatra or anything else parses command-line arguments; just a way to build a command line. Sumatra might be able to take more than 10 arguments even if you can only go up to %9 using the registry-style codes.

As far as I can tell, there's no situation where the %* in the Open With registry data would/could ever be used, but maybe I'm missing something.

If something is running Sumatra from a .bat file, it can just put whatever arguments it wants on to the command line and would not be using the template in the registry.

DDE commands are placed in the registry, but they usually hardcode any special arguments, without using templates/placeholders like %*, except for using %1 for the filepath. That's the only documented convention I can find, and the other %2 - %9 and %* codes always turn into nothing when running a test command via Explorer.

In this case I don't think DDE is being used so I don't think it's that anyway.

Basically, %* means "insert all the extra arguments", but there's nothing anywhere to say what those extra arguments should be, and I am not sure there ever are or could be any extra arguments. It's still a mystery to me what the %* is there for.

We have seen some of Explorer's private/undocumented toolbar/menu commands using %*, and the meaning seems to be decided by some assumed convention between Explorer and the thing it is running, which are both part of the shell. I could not find any documentation on it, and Explorer only adds anything where %* is specified when running certain things in a particular way; in all other situations I tried, it ends up being blank.

Maybe it used to be documented but no longer is.

Thank you @Leo for the fix in the new version, I am looking forward to it, so I can remove my registry hack. Also it's really informative to read your's and @githubrulesok discussion. Although I cannot really participate, I find it intriguing to read abut the -- mysterious -- inner workings of Windows. Thanks :).

Kinda happy I supported the right developer!