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(v=vs.85).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(v=vs.85).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.
