I just realized that in Opus, there's two context menu entries missing that I have in Explorer. One of them is some Adobe thingy that I have never used and don't even know what it does, so no big loss. The other one is the entry for Batch Rename Pro (http://www.foryoursoft.com/batchrename/index.htm), which I happen to like a lot, despite the rename functionality built into Opus.
First of all, I wonder why this entry is not in Opus' menu in the first place. It's a regular 64-bit shell extension, although, a bit unusually, it's installed in the Program Files (x86) folder. As I understand it, the renamer itself is 32-bit, but they provide a 64-bit DLL so that it works in 64-bit Windows, too. That 64-bit DLL is in the same folder as the renamer.
So, is there a way for me to add that context menu entry to Opus' menu as well? Maybe even including the cure icon that comes with it?
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.
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?
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...?
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.
