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

Question

The main idea of ​​programming the Windows shell is that you can associate this type of file (extension) with the fact that MS is currently calling progid (for example, Company.Type.Ver):

HKCR \ .txt @ = Acme.Text.1

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

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

But if I am XyzCorp, how to add a secondary verb to text files?

I don’t want to usurp the main file association - I am glad that it is associated with Acme.Text.1, but I want to add “Import to Xyz Editor”.

I could:
1. add a verb to Acme progid (for example, HKCR \ Acme.Text.1 \ shell \ my-verb)
2. Create a new progid from both of our sides and copy the Acme data into it and merge the XyzCorp verbs in that
3. add verbs directly to the file extension (at least one of them has been used)
4.???

Does anyone know the “correct” answer to this question?

EDIT: I'm really not thrilled with any solution that involves the need to modify someone else's PROGID. I would prefer to add something - IContextMenu or something else, outside of the associated PROGID, to add additional verbs / parameters to a specific file type.

It seems that such a crazy system has ext-> progid, where the progid belongs to separate development houses and can be removed or changed this way if desired. It amazes me as fragile (delete something and poof, your file extension stops working properly or installs something, and your secondary verb disappears, because ext now maps to another proprietary PROGID to which I did not add our verb, when we were (at the wrong time, knowing something about this other, yet non-existent prog)), and just dumb. After all this time, have all these versions of Windows and Microsoft never figured out a way to have handler layers for a given file type? Indeed?!?

I just find it crazy! Junior programming 101 includes learning a command pattern or other multi-level / cascading systems. Windows WinProcs themselves are organized into a command template template - so from the internal window context to the external set of possible handlers they get a crack in this MSG.

Of course, there is a way to add a verb that applies to several extensions without overriding the primary association of extensions extensions, which itself is completely independent of the primary mapping to the extension → progid (so that the user can install several programs over time, and still have access to the secondary verb for this type of file).

I suppose I can look at HKCR. * ... I understand its ability to add verbs there that apply to all types of files. But then I need to find a filtering method so that our verb is really present only for those actual file types that we should apply ...

Answer 1

It is possible, and it is very easy to do (as soon as you know where to look). The magic is in the key HKEY_CLASSES_ROOT\SystemFileAssociations . Here you will find many subsections named after file extensions. Just create the necessary shell / open / command keys under them.

Here is an example registry file showing the structure. If you save this as a .reg file and import it, you will get the “Import to Xyz Editor” command added to all .txt files without affecting the basic 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 several keys that are not named after the extensions: "text", "image", "video", etc. They correspond to PerceivedType elements under extensions in HKCR. For example, the HKCR\.png\PerceivedType parameter is set to "image", as well as HKCR\.jpg\PerceivedType , so you can add handlers under HKCR\SystemFileAssociations\image , which will appear for all types of "images".

Answer 2

An unnamed value (aka default or standard value) for the file extension key can be progID, but not required. This is really just an identifier. This is normal if you add your verbs to the file type identifier, even if it looks like a different name. The following paragraphs discuss all options.

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

This voice gets my vote. It is simple and effective. Updating / reinstalling ACME software will not affect the verbs that you added to the ACME / progid type. Removing Acme software will usually not result in the removal of your verbs, as uninstallers usually do not delete registry keys related to subkeys that they did not create.

2. create a new progid from both of our sides and copy the Acme data into it and merge the XyzCorp genes into it

This will work at the time of the change, but will stop working when the Acme program is updated / reinstalled - the installer will not know how to update the general file type. Similarly, when you start the Acme removal program, it will not delete verbs, so they will spoof commands in a non-existent way.

3. add verbs directly to the file extension (at least one of them has been used)

I just tried this on Win XP SP3, and unfortunately this did not work. Verbs should be installed under the file type key, and not with the file extension.

4.

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

Summary For simplicity, I would go with No. 1. The XYZCorp installer can check if a file type exists for the file extension, and if it adds verbs under the existing type or creates a new file type if it does not exist, and registers the verbs under it.