A very standard feature in Windows programs is the context sensitive floating menu. Basically, you intercept a right button up event, get the location of that event, determine which window should receive the menu’s commands and then tell a menu where to display. The menu itself comes out of resources and has the odd attribute of not displaying its root popup item.

Got it? Great. Now here are the dirty little details of how this all happens. (nudge nudge, wink wink.)

This particular example menu has a single menu command in it, ‘Get Item’. The menu item at the root, ‘This doesn’t display’ won’t get shown when the menu is presented to the user. Sometimes there is some descriptive string in here to help keep track of which popup menu does what but more often than not you’ll see things like ‘Dummy’ here instead. When ever I see the word ‘Dummy’ emblazoned at the top of a context menu, I am inclined to wonder who is being addressed with such a demeaning declarative. Not me, I hope.

void CMyClass::OnRButtonUp(UINT nFlags, CPoint point)
    {

    // Load the menu from resources.

    CMenu     menu;
    menu.LoadMenu( IDR_MENU_SS_LIST );

    // The menu we want to display is connected to the root popup.
    // Extract that from the loaded menu.

    CMenu* pPopup = menu.GetSubMenu( 0 );

    // Tell the menu where to display and also which window to send the
    // menu command to. In this case, we want the command to come
    // back to this window.
    // The button up event comes to us in client coords. We need screen
    // to tell the system where to put the menu.

    ClientToScreen( &point );
    pPopup->TrackPopupMenu( TPM_LEFTALIGN, point.x, point.y, this );
    }

That’s it. From here on out it’s business as usual. The normal routing mechanism for commands will send the command to the specified window which is supposed to handle the command in the normal fashion.;

Context Menu