Dynamic context menu items

Hi,

I love Dopus, but there's one thing that's been bugging me for a while -- you can't add dynamic context menu items for all files, when you hide the explorer context menu items. Perhaps I'd best give an example... :slight_smile:

Even though I know Dopus has great support for ZIPs and RARs, etc., I still prefer to use PowerArchiver / Winzip / WinRAR, especially because they have dynamic changing of the menu option based on what's selected. A whole bunch of files? have an "add to zip" option. Detected multiple archives (of different types)? "Extract here", or "to ". And so on, and so forth.

To use these, after have a fiddle around in the registry, I found that they have an entry which links it back to a particular DLL (for example, C:\Program Files\PowerArchiver\PASHLEXT.DLL for the PowerArchiver shell extensions).

Now, I know that they will work fine if I uncheck "hide standard windows context menu items" or whatever the option is, however doing this drives me nuts (with all the applications that add their own little options, and you can never remove them, etc...)

I'd accepted that as my loss for a while, however I noticed in the release notes for 8.0.1.0 that it said:

"Opus now supports third party shell column extension handlers (eg TortoiseCVS). Any columns added by third party handlers will be available through Folder Options as usual in the new 'Special' column category. "

I got all excited, and tried it, but for the life of me I can't figure out what it's talking about. Is this not possible at all, or have I just not found the right option?

Failing that, is it possible to do, and if not, how hard is it to implement? :wink:

Thanks!

Have a look at nudel.dsl.pipex.com/opus-context-tip.gif - it's a tip from Leo about how to customize the context menus in Opus.

These are column extension handlers, not context menu extension handlers. They let third-party programs add information columns to the details mode view of Opus (and Explorer). Nothing to do with context menus.

Cheers,
Jon

I also looked into your great tip-gif.

I saw that you use two apps, i use as well: PGP and TextPad.
However, in mine the first letter is underlined, in yours not. When i now add Trillian as well, both Trillan's and TextPad's T is underlined. How can that be managed / deleted?

The hotkeys are assigned directly by the context menu extensions involved, there is no way to change this (unless those third-party programs have an "Opus-level" of configuration, which seems unlikely :slight_smile:

Hi there temporary...

If you take a look Under the "Settings... -> File Types..." main menu entry you'll see a "File Types- Directory Opus" selection window popup. There are categories of data types shown in the window and clicking on them allows you to edit the context menu (and doubleclick behaviour as well) for the selected data/file type... Here's a sample of a configuration I'm trying out:

BEGIN
Directory Opus File Types

All files -> "Info Tip"

Filename: {name}.{ext}
Size: {sizeauto}
Attributes: {attr}
Type: {type}
Date Modified: {modified}

MD5 Checksum: {md5sum}

All files -> "Context Menu"

Open With... -> FileType OPENWITHMENU

All files and folders -> "Context Menu"

&Rename Files... -> Rename ADVANCED PRESET=Wildcard
&Path to Clipboard... -> Clipboard COPYNAMES=unc
&Filename to Clipboard... -> Clipboard COPYNAMES=nopaths
&MD5 Checksum to Clipboard... -> Clipboard COPYNAMES=hash2
WinZip -> FileType CONTEXTMENU {E0D79304-84BE-11CE-9641-444553540000} CONTEXTFORCE
&Send To... -> FileType SENDTOMENU
File Types... -> FileType EDIT
Show Commands for this file type... -> ContextMenu SHOWCMDS

All folders -> "Context Menu"

Open to a &Command Prompt -> CLI DOSPROMPT=selfolder

File Type Groups

NEW Source Code files -> "Events"

dblclck -> "C:\Program Files\UltraEdit\uedit32.exe" "%1"

System File Types

WinRar archive -> "Drop Menu"

WinRar: E&xtraxt here dialog... -> ContextMenu ID 103
WinRar: Extract to folder... -> ContextMenu ID 104

WinZip File -> "Drop Menu"

WinZip -> FileType CONTEXTMENU {E0D79304-84BE-11CE-9641-444553540000} CONTEXTFORCE
END

The WinZip Drop menu behaves a little funky though... when I right click and then drag and drop a zip file onto a folder in the folder tree, the WinZip context menu pops up and I can select to "Extract to here" but the zip file gets extracted to the same folder the zip file is in... weird. For WinRar handling of .RAR files it's a little clunky also. The Drop menu doesn't display as refined as the raw explorer shell handler... with the full path of the destination folder shown in the menu. Guess because it uses the raw ContextMenu command instead of the FileType command to invoke WinZips actual shell menu via it's CSLID/GUID number.

-steje

[quote]
jon wrote:
The hotkeys are assigned directly by the context menu extensions involved, there is no way to change this (unless those third-party programs have an "Opus-level" of configuration, which seems unlikely :slight_smile:[/quote]

Actually, in the name of the the context menu entry you add, if you add the & symbol before the letter you would like to make the 'hotkey' for this action, this will do the trick. At least for internal Dopus commands or command ID/VERB invocations using the raw ContextMenu command. This is instead of hooking the shell extension provided by the app (Trillian etc.) based on it's CLSID/GUID value. In that case you can't control the underline/hotkey. But maybe there's a way you can run a ContextMenu ID/VERB command instead of hooking the shell extension...

QUESTION: The tell tale sign you're hooking an app shell extension (or windows native extensions) is that there is a context 'sub'menu... like for WinZip and Send To. Might Dopus provide a way for users to define their own sub-menu's? That would be great...

Well, i played around with my file settings a little bit now and i'm very satiesfied with the result.

However, when i study Jon's gif, i see that i can' t get rid of some context menu items for folders. Please take a look here.

And how can i implement "sort by", "undo" and icons left to the menu items?

Regards,
Ralph

Hey, that's great!

Sorry about the late reply -- I've been in recovery mode from New Year's Eve. :wink: But that worked great -- thanks for your help!

Now, the only other thing to fix is that damn refreshing problem... :wink:

Thanks for everyone's help!

[quote]ralph76 wrote:
i can' t get rid of some context menu items for folders. Please take a look here.[/quote]
Those items are likely the "verbs" on the "Actions" part of the filetype. You can edit these by clicking the first tab in the filetype editor (called Actions in the English version, two to the left of the Context Menu tab).

[quote]ralph76 wrote:
And how can i implement "sort by", "undo" and icons left to the menu items?[/quote]
You can add any Opus commands to the filetype context menus if you want, even those which don't actually act on right-clicked files, such as changing the lister's sort order or invoking the undo command.

The command for a sort-by list is:

Set SORTBY=sortlist

And Undo is simply:

Undo

The only trick to adding these commands to FileType context menus is you have to remember to change the "Type" dropdown from "Run an application" to "Run an Opus function".

By the way, it's easier when editing the other context-menus (e.g. the one you get if you right-click an empty space, or the status bar, in a lister) since you can drop pre-defined Opus commands onto the menus. You can't do that in the filetype menu editor (which isn't surprising as it's unusual to want to) so you have to work out which commands to run, but all the commands are still available and seem to work fine.

Finally, you can't specify icons for filetype context menu items at the moment. (You can specify them in the other context menus, though.)

Hey there Nudel,

Can you possibly say why adding a Context Menu action of type "Run an application (supported in Opus and Explorer)" seems not to be available when I've disabled the Windows context menu items? It sure enough shows up when I do a Shift-right click... For instance, I'd like to have a context menu entry for ISO file types that let me mount them with Daemon-Tools. If I add the proper command line to one of the Action tab actions... like the "open" action, it works but why won't it work as a Context Menu tab action entry?

Also, the Dopus Context Menu seems not to work at all on Drives and other root level elements in the folder tree like My Computer or My Documents. Again, entries to the Action tab are visible, but unlike the problem above, even Shift-right clicking on a drive or other folder tree item does not show Context Menu entries. I'd love to be able to add a "Dismount Daemon-Tools virtual drive" context item just for the drives... this also does not work for drives in the File Lister pane if you've got My Computer selected in the folder tree.

thanks in advance,
-steje

[quote]steje wrote:
Can you possibly say why adding a Context Menu action of type "Run an application (supported in Opus and Explorer)" seems not to be available when I've disabled the Windows context menu items? It sure enough shows up when I do a Shift-right click...[/quote]
If you mean a FileType CONTEXTMENU=xxx command, you have to add the CONTEXTFORCE argument (like in my example GIF) to force them to appear without holding shift. But this is only if you've checked the option in Preferences, Miscellaneous, Windows Integration: Hide Windows items on file context menus (shift overrides).

If you haven't turned on that option, or the command you're adding is a normal one which just runs an Opus command or some other executable, instead of some variant of the FileType command, then I don't know why it isn't appearing.

Can you tell us what the entry is? That might shed some light on it.

For DT I use one of the 3rd party programs ("awxDTools") which adds a context menu but I actually don't want to see its menu items most of the time so I leave it hidden unless I press shift. I haven't tried to make it always visible but equally don't know of any problems if you do.

Not sure what happens when you right-click on the tree itself, but if you're showing My Comptuer etc. in a lister and right-click one of the items (in the file display area) then that menu is drawn by Explorer and not Opus, since Explorer provides the views like My Computer, even inside Opus listers.

Hi again Nudel and thanks for the response!

Well, some interesting developments... Firstly, I do indeed have the Hide Windows items on file context menus option selected so that I can control the context menus to my liking. Secondly, the actual command I'd wanted to invoke as my Context Menu action for .ISO files was "C:\Program Files\D-Tools\Daemon.exe -mount 0,"%1"". Lastly, I understand what you're saying about certain things still being rendered by Explorer - even in Dopus listers... and in the course of messing around a little bit to make sure some of what I was originally going to write in my reply to you was accurate, I've stumbled on some observations...

First, I know what you mean about using the CONTEXTFORCE argument for Context Menu actions of the type Run an Opus function (not supported in Explorer). It certainly allows things such as the WinZip shell extension handler to appear by invoking it with a FileType CONTEXTMENU {E0D79304-84BE-11CE-9641-444553540000} CONTEXTFORCE command. Though there are some quirks with it's behavior when using this on the Drop Menu :slight_smile: (more on that later, and let me know if it should be a seperate thread or post). But what I was originally describing that didn't work was adding a new Context Menu action specifically of type Run an application (supported in Opus and Explorer) where you can't use the CONTEXTFORCE argument because you're not selecting an Opus function but rather like you said, an executable. And this does not seem to work... on at least not on specific System File Types items such as .ISO files (more on that too... relating to the folder tree items).

In any event... like you, I also like the awxDTools extensions. The only reason I wanted to add a Run an application... call to daemon.exe was because I hadn't found any CSLID/GUID type footprint in the registry for awxDTools in order to invoke it with a FileType Opus function call. But while messing around in the registry to verify some comments I was going to make to you about Explorer still handling certain folder tree items in Dopus listers... lo and behold I found the awxDTools shell extension GUID in the HKEY_CLASSES_ROOT\Drive keys shellex\ContextMenuHandlers\awxDTShlExt sub key. And sure enough if I invoke it with a FileType CONTEXTMENU {70B28949-EC23-4D00-A411-AD8A1B3A8A5A} CONTEXTFORCE call, it works fine! So yahoo... it gets around not being able to call the executable directly and I prefer this anyway!

But this still leaves the now less important question of why you can't seem to use an action specifically of type Run an application (supported in Opus and Explorer) in the Context Menu of Directory Opus File Types items as well as SOME items in the System File Types category. Incidentally, I said SOME because such action types DO work on items in the folder tree... for instance the 'Drive' System File Type. My original question regarding Context Menu actions that were NOT working on the folder tree items was based on trying to use Run an Opus function... type commands like CLI DOSPROMPT. What I noticed while messing around with the System File Types -> 'Drive' Type Context Menu is that the Run an application... type actions which DO work for the folder tree items wind up in the HKCR\Drive\shell registry key... as do entries you add to the 'Drive' Type Action tab...

So it seems from the first part of your reply to me:

you're not sure why such actions aren't appearing... and that's mostly not a BIG deal now that I found the awxDTools shell extension ID.

However, one last question I have for now is... and I'm not sure if I should ask this in a new post or not but; can aynone say why calling the WinZip shell extension in the Drop Menu of a System File Types WinZip File seems to behave funky? Specifically, if I right click on and drop a zip file over another folder and select the WinZip option to Extract to folder x:\selected folder\zip filename it extracts the archive to a folder named after the zip file... but NOT in the folder I've dropped onto... instead it extracts it to the zip files current folder. If you do a SHIFT right click and drop, you will see both Winzip's native Explorer shell menu, AND the one you've invoked in Dopus with the FileType function... and sure enough the Dopus invoked menu doesn't even show the drop target folder as part of the path it's saying it will extract the file to. Weird...

-steje

Well, figured out the issue with the strange behaviour of the WinZip shell extensions (and for that matter WinRAR as well) on the drop menu...

Seems that some applications have many (or at least several) shell extension handlers and you have to pick just the right one. If the one you pick to use in a Dopus FileType Context or Drop Menu command seems to be the right one because it looks mostly like what you want but doesn't function exactly as you'd expect, keep digging for another CLSID context handler ID, you might be able to find the right one.

In the case of WinZip and WinRAR "Drop Handlers" the full commands with the proper CLSID value that let the extensions use the correct folder drop target in the extraction paths are:

WinRAR archive -> "Drop Menu"

WinRAR -> FileType CONTEXTMENU {B41DB860-8EE4-11D2-9906-E49FADC173CA} CONTEXTFORCE

WinZip File -> "Drop Menu"

WinZip -> FileType CONTEXTMENU {E0D79305-84BE-11CE-9641-444553540000} CONTEXTFORCE

If you're comfortable with the registry, the following keys are likely places to look for application extensions that have been installed.

HKCR*
HKCR\AllFilesystemObjects
HKCR\Directory
HKCR\Drive
HKCR\Folder
HKLM\SOFTWARE\Classes\

It goes without saying that you should be careful if you're going to play around inside these keys as Dopus relies on a properly functioning operating system as much as any complicated application... :slight_smile:; though I've been able to clean out certain unwanted things to no ill effect, particularly from the HKCR\Drive key to eliminate some unwanted context items that Dopus can't directly control because as Nudel has stated some context items are still handled by Explorer... such as context items that appear when you right click on Drive letters and other Virtual Folders or Shell Namespace items in the Folder Tree...