1

嘿嘿。最后，经过大量的摆弄，我得到了一个 .rc 加载的上下文菜单，让我的托盘通知图标正常工作。（基于对话框的 Windows API 应用程序，没有 MFC）。但是，在各种示例和使用演示中，我总是看到HMENU在调用. 通知图标的弹出菜单在 MSDN 上根本没有记录（至少我没有找到超过一个段落）。CreateMenu()LoadMenu()DestroyMenu()TrackPopupMenu()

直观地说，我将 放在LoadMenu()消息处理中WM_INITDIALOG并存储HMENU，因此我不必每次都创建和销毁菜单。正如我所说，我还没有找到任何类似的例子，我觉得这有点有趣。在使用菜单或应用程序时，我是否有可能HMENU被“损坏”？或者像我一样追求（好吧，边缘的）额外性能是否安全？

INT_PTR CALLBACK MainDlg(HWND ..., UINT, WPARAM, LPARAM)
{
    switch (message)
    {
    case WM_INITDIALOG:
        ...
        HMENU hMenuBar = LoadMenu(hInst, MAKEINTRESOURCE(IDR_NOTIFYMENU));
        hNotifyMenu = GetSubMenu(hMenuBar, 0);
        ...
        break;

    ...

    case WM_NOTIFYICON:
        switch (lParam)
        {
        case WM_RBUTTONUP:        // there is no WM_CONTEXTMENU for 
            {                     // nid.uVersion != NOTIFYICON_VERSION_4
            POINT CursorPos;
            GetCursorPos(&CursorPos);

            // this is where I saw LoadMenu and stuff in examples

            SetForegroundWindow(hDlg); // otherwise menu won't disappear
            TrackPopupMenu(hNotifyMenu, TPM_LEFTALIGN, CursorPos.x,
                           CursorPos.y, 0, hDlg, NULL);

            PostMessage(hDlg, WM_NULL, 0, 0); // otherwise menu locks hDlg

            // this is where I saw DestroyMenu in examples
            }

            return (INT_PTR)TRUE;
        }
        ...
    }
    ...
}
4

1 回答 1

2

并不是它被破坏了，更多的是你不想让 GDI 资源超过绝对必要的时间。你可以很容易地用完它们，只要看看在最终找到解决方法之前与 GDI 资源限制作斗争数月的 Chrome。

除了加载菜单十几次并销毁它对于现代处理器来说什么都不是。不要过早地优化程序，尤其是不要为了这么少的收益。

至于为什么您没有找到任何专门处理通知图标菜单的 MSDN 页面，那是因为它们是两个独立的东西。菜单是一个菜单，无论它是在对话框顶部，当您右键单击文本框或右键单击通知图标时弹出。您不需要任何特殊建议或代码。

于 2011-03-25T19:43:04.840 回答