I'm blind: Get Popup Menu's Parent?

[colin glenn]

What I'm trying to do is handle the %WM_INITMENUPOPUP commands and dynamically enable/disable menu items on the fly based on available clipboard formats. However:

• Parameters
  • wParam
    • Handle to the drop-down menu or submenu.
  • lParam
    • The low-order word specifies the zero-based relative position of the menu item that opens the drop-down menu or submenu.
    • The high-order word indicates whether the drop-down menu is the window menu. If the menu is the window menu, this parameter is TRUE; otherwise, it is FALSE.

Which means I got the handle to the popup, not the menubar. And while my current top menu elements are:

File / Edit / View / Help

If I should happen to change things up and for some quack reason stick a new top level menu item in front of Edit, that means my Edit is no longer the #1 zero-based relative position menu item. Currently, it seems in order to do this, you need a MenuHitTest function:

FUNCTION MenuHitTest(hDialog AS DWORD, wParam AS DWORD, lParam AS DWORD, _
                        mString AS STRING) AS LONG

LOCAL hMenu, mIndex, mCount, myMenu, sCount     AS DWORD
LOCAL aString                                   AS ASCIIZ * 80

    IF ISFALSE HI(WORD, lParam) THEN
        hMenu = GetMenu(hDialog)
        mCount = GetMenuItemCount(hMenu)
        mIndex = LO(WORD, lParam)
        IF mIndex < mCount THEN
            sCount = GetMenuString(hMenu, mIndex, aString, 79, %MF_BYPOSITION)
            IF sCount > 0 THEN
                IF mString = aString THEN
                    MenuHitTest = GetSubMenu(hMenu, mIndex)
                END IF
            END IF
        END IF
    END IF
END FUNCTION

:coffee:

CASE %WM_INITMENUPOPUP
    IF ISTRUE MenuHitTest(CB.HNDL, CB.WPARAM, CB.LPARAM, "Edit") THEN
        ' then do stuff
    END IF

Not a bad construct for studying the SDK for a while, though if there IS a GetParentMenu function, or a menu function which gets the parent, I'm not finding it.

Note: it's not %100 percent necessary to return the SubMenu's handle, if the strings match, then the SubMenu will be the same thing as the wParam, which should also be checked if you're crazy enough to nest menu names.

In which case you would also do:

myMenu = GetSubMenu(hMenu, mIndex)
IF myMenu = wParam THEN
    MenuHitTest = myMenu
END IF

Otherwise a %TRUE return will suffice. I suppose this can be fleshed out further to gain the parent of SubSubMenu's.

[Michael Mattias]

Hard to tell from your code, but it seems you could just enable/disable the 'Parent' menu items when you get WM_INITMENU from that?

WM_INITMENU Message

--------------------------------------------------------------------------------

The WM_INITMENU message is sent when a menu is about to become active. It occurs when the user clicks an item on the menu bar or presses a menu key. This allows the application to modify the menu before it is displayed.

Isn't that what you are doing, trying to enable/disable items before the user sees them, right?

[colin glenn]

Yes, I am attempting to modify the state of menu items before they're displayed, however:

A WM_INITMENU message is sent only when a menu is first accessed; only one WM_INITMENU message is generated for each access. For example, moving the mouse across several menu items while holding down the button does not generate new messages. WM_INITMENU does not provide information about menu items.

So I don't know which menu item was selected, and WindowProc only gets this message once. The wParam is the same handle as the main menu for the program, [wParam == GetMenu(hWnd)]. Do I really need to check the clipboard for all available formats that my program is designed to handle on every menu access when perhaps the user is only using the FILE menu to save their work in progress? The other option besides using my MenuHitTest is to scan the menu at program initialization and store the popup menu(s) I have an interest in modifying on the fly and comparing handles when getting the WM_INITMENUPOPUP message from the OS. Which works till I decide to get strange and modify the entire menu on the fly.

Yes, I do strange things like replace the entire menu when the structure of the program changes. In which case I'd have to remember to rescan the menu of course.

[Michael Mattias]

So I don't know which menu item was selected [when WM_INITMENU received]

You're right, WM_INITMENUPOPUP is the right place if it's a POPUP menu about which you care.... and of course ypu don't know which item has been selected, because none has. (You get WM_MENUSELECT when that happens).

I just don't see why you have to concern yourself with the status of items on menus which are not becoming active.

In this demo here...
Add a 'Favorite Files' menu to your application 10-25-07

.. I check the favorites menu only when it's about to show... and I do it every time it's about to show, and don't attempt to 'save' the status, or change any other menu settings at that time. That code, too, uses menus in which the number of items changes dynamically.

Maybe if you showed the menu structure eg

FILE
   OPEN 
   CLOSE
EDIT 
   COPY 
   PASTE 
...

.. and added a little narrative we'd have a better picture.

(I know asking for real code is a dream).

It just seems you are doing something the hard and/or long way.

MCM

[Michael Mattias]

Eg when you get INITMENUPOPUP for the edit menu, check if a supported format's data are on the clipboard or not (IsClipboardFormatAvailable()), and enable or disable the PASTE item accordingly. THe user will only be able to select 'paste' if there actually is something you can paste on the clipboard.

[Bern Ertl]

Some time ago, I posted some code for an owner drawn menu. In that example, I added control ID's to the top level menubar so I could reference them by ID instead of position. Perhaps that might help?

[Edwin Knoppert]

I haven't read all text in this message but what i wanted to tell is that you can also enumerate all menu items until some handle or id is passed so you'll know what parent and id's are available.