Share via

Supplemental Registrations (aka. Context Menu Handers (etc) - where are they loaded from...)

  • Article

I've been thinking about the registration problem where you want to add a context menu (much of this applies to static verbs as well) to a file type (we'll say .ogg).  You don't want the default verb, you just want to add some verbs.  Because you don't want the default, you shouldn't put your progid in the HKCR\.ogg default value, so you put an entry under HKCR\.ogg\shellex\ContextMenuHandler.  And this works great.. until someone comes along and puts a progid in HKCR\.ogg's default value.  Look at the fallthrough logic below - #2 (where we registered), and #3 are only used if there is no progid! 

Fallthrough logic when loading context menu handlers (static verbs and then context menu handlers are collected from the following places):

(DO NOT USE THIS LOGIC IN YOUR CODE - it is a simplification of the real logic and it will change. Instead, use IQueryAssociations or AssocQuery* for all these kinds of file association related things.)

  1. HKCR\<ProgID>
  2. HKCR\<.ext> (only if #1 does not exist)
  3. HKCR\Unknown (only if #1 does not exist)
  4. HKCR\SystemFileAssociations\<.ext>
  5. HKCR\SystemFileAssociations\<PerceivedType>
  6. HKCR\Folder (only used if the selected item has the SFGAO_FOLDER attribute, such as a folder, zip, cab, etc.)
  7. HKCR\*
  8. HKCR\AllFilesystemObjects

But there is a way!  You can register supplemental verbs associated with the SystemFileAssociations key.  Note that those keys (#4 and #5) are folded in regardless of the association having a progid registered.  In our example, that would be HKCR\SystemFileAssociations\.ogg\shellex\ContextMenuHandler

The important thing here is that you should never put the registration under HKCR\<.ext>(!) because you should either be putting it under your progid (#1), or in SystemFileAssociations (#4).  Why do we disable #2 and #3 in those cases?  If folks are interested, I'll talk more about that later - or feel free to guess. :)

(A quick comment about #5 - I think it is often misused.  Applications don't know how to handle very many perceived types (one exception is text).  How are you going to handle the "video" perceived type?  I guarantee that we'll come out with more codecs/container formats, etc.  Unless you can guarantee that you can handle everything that will map into the perceived type, don't register for it - instead register for the individual associations that you really can handle.)

This technique is used for a lot of other things besides context menu handlers.  It's also used for Property Handlers for Windows Search, Windows Imaging Component codecs, etc, etc, etc.

Cheers,
James

[Update: finished the sentence beginning "In our example, that would be..."]

Comments

  • Anonymous
    September 06, 2007
    well, if you have a mediaplayer that uses directshow, you can probably play the file, so the video type makes sense for that What I hate the most is how Windows Media Player cheats (Its always at the top of the openwith list, even if you never use it, the rest of the list is sorted by last use) and it sticks its useless menus everywhere (how often do you burn something by right clicking on a folder? And both play and add to playlist, so useless)

  • Anonymous
    September 06, 2007
    The comment has been removed

  • Anonymous
    September 06, 2007
    The comment has been removed

  • Anonymous
    September 06, 2007
    @ak - I buy your argument somewhat (and it annoys me because I like MP4 and I think it's likely a very stable format for a while so a good choice for video of my kids, etc since every reencoding is data loss).  I wonder, though, if there wouldn't be a lot of legal questions involved. (Some of these are mostly the same thing (not sure about the container formats).  XViD is an "MPEG-4 ASP" encoder, which is also "H.264", which is also "ISO MPEG-4 part 10"  Not sure why we need so many names - H.264 and the ISO is two different standards bodies, but MPEG-4 ASP?)

  • Anonymous
    September 07, 2007
    XviD/DivX (aka Mpeg4 ASP aka MPEG-4 Part 2) is not the same as h.264 (aka Mpeg4 AVC aka MPEG-4 Part 10) h.264 is the "new" kid on the block and offers better quality compared to the older Mpeg4 ASP based codecs XviD/DivX mostly comes in the avi container, but can also be seen in MKV and OGG. h.264 will hopefully mostly come in just the mp4 container As for the legal questions, FLAC, OGG are 100% open, XviD is GPL IIRC but MS now supports in in Media Center extenders, so I don't see why they can't support it in WMP (And you don't need to use the XviD or DivX decoders, any Mpeg4 ASP decoder will do, MS could even code their own (First version of DivX was a hacked version of WMV so I'm sure they could decode it if they wanted) ) Got a bit off topic there, sorry ref: http://en.wikipedia.org/wiki/Xvid http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC http://en.wikipedia.org/wiki/MPEG-4_ASP

  • Anonymous
    September 07, 2007
    Fine with me - I don't mind understanding this stuff better.  Although I don't do a lot with it, I do a fair amount of home videos and like to know what I'm doing with those memories. Do you happen to know what specific codec is used on HD-DVD/Blueray/DVD?  Whatever all the popular media (movies) is encoded into is probably going to be most stable over time due to hardware support requirements.

  • Anonymous
    September 07, 2007
    HD-DVD and Blueray use the same formats, and they are; MPEG-2 (same as plain DVD), h.264 and VC1 (aka MS's WMV9) (Players need to support all 3 formats) I'm not sure what the container format(s) are