How do I make sure that my shell extension is at the top of the context menu?

A customer wanted the items for their context menu shell extension to appear at the very top of the context menu. They did this by ignoring the recommended insertion point passed to the IContext­Menu::Query­Context­Menu function and just inserting their items at the top anyway:

HRESULT MyContextMenu::QueryContextMenu(
    HMENU hmenu, UINT indexMenu,
    UINT idCmdFirst, UINT idCmdLast, UINT uFlags)
    // Insert at the top (position 0), ignoring the indexMenu
    InsertMenuItem(hMenu, 0, TRUE, &mii);

However, they found that this didn't work. Their context menu item showed up in the middle.

Well, sure, their context menu extension broke the rules and put their menu item at the top, but that just gets them to the top of the context menu so-far. But there are other shell extensions, and they may end up going on top of yours. And of course there's the shell itself, which has final say over where things go, and it might decide to put things on top of yours as well.

At the end of the day, it's the context menu host that decides where the menu items go. If you break the rules, you may be able to trick the host for a little while, but you're living on borrowed time.

(And of course there's also the question "What if two programs did this?"

Comments (16)
  1. Erik says:

    One wonders why the API allows its users to select an insertion point, even though based on the discussion above, it would be much more straightforward to not have an ‘insertion point’ parameter at all, and just use the ‘recommended’ value. Could you shed some light how the designers thought the insertion point parameter might be used in a non-selfish/constructive way?

    1. Brian says:

      The insertion point parameter is useful if you are inserting multiple items and wish for them to be in a specific, contiguous order.

    2. Mason Wheeler says:

      I would imagine it exists to allow you to insert multiple menu items of your own in an order of your choosing, which is a very valid use case.

    3. It allows for context menu composition, without which context menu shell extensions wouldn’t work at all.

      1. Dave Bacher says:

        You could implement composition without this, if you planned for it from the get go. What you can’t fix is where two or more apps want to claim the top spot, one always has to win.

        The reason that I say that is for example, in my XAML based app, I have plug-ins and I allow them to change some context menus in certain situations – I’m even starting to experiment with it on Vive with projected XAML in VR space (* still think Microsoft should buy that company, neither here nor there).

    4. skSdnW says:

      A stricter design would have abstracted away the parameters and just provided a instance of an interface like “IMenuInsertService” or something like that where you told it about your menu items and the shell (the implementer of “IMenuInsertService”) would insert the items at the Win32 level. IContextMenu goes all the way back to Windows 95 and back then you trusted developers not to be evil.

  2. skSdnW says:

    If you create a static registry entry instead you can set the Position value to “Top” which is the best you can do while playing by the rules. MSDN says “If there are multiple verbs that specify this attribute then the last one to do so gets priority” which probably involves the unspecified registry enumeration order.

  3. Alex Cohn says:

    But from the POV of a user, or, more realistically, of an enterprise admin who’s task is to configure a unified system image access the organization, this is a totally legitimate question. Do they have tools to ensure their preferred order of this menu?

    1. Daniel Neely says:

      I’ve never seen one, and short of it being walled behind an elevated desktop all the abusive craplications attempting to make themselves first would just automate whatever that method was (via injected keyboard/mouse events if nothing else) in their attempt to win the war over every other scumbag dev doing the same.

    2. Tanveer Badar says:

      Do my organization admins have the power to stop me from installing shell extensions they know nothing about?

    3. cheong00 says:

      IMO, the admin only have interest in show/hiding items in context menu, not in the order itself.

      As long as you limit the number of items to like 10 items, the sort order difference isn’t that huge.

      1. Brian says:

        A fixed order has some advantages from a training point of view. If you know the order, you can describe things more easily and screen shots are more accurate.
        However, having worked for an ISV who loved to try to own his customers’ desktops, I’m quite happy that Microsoft keeps these folks at bay.

  4. Joshua says:

    The one time I went looking for this it turned out I really meant “rename the open verb”. (It was some weird file format that nothing else had a ghost of a chance of opening anyway.)

  5. Lawrence says:

    Must.. supply.. missing.. “)”

  6. Chris Barts says:

    It’s impossible here because there can only ever be one thing on top, but in the super-topmost window example in the linked post, well, wasn’t that how Windows 1.0 worked? Tiled windows? Every window is on top, none are above the others, they just can’t all be maximized. Now it’s impossible, eh? How soon we forget, eh?

Comments are closed.

Skip to main content