Why does the Shift+F10 menu differ from the right-click menu?

Date:August 9, 2011 / year-entry #191
Tags:tipssupport
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20110809-00/?p=9943
Comments:    35
Summary:The Shift+F10 key is a keyboard shortcut for calling up the context menu on the selected item. but if you look closely, you might discover that the right-click menu and the Shift+F10 menu differ in subtle ways. Shouldn't they be the same? After all, that's the point of being a keyboard shortcut, right? Let's set...

The Shift+F10 key is a keyboard shortcut for calling up the context menu on the selected item. but if you look closely, you might discover that the right-click menu and the Shift+F10 menu differ in subtle ways. Shouldn't they be the same? After all, that's the point of being a keyboard shortcut, right?

Let's set aside the possibility that a program might be intentionally making them different, in violation of UI guidelines. For example, a poorly-designed program might use the WM_RBUTTON­UP message as the trigger to display the context menu instead of using the WM_CONTEXT­MENU message, in which case Shift+F10 won't do anything at all. Or the poorly-designed program may specifically detect that the WM_CONTEXT­MENU message was generated from the keyboard and choose to display a different menu. (This on top of the common error of forgetting to display a keyboard-invoked context menu at the currently selected item.) If somebody intentionally makes them different, then they'll be different.

Okay, so the program is not intentionally creating a distinction between mouse-initiated and keyboard-initiated context menus. Shift+F10 and right-click both generate the WM_CONTEXT­MENU message, and therefore the same menu-displaying code is invoked. The subtle difference is that when you press Shift+F10, the shift key is down, and as we all know, holding the shift key while calling up a context menu is a Windows convention for requesting the extended context menu rather than the normal context menu.

You get a different menu not because the program is going out of its way to show you a different menu, but because the use of the shift key accidentally triggers the extended behavior. It's like why when you look at yourself in the mirror, your eyes are always open, or why when you call your own phone number, the line is always busy. To avoid this, use the Menu key (confusingly given the virtual key name VK_APPS) to call up the context menu. (This is the key that has a picture of a menu on it, usually to the right of your space bar.) When you press that key, the code which decides whether to show a normal or extended context menu will see that the shift key is not held down, and it'll go for the normal context menu.

Of course, you can also press Shift+AppMenu, but then you'll have come full circle.


Comments (35)
  1. Dan Bugglin says:

    I've also seen the Menu key called the Application key, hence VK_APPS.  Menu would seem to be more apt, but when I hear "Menu" without "Context" I think of a menubar.  On the other hand, "Application" doesn't seem to fit the function of the key…

  2. Mc says:

    Shift+AppMenu does nothing in Chrome.   Pressing just AppMenu brings up the context menu however.

    Bad Google.

  3. Scotte says:

    My Dell E6500 notebook doesn't have the Menu key, so I was quite excited several months ago when I learned of Shift-F10 as a replacement. However, it doesn't work when searching the start menu. The text field retains focus even though a search result is highlighted. It's pretty frustrating, especially since the Menu key does work.

  4. jader3rd says:

    That's hillarious.

  5. Antonio Rodríguez says:

    That the keyboard accelerators for the Start Menu and Context Menu keys still work in Windows 7 is good for those of us still using pre-Win95 IBM Model M keyboards :-) .

    That the virtual key for the Context Menu key is VK_APPS makes me wonder if it was a primitive shortcut for opening the Programs folder located on the desktop in early, pre-Start-menu, Chicago betas. The Windows and Context Menu keys must have an interesting story behind, as the task bar or the Start menu have.

  6. Anonymous Coward says:

    Does the shell still use extended menus for anything interesting?

    In the Windows 95 days ‘Open with…’ was an extended menu item, but but now it's a submenu that always appears. I've been clicking around on a lot of things, but so far I haven't been able to find something that looks different if shift is held down.

  7. LukeH says:

    @Anonymous Coward: The extended menu in explorer gives you the "Open Command Window Here" option – very handy.

  8. JamieF says:

    @Anonymous Coward: In Windows 7 two menu items that come to mind are "Copy as Path" on files & folders and "Run as different user" on executable objects. Really useful to run a MMC as another user without having to log in as them.

  9. David Walker says:

    In spite of the linked article "Pitfalls in handling the WM_CONTEXTMENU message" dating from 2004, Internet Explorer 9 seems to ignore this advice: "When the user invokes a context menu from the keyboard, the x and y coordinates are both -1. In this case, you should display the context menu for the currently-selected item (or items, if a multiple selection is active)."  I would presume that the context menu FOR the selected item should appear (it sometimes does, depending on what's selected), and also that the menu should appear NEAR the selected item (it doesn't).

    If you select some text in this blog page, then press and release the keyboard menu key, the context menu appears in the upper-left corner of the IE window, not near the selected text.  If you select a link in this blog page with the mouse (without clicking it), then press the keyboad menu key, you don't get the same menu that you would get if you right-click on a link.

    I know that you, Raymond, don't control the other teams within Microsoft.  If I'm right about that behavior being a subtle error, then it's too bad that some of the teams don't pay more attention to your blog…  :-)

  10. Chris B says:

    It's funny because Shift-F10 or Shift-AppMenu gives you different results then Right-Click or AppMenu in Explorer.

  11. steveg says:

    I'd be curious to know if MS has telemetry on Menu key usage and how popular it is. I'm sure some people use it a lot, but is it 50% or 0.01%?

  12. 640k says:

    I only use context menu key when I cannot right click, for example when client area is 0 pixels. Never seen anyone use it. Ever.

  13. Jim says:

    640k: I wouldn't be so confident about that. I never notice using it, but when I'm using a keyboard that doesn't have it (or more accurately, requires you to press it in an awkward combination with a modifier key) I occasionally find it really frustrating.

  14. Kzinti says:

    Funny. I just discovered a new key on my 5-years old keyboard. I'm not even kidding.

  15. factor says:

    Is there an example of how to handle WM_CONTEXTMENU in WPF? I've just been subscribing to right click mouse events…

  16. Alfred E. Neumann says:

    I dare to add a "nitpickers comment": <support.microsoft.com/…/242380> and <support.microsoft.com/…/295116> states that Shift+F10 opens a command processor windows during GUI mode setup.-)

  17. Michael Urman says:

    What about the even more subtle case that with multiple monitors it's possible to have a right click via the mouse occur at (-1, -1)? Should one compare against GetMessagePos(), and if there's a match just make a guess?

  18. Neil says:

    Interestingly Firefox manages to display the keyboard context menu for a text field near the caret. It seems to get it wrong when the caret is too close to the bottom of the window though, and I don't see a bug filed for that. (The lack of context menu near page selection is bug 498254.)

  19. Tanveer Badar says:

    Nitpicker comment# 2: I can call myself on my sip phone, call is received on line no. 2 and after setting conferencing to on its a lot of fun, albeit with disasterous amounts of echo.

  20. Np says:

    The problem with this behavior is that users who do not have a menu (also known as Applications) key are stuck. This is especially problematic on Windows 7 where on the new taskbar right-clicking brings up a jump-list but shift + right-clicking brings up a completely different menu which is the classic menu for taskbar items. So, effectively if you do not have a menu key you cannot get to the cool new features of Windows 7, such as jump-lists, etc. It is fine when the shift key gave you just an extended menu, i.e. the same menu but with some extra options, but it is really bad when the extended menu is a completely different menu. This is a very bad design decision for Windows 7. I wonder why the designers haven't thought about it. The Win+shift+number shortcut keys for launching new instances of applications are also hard to press. And the strange behavior that if you press a win+number shortucut key mmor e thean onece it uswitcht anothr application, are both very bad design decisions.

  21. Simon says:

    640k: I use the context menu key quite often. If you have both hands already on the keyboard (eg. typing in Word), then having a key available is far quicker than finding and clicking the mouse. It's also a lifesaver if there are any ergonomic reasons for not wanting to use the mouse.

  22. Not Norman Diamond says:

    I've got a Macbook Air which runs Windows 7 exclusively. I ended up using a keyboard remapper to swap the Alt and Cmd keys around so that the keyboard layout on the left of the space bar is functionally 'ctrl winkey alt' like on all normal keyboards, instead of the Mac's 'ctrl alt cmd'. I also remapped the right alt to VK_APP because shift+f10 is a pain and because it doesn't always work exactly like a right-click.

    I use the keyboard as much as possible, so the lack of a 'menu' button was really frustrating for me.

  23. Brian Tkatch says:

    Kewl stuff Raymond. As a keyboard user, i find this very interesting.

    On a completely unrelated note, i'm thinking of purchasing the ONT book. If i buy it from you directly, would you sign it?

  24. David Walker says:

    @Anonymous Coward:  Things that you can do, or things that happen, during GUI mode setup are not very relevant in day-to-day operation.

  25. David Walker says:

    Oops, I directed that comment to the wrong commenter.  There's no way that I can edit it.  Oh well.

  26. Greg D says:

    @factor:  This is not a .Net (or WPF) blog.  Your question is a good one and is much more likely to get answered on the MSDN forums or on a site like StackOverflow.  :)

  27. Doug Deden says:

    My current favorite use of the context menu key is to open any file I want in Notepad. I placed a shortcut to Notepad in the SendTo folder, so now I just hit Menu, N, N, and the file opens in Notepad without having to deal with the "Open With…" menu or changing any file associations.

  28. Don Reba says:

    You are right! They are open! Never thought anything of it before…

  29. ChrisR says:

    @Doug Deden:  Thanks for the excellent tip; that will save me quite some time.

  30. @Brian Tkatch

    The book is a very good read, hopefully there'll be a second volume issued at some point.

  31. You use Sys Rq more than the Menu key?!

  32. James says:

    @Doug Deden: I've been using pretty much the same trick since Win9x. Although since the Menu key is without a doubt the least-used key on my keyboard (I might be able to count on my fingers the number of times I've used it since it was introduced!), I use Shift+F10, N, N.

    Of course, there will always be some program that also uses 'N' as a keyboard accelerator, in which case it messes the whole thing up. >:( In Win9x at least I could edit the accelerators from the File Types dialog (as also change icons for a file type, description, extension and so on), but sadly MS chose to remove that dialog in Win7 (or back in Vista, not sure). I know, I know, apparently it wasn't too accurate, but who cares? It certainly did what *I* wanted it to for 'normal' file types, and I'd rather have an inaccurate dialog than none at all and need to fire up RegEdit every time. Oh well… :(

  33. James says:

    > You use Sys Rq more than the Menu key?!

    Yeah, considering it shares duties with PrntScr…

  34. j b says:

    or why when you call your own phone number, the line is always busy.

    OffTopic: So you haven't got an ISDN phone line, I gather…

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index