Forum

Dear Support,

I have to solve the following scenario: I have to create a sublevel popup menu in Menubar and the same menu as the popup menu of a toolbar button. No problem in this one, I create a helper menu item in the .rc file and use CExtPopupMenuWnd::g_nMsgPrepareOneMenuLevel to know when I have to replace it with many other menu items. But in my case, along with the new menu items, I have to fill a variable, a kind of map, that maps these items with items specific to my application. Later, this map is used when one of the commands is fired in the dynamically created menu.

My problem is that I need to erase this map if no menu item is selected. Is there any message or overridable method that could be used to find out if my menu disappeared but no command was fired from it?
I saw there was a TPMX_NO_WM_COMMAND flag that can be used with TrackPopupMenu, but I doubt I can use TrackPopupMenu in this scenario.

Any help would be appreciated.
Chris

We are sorry for the delay with this reply. It seems the HelpNotes sample demonstrates what you need: the notification about complete menu selection through the CExtPopupMenuWnd::g_nMsgItemCoveringNotification, CExtPopupMenuWnd::g_nMsgNotifyMenuExpanded and CExtPopupMenuWnd::g_nMsgNotifyMenuClosed registered messages.

I’ve examined your HelpNotes sample, checking when exactly CExtPopupMenuWnd::g_nMsgNotifyMenuClosed is fired. I also checked some snippets of your code, where you send this message. What I found is that the message is sent both when the menu closes because of selecting a menu item or when the menu closes without selecting a menu item. In both cases wParam is 0, so I can’t distinguish them.

RUI is used neither in your sample, nor in my code, so CExtPopupMenuWnd::g_nMsgNotifyMenuExpanded message would never be fired.

I don’t have any idea how CExtPopupMenuWnd::g_nMsgItemCoveringNotification message could help solve my problem.

In your sample there is another message, CExtPopupMenuWnd::g_nMsgPrepareDesktopBk, but I couldn’t find out what triggers this message and how it could help me.

Could you please provide some more information about any of these messages that would help me solve my initial problem?

Thank you!
Chris

We are sorry for the delay with this reply. It is not a problem to implement any new messages which will fit your requirements but we would like to discuss your task in details first. What we currently have: the dynamic menu construction in your program occurs when the appropriate popup menu level is displayed first time during the life time of one menu tree. The menu will be constructed dynamically again only when the menu tree will be tracked again. This should not be a problem because menus are typically menus have no very long life time. You can bind your custom data to each dynamically inserted menu item using some external map or using the user defined LPARAM values attached to each menu item. The CExtPopupMenuWnd::g_nMsgNotifyMenuClosed method allows you to catch the menu closing event and clean up the external maps if they are used. The WPARAM parameter of this method is equal to the invoked command item’s identifier or zero of the menu is closed without invoking any command. So, we guess you have everything for your task.

If you need to re-build the dynamically constructed menu parts while opening one menu level several times while one menu tree is tracked, then you should code the CExtPopupMenuWnd::g_nMsgPrepareOneMenuLevel registered message handler method with care about the dynamic menu sublevel can be already constructed. The per-menu-item LPARAM user-defined values can be used for marking dynamic menu sub trees.

I have to disagree to this part:
"The WPARAM parameter of this method is equal to the invoked command item’s identifier or zero if the menu is closed without invoking any command." I tried your HelpNotes sample as you suggested. In that, there is only one message handler for 3 messages originally So I made a message handler for CExtPopupMenuWnd::g_nMsgNotifyMenuClosed and put the same code in it as in the original message handler. This way, I could check the value of the WPARAM parameter of the CExtPopupMenuWnd::g_nMsgNotifyMenuClosed message. It is always zero! My problem would be solved if it worked as you wrote, but it doesn’t.

The CExtPopupMenuWnd::g_nMsgNotifyMenuClosed is sent with non zero WPARAM only if the CExtPopupMenuWnd::m_hWndNotifyMenuClosed property is not NULL. You can initialize the CExtPopupMenuWnd::m_hWndNotifyMenuClosed property of each displayed CExtPopupMenuWnd object while handling the CExtPopupMenuWnd::g_nMsgPrepareOneMenuLevel message. But this may be not the easiest way. We recommend you to use the CExtPopupMenuWnd::g_nMsgNotifyMenuClosed message for handling the cancel menu tracking event only. If the command item is invoked, then you can catch this event using standard MFC’s command handling mechanism for single command identifiers and/or for command ranges. Please let us know whether this approach is acceptable for you?

I’m not sure if I understand the approach you suggest, but with this new information about CExtPopupMenuWnd::m_hWndNotifyMenuClosed I can make an acceptable solution.

Thank you very much for your help!

We mean you have to use the CExtPopupMenuWnd::g_nMsgNotifyMenuClosed message to catch the menu closing event without invocation of any command. If a menu was closed as a result of invoking some command item, then you have two ways of handling this:

1) Use the CExtPopupMenuWnd::g_nMsgNotifyMenuClosed message, but the CExtPopupMenuWnd::m_hWndNotifyMenuClosed property should be initialized as we described in the previous answer.

2) Use the MFC way based on the OnCmdMsg() virtual method or on the ON_COMMAND_RANGE message map entry. Both MFC ways allow you to handle a range of command events in one method.