How does one add a secondary verb to a file type in Windows shell?

Question

The basic idea with Windows shell programming is that you can associate a given file type (extension) with what MS is currently calling a progid (e.g. Company.Type.Ver):

HKCR\.txt @=Acme.Text.1

HKCR\Acme.Text.1 @=This is the progid for text file associations for Acme

And then Acme Corp can put as many shell verbs as they want as subkeys of HKCR\Acme.Text.1\shell such as HKCR\Acme.Text.1\shell\open.

But if I'm XyzCorp, how do I add a secondary verb to text files?

I don't want to usurp the primary file association - I'm happy for it to be associated to Acme.Text.1, but I want to add "Import into Xyz Editor".

I could:
1. add a verb to Acme's progid (e.g. HKCR\Acme.Text.1\shell\my-verb)
2. create a new progid on both our behalfs and copy Acme's data to that, and merge XyzCorp's verbs into that
3. add verbs directly to the file extension (at least one used to be able to do so)
4. ???

Does anyone know the "right" answer to this?

EDIT: I'm really not thrilled with any solution that involves having to modify someone else's PROGID. I really would prefer to add something - an IContextMenu or whatever is required, outside of the associated PROGID to add additional verbs / options to a given file type.

It seems like such a crazy system to have ext->progid where progid is owned by individual development houses, and can be deleted or changed by such at will. This strikes me as fragile (uninstall something and poof, your file extension stops working properly, or install something and likewise your secondary verb disappears because ext is now mapped to a different proprietary PROGID to which I didn't add our verb to when we were installed (not, at that time, knowing anything about this other as-yet-nonexistent progid)), and just dumb. After all this time, all these versions of Windows, and Microsoft has never figured out a way to have layers of handlers for a given file-type? Really?!?

I just find that flabbergasting! Junior programming 101 involves learning command-pattern or other layered / cascading systems. Windows WinProcs themselves are organized in a command-pattern pattern - so that from the inner window context to the outer, many possible handlers are given a crack at a given MSG.

Surely there is a way to add a verb that applies to several extensions without overriding the extensions' primary progid association, which is itself totally independent of the primary extension->progid mapping (so that the user can install multiple programs over time, and still have access to a secondary verb for that file type).

I suppose I can look at HKCR.* ... I understand its possible to add verbs there which apply to all file types. But then, I need to find some way to filter so that our verb is only really present for those actual file types we should apply to...

Answer 1

This is possible, and it's very easy to do (once you know where to look). The magic lies in the key HKEY_CLASSES_ROOT\SystemFileAssociations. Here you will find many subkeys named after file extensions. Simply create your desired shell/open/command keys under these.

Here is an example registry file showing the structure. If you save this as a .reg file and import it, then you'll get the "Import into Xyz Editor" command added to all .txt files, and without affecting the primary file association:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\SystemFileAssociations\.txt]

[HKEY_CLASSES_ROOT\SystemFileAssociations\.txt\shell]

[HKEY_CLASSES_ROOT\SystemFileAssociations\.txt\shell\xyz-import]
@="Import into Xyz Editor"

[HKEY_CLASSES_ROOT\SystemFileAssociations\.txt\shell\xyz-import\command]
@="notepad.exe \"%1\""

Also under HKCR\SystemFileAssociatons are a few keys not named after extensions: "text", "image", "video", etc. These correspond to the PerceivedType entries under extensions in HKCR. For example, HKCR\.png\PerceivedType is set to "image", and so is HKCR\.jpg\PerceivedType, so you could add handlers under HKCR\SystemFileAssociations\image which will appear for all "image" types.

Answer 2

The unnamed value (aka default or standard value) under the file extension key can be a progID, but doesn't have to be. It's really just an identifier. It's ok for you to add your verbs under the file type identifier even if it looks like someone else's name is there. The next paragraphs consider each of the options.

1. add a verb to Acme's progid (e.g. HKCR\Acme.Text.1\shell\my-verb)

This one gets my vote. It's simple and effective. Upgrades/reinstallation of ACME's software will not affect verbs that you have added to ACME's file type/progid. Uninstalling Acme's software will typically not remove your verbs, since uninstallers usually do not remove registry keys contaning subkeys that they did not create.

2. create a new progid on both our behalfs and copy Acme's data to that, and merge XyzCorp's verbs into that

This would work at the time the change but will stop to work when Acme's program is upgraded/reinstalled - the installer will not know to update the shared file type. Similarly, when Acme's uninstaller is run, it will not remove the verbs, so they will be dangling commands to a non-existent path.

3. add verbs directly to the file extension (at least one used to be able to do so)

I just tried this on Win XP SP3, and unfortunately it didn't work. The verbs have to be set under the file type key, not the file extesion key.

4. ???

You could create a ContextMenu Handler - this is a shell extension and requires implementing COM interfaces. An overview of the differences and benefits of context menu handlers compared to simple registry-configured verbs is described in Shell Context Menu.

Summary For simplicity, I'd go with #1. XYZCorp's installer can check if a file type exists for the file extension, and if so adds verbs under the existing type, or it creates a new file type if one does not exist and registers the verbs under that.