[PATCH] user32: Don't depend on HMENU being valid for popup menus
Vincent Povirk
madewokherd at gmail.com
Tue May 6 16:34:21 CDT 2014
if (menu->FocusedItem != NO_SELECTED_ITEM)
{
+ ERR("focused: %u, nitms: 0x%x\n",
+ menu->FocusedItem,
+ menu->nItems);
menu->items[menu->FocusedItem].fState &= ~(MF_HILITE|MF_MOUSESELECT);
menu->FocusedItem = NO_SELECTED_ITEM;
}
Is this stray debugging code or a real error condition?
- * Return the handle of the submenu, or hmenu if no submenu to display.
+ * Return the handle of the submenu, or menu if no submenu to display.
Still slightly inaccurate as the returned submenu is no longer a handle.
@@ -4787,24 +4770,29 @@ static BOOL SetMenuItemInfo_common(MENUITEM * menu,
menu->wID = lpmii->wID;
if (lpmii->fMask & MIIM_SUBMENU) {
- menu->hSubMenu = lpmii->hSubMenu;
- if (menu->hSubMenu) {
- POPUPMENU *subMenu = MENU_GetMenu(menu->hSubMenu);
- if (subMenu) {
- if( MENU_depth( subMenu, 0) > MAXMENUDEPTH) {
+ if(menu->fType & MF_POPUP){
+ if(menu->submenu)
+ InterlockedDecrement(&menu->submenu->refcount);
+ }
How do we know this isn't the last reference?
I'm not sure this frees submenus correctly. If I create a popup menu
and add a submenu to it, that submenu has two references (one because
it has an HMENU and one because it is a submenu). DestroyMenu should
recursively destroy submenus. So it seems to me, destroying a menu
needs to destroy the handles to submenus (if they have one) and
release its references to them.
More information about the wine-devel
mailing list