Is Preferences / Miscellaneous / Windows Integration / Hide Windows items on file context menus (shift overrides) turned on?
And does it show up if you "Shift + Right Click" instead of a simple Right Click?
No. I should have said, I have a fairly massive context menu, with typically more than a dozen entries, quite a few of them from third-party shell extensions. All of them show up in Opus as well, with the exception of the two I mentioned. I don't understand what is different about these.
Do you have anything set for Preferences / Miscellaneous / Advanced / ignore_context_menus ?
No, nothing at all. Like I said, all of my other shell extensions show up. If I'm asking myself what is different about the two that do not show up, the only commonality that I can see at this point is that in both cases the DLLs reside in the 32-bit program folders tree, C:\Program Files (x86), rather than in the 64-bit tree, even though they are, of course, 64-bit extensions. Could it be that there is some logic in Opus that would discount the extensions based on that fact?
Try the debugging steps in Crash, exit or high CPU when right-clicking certain files and see if the context menu is even being queried.
Hmm, interesting. I can see the line
  dopus: (BatchRenameShell Class)
in the output, and no error messages, but the context menu item from Batch Rename isn't there. What does that tell us?
It suggests the shell extension isn't adding any items to the context menu.
Alright, wonderful. Can we figure out why not? If I right-click on the exact same file in Windows Explorer, I'll get a context menu entry.
Nah... PowerArchiver works the same way, installing itself to the x86 folder but providing a 64-bit extension that acts as a stub since I presume the rest of the program exe's are 32-bit.
I downloaded the Free version - but after installing it, found that it doesn't come with shell extensions at all. Installed the Pro version... found the context menu, but sure enough it doesn't show in Opus though it's ok in explorer.
FWIW: in my diff program (Araxis Merge), there is an "Explorer" context menu item when clicking on a file or folder from within it's folder comparison UI. That menu item functions a bit like Opus' "windowsonly" filetype contextmenu command, and allows you to access the normal Windows Explorer context menu for items you right click in the merge UI. It is also a 64-bit app (like Opus) and doesn't show the BatchRename Pro context menu either. I suppose it's possible that both Opus and Araxis could be doing something ~wrong, but BatchRename could also be either returning something neither of the other two apps consider to be valid - or maybe suppressing it's menu items for anything calling it other than Explorer...?
Ask the people who wrote Batch Rename Pro
Forgot to suggest... that it's worth while to contact the BatchRename support and dev folks as well. Perhaps they can easily confirm if they only render their menu items for Explorer or something similar.
O.k., that's probably the thing to do, if I decide this is important enough for me. I should say, before I do that I'll take a closer look at Opus' own interface for file renaming. I may well decide that this fits my bill perfectly well. If I need any more than that, I can simply make a toolbar button that opens Batch Rename. I'll have to copy/paste filenames into it manually, but that's a minor inconvenience really.
Oh yes, I agree. Just to be clear, I never meant to imply that the missing context menu is Opus' fault. I am, in fact, convinced that it's a lot more likely that Batch Rename is at fault. Well, if there is any "fault" here at all.
Yes, see above. Thanks very much for your feedback. Reading about your similar experiences to mine has been valuable!
I tried the pro version and one thing I noticed is that it's adding an owner-draw menu item to the context menu. That causes Explorer to fall-back on the old/ugly menu-drawing code. (The easiest thing to see is the way selected items look in any menu which BatchRename has added its item to, compared to menus without it.)
That doesn't explain why the menu item isn't appearing in Opus (owner-draw menu items should work in Opus), but it does indicate that BatchRename is adding its items in an unusual way. (I'm not saying it's doing anything wrong, though. It's hard to tell what's going wrong or where.)
Since the debug output indicates that Opus is definitely loading the BatchRename shell extension, and calling its methods doesn't seem to be resulting in any menu items coming out, this will probably be easiest to debug on the BatchRename side, at least initially. Maybe something Opus does (or doesn't do) differently to Explorer is confusing the code on that side. If so, it should be really easy to tell if you have the source to BatchRename but quite difficult if you don't. If a difference is identified then we might be able to change Opus to resolve it (depending on what it is exactly).
BTW, I don't think the shell extension is checking the process name and only showing its items in Explorer.exe or anything like that (some extensions do that), since its menus also appear when you right-click in the File Open dialogs in Notepad etc. So we can probably rule that out.
thanks very much for this detailed response! I had never noticed that the appearance of Explorer's menus had been changed through the addition of the BatchRename entry, but I just tried it (disabled the context menu entry), and you're right! I have by now decided that I am not going to need BatchRename anymore and switch entirely to Opus for its functionality, so that renders that issue moot, for me.
In other news, and for what it's worth, last night I was troubleshooting a much more serious context-menu issue, where right-clicks on image files in a thumbnails view caused Opus to crash. I tracked that one down to the CFi ShellToys context menu item (more specifically to the Image Size item in ShellToys' submenu). I thought I'd mention this just in case somebody else runs into this problem. ShellToy's allows you to individually remove its menu entries, and removing just the one I mentioned solves the problem. Needless to say, that particular entry is wildly redundant anyway...
Thanks for the pointer about CFi ShellToys and the Image Resize menu.
I looked at that today and it turned out to be a bug on the Opus side. I've fixed the bug and the fix will be part of the next Opus update (10.0.3.3-beta or 10.0.4.0-stable).
I've also emailed CFi to let them know, in case they get any support queries about it, since it's not their fault.
(As a temporary workaround, if you configure Opus to use "Office 2003 style toolbars" then things will work, since that happens to avoid the code-path with the bug in it. We should have a fixed version out soon, though. Of course, it's also easy enough to just avoid opening the menu in question, since it only seems to affect that particular sub-sub-menu. So hopefully this isn't causing anyone too many problems, but it'll be fixed soon either way.)
The same bug may affect other shell extensions which add owner-draw menus, but it doesn't seem to be the reason that the BatchRename items are missing. I'll look at that a bit more since I'm in that part of the code anyway. (Update: I've looked into BatchRename quite extensively now but I can't find where things go wrong. Everything succeeds and looks normal, except that it doesn't add any menu items. I've written to the developers to ask if they have any ideas.)
thanks for looking into this again. Like I said, I have removed that ShellToys context menu, so the problem for me is gone either way. However, since you mention that scenario as a possible work-around, when I had the problem with those context-menu crashes, I did have "Office 2003 style toolbars" enabled. In any case, once the bug is fixed it shouldn't matter either way. Plus, now that I have a better understanding of what Opus' built-in renamer can do, I really don't need BatchRename anymore.
Did you have Prefs / Advanced: no_contextmenu_fix = True, by any chance? (It's False by default, but if set to True then the Office-style toolbars could still crash with owner-draw menu items, FWIW.)
No, it was set to "False". It's possible that in my case there was an interaction with other context menu entries that caused the crash. For example, I have a context menu entry from XnView, which also queries images in some way. Who knows, the possibilities are near-endless.
Update on Batch Rename Pro: I emailed the developer and they took a look at things on their side. It turns out Opus isn't setting a flag which they look for, so we'll fix that in an Opus update.
(It's debatable if they should be checking the flag at all, but there doesn't seem to be any downside in setting it, so we might as well.)