Hex Workshop shell extension opens for Edit verb

I have Breakpoint Software's Hex Workshop 6.8, and it comes with a context menu shell extension. In DOpus 12, when I click "Edit" in the context menu for any file for which it's defined, Hex Workshop is launched instead of running the associated "Edit" command.


  • The shell extension itself works normally.
  • This happens with any file type where the shell verb is "Edit" exactly. Other commands work fine.
  • The Edit command works normally outside of DOpus. E.g. in powershell:
Start-Process -Verb "Edit" somefile.txt
  • The issue did not appear in DOpus 11, but I haven't re-checked by downgrading.

So I can get around the issue by:

  1. Disabling the shell extension (I've gotten quite used to it though)
  2. Renaming the "Edit" command to something: "Edit_workaround_for_dopus"
    • Impractical as this would have to be done for all file types, and might break something

The bug is in the shell extension, not Opus. You can reproduce it outside of Opus with this simple code:

	se.cbSize = sizeof(se);
	se.lpFile = L"C:\\Path\\To\\Text\\File.txt";
	se.lpVerb = L"edit";
	se.nShow = SW_SHOWNORMAL;


Their context menu is adding a verb called "edit" to the menu, which is overriding the normal "edit" verb.

It only happens when SEE_MASK_INVOKEIDLIST is set, so maybe Explorer doesn't do that, or maybe Explorer is launching the action in another way, but the only reason (I know of) to add a verb in this way is so it can be run via SEE_MASK_INVOKEIDLIST, so either they are adding something that's never meant to be used or they're adding something that should not be added (at least with the name "edit").

Your ShellExecuteEx example did not reproduce the behavior. I gave it C:\\temp\\test.ahk, and it correctly opens the file in SciTE, not Hex Workshop, whether SEE_MASK_INVOKEIDLIST is set or not. Just in case I tested both edit and Edit, same result. Maybe the lpIDList parameter makes a difference? I'm not too familiar with the shell API.

I also confirmed that Opus 11.19 does not exhibit the bug. It's really only version 12 that does something different.

It may depend on the exact details of the file type.

I did it with a text file on a vanilla Windows 10 install where Notepad is the default editor.

Opus 11 didn't support this kind of context menu verb. We added support for a reason, although I don't remember what it was off the top of my head. Removing that support would break something else, and they shouldn't be touching the "edit" verb in the first place, unless their intention is to become the default editor.

Fair enough, the hex editor isn't updated anymore anyway. Disabling the extension and replacing it with a custom shell command seems to work ok.