Change text and icon for shell extension context menu item

Help & Support
1

I know that changing the icon and text shown in a context menu item for a specific file type can be changed in Windows File Explorer if that information is under a shell key for that file type ProgID in the Windows Registry, but it can't be done if a shell extension (DLL) is used instead for generating the context menu entry (which is set under a shellex key in the Registry for that file type ProgID).

What I would like to know is if Directory Opus can change the shell extension behavior and modify its generated context menu text and/or icon —or add one if no icon is shown— in the second case.

2

It depends how the shell extension works, or if the program has a command line interface that can run the same commands.

If the things you want appear in the contextmenu showcmds list, then it's easy to make a button which runs the same thing and can have the icon and label of your choice:

https://www.gpsoft.com.au/help/opus12/index.html#!Documents/ContextMenu_Command.htm

Failing that, if there's a command-line interface to the program then you can make a button which runs it via that, again with any icon or label.

3

OK, I've tried that and it appears on the list. When I copy the command I get this:
ContextMenu LABEL="Better File Rename 6..."

When you say

it's easy to make a button which runs the same thing and can have the icon and label of your choice.

Does it mean I can make a context menu item instead of a toolbar button, too?

4

It's up to you where you put the button. It can go on a toolbar, in a menu, in a context menu, or on a hotkey.

1 Like
5

Thank you, I did it and it's working even better than I intended at the beginning, as I've been able to place the context menu item in the exact position I wanted it to be but didn't think it was possible.

One more thing... Is it possible to disable/hide a context menu shell extension (the original one I've successfully replaced) in Directory Opus but keep it working in File Explorer?

6

If you turn on Preferences / Miscellaneous / Windows Integration / Hide Windows items on file context menus (shift overrides) it will be hidden, but so will all the other similar menu items.

This is what I do, since it removes all the extra junk and lets me add just the things I want, where I want them. But it's obviously more work, since you have to manually insert the things you do want to see all the time. (For me, that isn't many things, so it's worth it.)

If you do that, you can still access the hidden items that you need, but don't need often enough to add explicit menu items for, by holding Shift when you right-click.

7

I have been playing with that Preferences option but as I have quite a lot of shell extensions for different file types I think I will need some time to see if I can get the same context menu behavior I have right now.

Also, I have run into a problem with the context menu I created. After disabling the original context menu handler shell extension for File Explorer and Directory Opus by using the well-known ShellExView utility and restarting my computer —the same occurs if I just restart Directory Opus—, my custom context menu item stops working. Therefore, the original one has to be enabled and that means it appears duplicated in the context menu, which is not what I had in mind. Am I missing something?

8

The new command you made is just a shortcut to the original context menu item, so the menu item would need to still exist (but can be hidden in Opus) for it to continue working.

9

Ok, thanks. I've found the solution I was looking for here:

For anyone interested, now I don't block the shell extension context menu handler with ShellExView but add its CLSID to Directory Opus blacklist in Preferences - Miscellaneous - Advanced, in the ignore_context_menus setting. This way it still shows up in a Windows File Explorer context menu as before, but doesn't show up in its original form in a Directory Opus context menu, neither in a simple one nor in a extended one, but my custom context menu which uses a command to reference by label the original one works as intended. That's the exact behavior I wanted in the first place.