MFC应用程序中的菜单提示信息

核心提示：CMenuTipManager 有一个静态的辅助函数 CMenuTipManager::GetRunningMenuWnd，它返回当前正在运行的菜单窗口，MFC应用程序中的菜单提示信息(3)，鉴于这个函数的使用频率非常高，我将其设定为公有，但是不知道哪 位友好的微软员工在编写这个函数时显然没有注意到根本不需要 CFra

CMenuTipManager 有一个静态的辅助函数 CMenuTipManager::GetRunningMenuWnd，它返回当前正在运行的菜单窗口。鉴于这个函数的使用频率非常高，我将其设定为公有。但这个函数是如何工作的呢？你也许考虑调用 WindowFromPoint 来得到位于鼠标下面的窗口。多数情况下这种方法能够达到目的，但是不要忽略一种情况：用户可能会通过键盘而非鼠标来调用菜单，此种情形下光标可能位于任何位置，而未必是在菜单上的。所以 CMenuTipManager 改为调用 ::EnumWindows 列举出所有顶层窗口，并且在其中寻找一个使用了特殊类名 #32768（Windows 为菜单窗口使用的类名）的窗口。 static BOOL MyEnumProc(HWND hwnd, LPARAM lParam)
{
　 char buf[16];
　 GetClassName(hwnd, buf, sizeof(buf));
　 if (strcmp(buf,"#32768")==0) { // menu window
　　　// save hwnd
　　　return FALSE; // no need to look further
　 }
　 return TRUE;　　　 // keep looking
}　　　　　因为只会显示一个菜单，所以 MyEnumProc 函数找到的第一个就恰恰是我们需要的。即便由于某些非常古怪的原因，有两个菜单同时出现，EnumWindows 也会按照z轴上自顶向下的顺序列举窗口，所以第一个被找到的菜单窗口也一定就是当前的活动菜单了。很聪明的做法不是么？一旦你找到了菜单窗口（HWND 或者 CWnd），剩下的就只是为提示信息的出现位置进行一些像素运算了。Figure 2 中的 CMenuTipManager::OnMenuSelect 展示了细节工作。

那么提示信息文本怎么样呢？CMenuTipManager 提供了另外一个辅助函数， CMenuTipManager::GetMessageString，用以得到与每一个菜单命令相关联的提示信息字符串。这个函数是我或多或少地从 CFrameWnd::GetMessageString 直接拷贝过来的。为什么要复制这个函数？这样一来你就可以在没有主框架的情况下调用它了。CFrameWnd::GetMessageString 应该是静态的，但是不知道哪 位友好的微软员工在编写这个函数时显然没有注意到根本不需要 CFrameWnd。为什么在加载字符串资源的时候一定需要通过主框架窗口？为了通用性，我 创建自己的静态版本函数。