Developers: It’s a Context Menu, not a Right-Click Menu

Posted July 14th, 2008 by kyle

Well-behaved GUI software should make all functionality easily accessible from the keyboard. For Windows, most of this is covered by the Windows User Experience Guidelines.

But there a some subtleties not covered there which many developers get wrong. And one that I see quite often is the improper display of context menus. Many people refer to these as right-click menus, but they can also be initiated from the keyboard, either by pressing the menu key (usually to the right of the space bar) or Shift+F10.

The first problem is that some applications ignore the user and don’t display the menu at all when initiated via the keyboard. The second issue, and probably the most common, is displaying the context menu at the mouse pointer location instead of near the keyboard focus/selection. For keyboard users, it is not uncommon for the mouse pointer to be far away from the current selection (even on a different monitor), making for a very unpleasant, inefficient user experience.

Handling display of the context menu properly is very simple. Do not use the WM_RBUTTONUP message to display a context menu. Instead, process the WM_CONTEXTMENU notification in each control that displays a context menu. This notification provides the mouse position (if initiated via the mouse) or a position of -1, -1 if initiated via the keyboard.

If initiated via the keyboard, determine the position of the caret or first focused/selected item in the control and use that position to display the context menu. For tree and list controls, see how Windows Explorer handles this, and for edit controls, see WordPad. For all you developers who are doing this wrong, please fix it now. Thanks!

Share and Enjoy:These icons link to social bookmarking sites where readers can share and discover new web pages.
  • BlinkList
  • blogmarks
  • digg
  • feedmelinks
  • Furl
  • LinkaGoGo
  • NewsVine
  • Reddit
  • Simpy
  • Spurl
  • YahooMyWeb