GP SoftwareTwitter
Opus FAQsManualCommandsObjects

Context menus in Windows and DOpus not always the same

I've been looking at trimming my RCM Context menus in a systematic and orderly fashion (please, don't laugh or choke as you read this). It's taken me a while to work out the order of assemblage for files and for folders. I used Windows to do my analysis. When I cross checked with DOpus I found that DOpus uses a different ordering for files.

The components for files are shell and shellex items for: the particular extensions (eg .EXE), All Files (registry entry '*') and All File System Objects. The Windows's order of the commands in the right click mouse menu is bewildering but it is even more bewildering to have DOpus use a different order. I threw up my hands when I saw the EXE shellex items followed the shell items. It may make more sense but I need to a proper (formal) description of what is happening in DOpus before this exercise does my brain in. :slight_smile:

Can you explain the order DOpus puts the varies parts in for files and for folders, please.

I also note that DOpus has different terminology for, what in the registry is, All Files (*), All File System Objects and Folders. Also, DOpus doesn't have an equivalent for Directory (probably a good thing) but how does it handle it - is it included in Folder?

Thanks for any help you can provide.

The orders in the two programs may be different, yes. I don't think the order Opus uses has been documented anywhere (not sure about Explorer).

Context menus with a lot of items are going to be a mess whatever order the items are added, so removing unwanted or rarely used items, or moving them into a submenu, is the best way to tidy things up.

The linked post covers things you can do to only affect Opus. If you want to remove some items system-wide, and the programs adding them don't provide an option to do so, you can use ShellExView for shell extensions and the file type editor (or regedit if preferred, but be careful. of course).

Thanks, Leo. That makes it worse than I can imagine. :slight_smile: Okay, I'll see what I can deduce. I've got a pretty good idea about Windows now. I thought it would be easier getting documentation from GPSoft, maybe it's a case of 'nobody knows'. :slight_smile: That would explain everything. :slight_smile:

Hi Leo,

I've been doing some work on my RCM context menus. I looked at using 'menus' as described in 'Removing unwanted or rarely used items, or moving them into a submenu' ([Tip: Organise and Speed-Up Context Menus)). Unfortunately that technique does not carry through to Win-Explorer. I've been working with cascading menus in Win Explorer. I want the menus to be as similar as possible in Win Explorer and DOpus. The approach I'm taking is that if I get get close to what I want in Win-Explorer, I should be fairly close in DOpus too.

I've got some cascading menus working in Win-Explorer but there is an error when I use them in Dopus. The error message is, 'Parameter Incorrect'.


I'm right-mouse clicking on a folder named '010-Editor (SweetScape)'. The error message indicates that the parameter error relates to the 'folder 010-Editor (SweetScape)'.

Here's what the RCM Menu looks like:


The graphic has had superfluous information blurred and the arrows added to indicate the click path.

The menu is constructed in the registry as follows:


Again superfluous information has been blurred and the registry path indicated by highlighting. This is a work in progress and so the registry is littered with backups and experimental names.

The definition of the Unlock command is:


And the definition of its Command key is:


Unlocker (by Cedrick Collomb) works when it is not in the cascading menu. That is, when it is at the first level in the shell key.

I get the same error message (parameter error) when I select the other commands from the cascading menu and they all work when they are not in the menu but at the first level under shell.

The error message suggests that DOPUS is not seeing the Unlocker command ("E:\Program Files\Unlocker (Cedrick Collomb)\Unlocker.exe" "%1") or its "%1" parameter correctly.

Clearly, DOpus understands the cascading menu structure because it displays it, it's just the actual command that is not getting through.

These are the instructions on creating Cascading Context Menus using the registry.

https://msdn.microsoft.com/en-us/library/windows/desktop/hh127424(v=vs.85).aspx

Which of the three methods described are you using? Does what you've done match the instructions?

Hi Leo,

I was aware of the article you referred me to but I'd discounted it as useless. The first method does not describe cascading menus, only first level menus. The second method defies understanding, or did, and the third must be a programming interface as I have no idea what 'IExplorerCommand' (it's not a registry key name).

But all was not last. I felt obliged to revisit this article before answering your last question, 'Does what you've done match the instructions?' I reviewed Method 1 but it is a single level of menus, not cascading.

I minutely followed the instructions in Method 2 but they don't even work in Win-Explorer let alone DOpus. BUT I've unravelled it, thanks to your challenge, Leo. The short answer, Leo, is the method I am using IS Method 2 (but you'd be forgiven for not recognizing it just as I haven't). The exposé of Method 2 is at the bottom of this message for later, optional reading.

I've also implemented a cascading menu using Method 1 (it needed information from elsewhere). I can now say with great confidence that while DOpus can display one level menus, it CANNOT push out the second level. While I had thought DOpus was not getting the path of the object (clicked on) I now think DOpus just can't handle the definition of the second level. I'm now calling it a bug.

Leo, should I construct a cascading menu that I can export from my registry to send you? This will work in Win-Explorer but not in DOpus. That way you can try it for yourself.

If, however, someone at GPSoft or on the forum has successfully implemented a multilevel menu (greater than one) that works successfully in DOpus, then it is back to the drawing board for me.

The way to understand the MSDN article, 'Creating Static Cascading Menus ,
The problems with the article, 'Creating Static Cascading Menus' (https://msdn.microsoft.com/en-us/library/windows/desktop/hh127424%28v=vs.85%29.aspx) is that it is full of conceptual errors. Yes, I know it is on the MSDN website, which implies authoritative, but it is wrong. Comments from other users criticise it only as badly written and none of the alternatives proposed by users seem to work. Here's what is wrong.

The first method is entitled, 'How to Create Cascading Menus with the SubCommands Registry Entry'. Change SubCommands to 'CommandStore' and then there's a basis for understanding, maybe not straightaway, but it will correctly distingush it from Method 2. What's described is a single level menu but with the assistance of a graphic in article, 'How to Customize “Organize” and “Layout” Menus in Command Bar in Windows 7 Explorer' (http://www.askvg.com/how-to-customize-organize-and-layout-menus-in-command-bar-in-windows-vista-and-7-explorer/), one can work out how to make multi-level menus in CommandStore.

The second method is entitled, 'How to Create Cascading Menus with the ExtendedSubCommandsKey Registry Entry' (https://msdn.microsoft.com/en-us/library/windows/desktop/hh127431%28v=vs.85%29.aspx). The article is based on a lie, a mis-truth. There is no such key called a 'ExtendedSubCommandsKey'. The title of the article should have been:

In this context, the word 'extended' means repeating, reaching out.

The writer, or the editor have read 'Extended SubCommands Key' as an actual key when it is not. It's the wrong name and it is NOT a key. It is a value and its name is SubCommands. The code in the article is a fantasy too. This is what it should look like:

HKEY_CLASSES_ROOT/ txtile/ Shell/ Test Cascade Menu 2/ (Default) = null MUIVerb = Menu SubCommands = null Shell/ cmd1/ MUIVerb = Notepad command/ (Default) = %SystemRoot%\system32\notepad.exe %1 cmd2/ MUIVerb = Wordpad command/ (Default) = C:\Program Files\Windows NT\Accessories\wordpad.exe %1

Note I've added / after key names to distinguish them from values. Also note, 'SubCommands' is a value NOT a key. This example shows only a one level menu but it can be extended to make multiple-level menus.

Where/what are the instructions for the method that you are/were using originally?

Hi Leo,

The information I got from this forum thread: http://www.wilderssecurity.com/threads/windows-7-cascading-menus.314115/. In message #4, the contributor Sully provides annotated code to generate a cascading menu. It's by no means immediately apparent but this is Method 2 in the MSDN article. You have to do the metal transformation of 'ExtendedSubCommandsKey' key to SubCommand value to see the equivalence. It was only this morning that I saw the similarity and concluded that my implementation, based on Sully's code, is in fact Method 2 (if only it had been written up accurately).

I can envision a scenario where a programmer, over coffee one morning, sketched up the method of doing cascading menus on the back of an envelope. After it is implemented, that envelope is still the only documentation. The programmer leaves and another member of staff is given the job of doing documentation. The new programmer doesn't understand the process but uses the envelope to complete the job. Pure speculation but it would describe the MSDN article pretty well.

Hi Leo,

I've constructed a variety of cascading menus that can be used to compare the results in DOpus and Win-Explorer. If you think they could help, I can send send them as .reg files.

Hi Leo,

Is there an update on the progress of this issue? It's nearly two weeks since I raised it.

It seems to me that DOpus understands the SubCommands value when it contains data but does not know what to do when the value is empty.

I'll reply when there is an update. We've been busy with other work and haven't got to looking at this properly yet.

Thanks, that's fine. I don't think it will be a trivial issue. I can continue my work, an investigation of context menus, without an answer, just as long as I know it hasn't been lost. I will need an answer eventually but it's not top priority.

I've uncovered some other anomalies which I'll record in other threads.

We've investigated this now and found we only support single-level sub-menus when defined via the registry in this way.

Recursively nested menus defined via these registry methods are not supported and won't work in Opus.

You're right, Microsoft's documentation is terrible/wrong for the nested menus. I had to use debugging tools to work out what Explorer was even looking for. The docs for single-level menus are OK, although missing some information (you don't have to create CommandStore verbs at all; the commands can go directly below, and Opus support both ways of doing things in the single-level case).

Adding support for the nested menus would require a major refactoring of the code, which we are unlikely to do at this time. It's a Windows feature that is basically undocumented and (unsurprisingly) almost never used to our knowledge. Obviously if a popular piece of software starts using it then we'll have to invest the time to support it, but at the moment it does not look like a good use of our resources.

Opus has its own way to define sub-menus in the file type context menus, predating Explorer's registry methods. We suggest using that if you want to create custom nested menus, although it will obviously only work in Opus and not show up in Explorer. For custom menus defined in the registry, you'll need to stick to single-level sub-menus, at least for now.

Thank you for that thorough answer, Leo. It hadn't crossed my mind that cascading multi-level menus might be an 'unofficial' feature. That explains a lot. It explains why the only official Microsoft reference to this feature is on the MSDN website. It also explains why there has been no attempt to rectify the documentation that is there.

I was only asking about it not working in DOpus because I thought it was an official feature. I can work with single-level menus. I will probably use the Win-Explorer implementation because I want consistency, as much as possible, between D'Opus and Win-Explorer context menus. I don't particularly like working in Win-Explorer but sometimes it's where I end up.

From you answer I've also gleaned that DOpus has it's own code for generating the context menus. I'm never sure how much DOpus is a front-end for Win-Explorer and how much it replaces Win-Explorer. Good to know DOpus has full control of its context menus.