Handling WM_INITMENUPOPUP; now what?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I need to perform some special initialization of a menu when it is displayed, so I am looking for the WM_INITMENUPOPUP so that I can modify my menu before it appears. Unfortunately WM_INITMENUPOPUP doesn't provide the most basic information that you would need with this function - the menu being displayed! For example, assume I have an app with these menus: File, Edit, and Help and you trap the WM_INITMENUPOPUP message and pull out the handle to the menu being displayed. Can anyone tell me which menu it is? Is it the File menu, the Edit menu, or the Help menu? From what I can tell, it's impossible to get this information because the base item of a popup menus cannot be assigned an ID! From what I can tell, I can do nothing more than make an educated guess on the menu being displayed by looking at its position or looking at the IDs of menu commands within the menu (assuming of course that the menu contains something other than more submenu nodes and that translators handling the localized versions of a resource DLL did not modify the menus or their positions to make better sense in other locales) I've got to be missing something here because this is such a huge gaping hole in the menu API that it would have been fixed before Windows 95 was released

What is the trick to determing which menu was popped up?
 
Steve said:
I need to perform some special initialization of a menu
when it is displayed, so I am looking for the
WM_INITMENUPOPUP so that I can modify my
menu before it appears.

FWIW, I just checked an application of mine for its handling of this
message. I get the ID of item #0 of the popup menu and case off that to
determine what to do next.

I would think that there is a WM_MENUSELECT message being generated when the
user moves the mouse over the menu item in the owner menu that opens the
popup, no?

Regards,
Will
 
Steve said:
I need to perform some special initialization of a menu when it is displayed, so I am looking for the WM_INITMENUPOPUP so that I can modify my menu before it appears. Unfortunately WM_INITMENUPOPUP doesn't provide the most basic information that you would need with this function - the menu being displayed! For example, assume I have an app with these menus: File, Edit, and Help and you trap the WM_INITMENUPOPUP message and pull out the handle to the menu being displayed. Can anyone tell me which menu it is? Is it the File menu, the Edit menu, or the Help menu? From what I can tell, it's impossible to get this information because the base item of a popup menus cannot be assigned an ID! From what I can tell, I can do nothing more than make an educated guess on the menu being displayed by looking at its position or looking at the IDs of menu commands within the menu (assuming of course that the menu contains something other than more submenu nodes and that translators handling the
localized versions of a resource DLL did not modify the menus or their positions to make better sense in other locales) I've got to be missing something here because this is such a huge gaping hole in the menu API that it would have been fixed before Windows 95 was released!

What is the trick to determing which menu was popped up?

I believe submenu items can be assigned an ID with SetMenuItemInfo or
InsertMenuItem, even if the resource editor doesn't support it. If you need
to get the submenu's parent menu, you can search the window's menubar
recursively for the menu handle passed to you in WM_INITMENUPOPUP.
 
WM_MENUSELECT wouldn't work because it runs into the same flaw that handling the other message does. For a menu command it returns the identifier of that command but if it's a submenu then you're given the submenu's index position in that menu.

As far as I've been able to tell, there's no way of assigning an ID to a menu item if that menu item pops out a submenu and that's an enormous limitation because it forces developers to take a "best guess" on the position of a submenu in a menu. It requires all localized versions of resource DLLs to conform to the exact same layout for their menus otherwise any constants used for these positions would suddenly be invalid; an app would be damaged simply by adding an additional separator bar in a menu! It also introduces problems when menu items or entire menus are added and removed while the app is running; with multiple developers generally working on major commercial apps this limitation needlessly makes it easier for developers to fail to realize that a menu position value needs to be updated in a completely different file. Basically what I'm saying is that menu entries which are submenus absolutely need some sort of unique identifier attached to them
 
Thanks, I'll have to check that out but it still requires knowing at runtime which submenu is which. If this idea works the code for assigning submenu IDs could at least be performed at one place (therefore eliminating the fear of different files assuming different positions for the submenus)

Any idea if a new version of Visual Studio or Windows will support this in an easier way?
 
Hi Steve,

Thanks for posting in the community.

First I would like to confirm my understanding of your issue.
From your description, I understand that you want to determine which
submenu is selected when handling the WM_INITMENUPOPUP message, am I right?

Based on my experience, the nIndex parameter of the OnInitMenuPopup(CMenu*
pPopupMenu, UINT nIndex, BOOL bSysMenu) is the position index(from the left
end to the right 0...n-1) of the selected submenu, and it may be the only
way to determine which the submenu is popping up.
By the way, I think the developer would be familiar with his own
application's submenu position.

From what I can tell, it's impossible to get this information because the
base item of a popup menus cannot be assigned an ID!

I think the base item of a popup menu is not a real(valid) menu item, and
there really has no way to assign an ID to a submenu group, only the menu
item and one whole menu resource can have their own IDs.

I am regret that it is by design ;-(


Thanks!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
 
Thanks for the reply. It looks like there really is no way of determining this information, but I really think Microsoft should reconsider this behavior. Programs are only going to get more and more complicated and individual apps can have an entire team of developers working on the product, it's very plausable for someone to add or remove a menu dynamically and throw everyone else's position values out of wack. For example, marketing could tell the developer in charge of the resources that the trial version of an app won't have a certain submenu maybe even for only a certain market and then everyone else's position values would be off. Even in the best case senerio where the development team created some sort of manager object to juggle all of these changes it would still be easier and more reliable if this behavior came straight out of the API since its the one that handles the menu anyway.

If they submenu base items can't have a true command ID (since they aren't really commands) then it would be extremely helpful if they had some other form of identification from which they identity could be determined with 100% accuracy. It just seems strange with computers and Windows being as advanced as they are they we have to make an educated guess on the identity of a submenu item.
 
Hi Steve,

Thanks for your quickly response!

I can understand your concerns on the submenu ID's issue, its really an
issue in the condition you mentioned.

We will redirect your feedback to the product team.
We are looking at continual improvement, and it's this kind of feedback
that let's us know what things you're trying to do, that we haven't yet
exposed for you.

If there is any other feedback on our product, you can go to
http://register.microsoft.com/mswish/suggestion.asp?&SD=GN&LN=EN-US&gssnb=1
to submit it.


Thanks!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
 
Back
Top