Log in

No account? Create an account

Previous Web | Next Web

More on Explorer sub-context-menus...

If you saw my last post (on cascading submenus from the Explorer context-menu), and you followed the link to MS's documentation, you might have noticed another page that refers to using ExtendedSubCommandsKey and wondered why I didn't mention it.

The short answer to this is simple; I couldn't get it working!

Turns out I'm not the only one and the general opinion on that particular bit of documentation is about as far from complimentary as you can get!

Anyway, I've had a bit of a Google since then and come across this blog post that makes sense of how to use this registry entry to build a submenu.

The cool thing with ExtendedSubCommandsKey is that it lets you build multiple levels of submenu.... "extended flyouts" I think is one phrase used to describe these... the image at the top of the ExtendedSubCommandsKey documentation page (reproduced here) demonstrates this:

[Explorer cascading submenus]

but (amongst that pages many failings), the page fails to elaborate on how to achieve such a thing.

Given the knowledge that this is possible, and the content of the blog post, this really is just a case of join-the-dots, but I figured I'd write it down here, in case I actually need it one day...

So, to summarise the blog post, there are three parts to making an ExtendedSubCommandsKey-based submenu work:

  1. A menu entry in the shell key. This doesn't have to have an MUIVerb entry (even if the docs suggest it does) but I do recommend you use set the menu entry text using either the default value of shell\keyname or the MUIVerb value... using shell\keyname is liable to cause confusion when you get into the cascading menu definition where it isn't allowed.

    The order of precedence for where the menu entry text comes from is shell\keyname < shell\keyname\@ < shell\keyname\MUIVerb (IOW, an MUIVerb value will supercede the others)

  2. An ExtendedSubCommandsKey (REG_SZ) String Value that tells Explorer the key (under HKCU) to look at for the submenu, eg *\ContextMenus\menu (I'm using ContextMenus as a container to keep things neat and together (esp once we have multiple cascades), but you don't have to... you can even just have the menu definition as, ie, *\menu) .
  3. A menu structure definition at the location referenced by ExtendedSubCommandsKey, so we might construct the hierarchy *\ContextMenus\menu\shell\menuentry\command, with appropriate values along the way.

    This appears to be the same menu structure as you might expect to find under HKCU\<somekey>.

So what do we need to know to make an extended cascade work?

Not much more actually... the key is to realise that you can put the same things in your submenu definition as you can put in the normal context-menu, and that this includes ExtendedSubCommandsKey values (but there is one important caveat)... So basically, create another menu structure, say at *\ContextMenus\menu2 and an menu entry in the original submenu definition with the new structure's location as its ExtendedSubCommandsKey value... and now for that caveat: this menu entry won't just use shell\keyname as the menu text, you must specify the text as either the menu key's default value or as the MUIVerb value. (I know, I pretty much already said that when summing up the blog post, but it bears reiteration!)

And a couple of screengrabs demoing this:

[Registry for cascading submenus]

[Registry cascade]

[The cascading context-menu in Explorer]