Forum

Reposting this because I’m not sure it got through before - I was logged off when I hit "post".

I used the example in the FAQ to modify the File menu in my app, and it works great. However, there’s a sub-menu off the file menu that I need to modify as well, and I don’t get the g_nMsgPrepareMenu message for the submenu. Looking through the source code, I found that, in ExtPopupMenuWnd.cpp, _TrackPopupMenu(), there is code checking to see if the menu being tracked is a toplevel menu - if it isn’t, the routine doesn’t send the message. If I comment out the code (and the corresponding ASSERTs) I then get the message and everything *seems* to work fine. Could you elaborate on the reason why the toplevel checks are in there and what repercussions there may be by removing them?

Hi,

CExtPopupMenuWnd implements a menu hierarchy for one visible popup menu. It sends the g_nMsgPrepareMenu message for the top menu only to perform complete initialization of the popup menu tree (not only a single level). The hierarchy of CExtPopupMenuWnd objects exists until the menu is tracked. Only visible objects have real HWNDs. That described menu design.

We believe that the menu structure should not be changed while the popup menu is being tracked. So, there is no reason to reinitialize each popup menu every time it becomes visible. Of course, this causes some inconvenience: A universal the universal message handler for g_nMsgPrepareMenu needs to be recursive. There are no potential problems with your code modification. You just changed menu design.

So the way to handle this within the intended design would be to modify any and all submenus at the time I get the toplevel menu notification?

Yes, you are right.