有效的 MFC ID 范围

这让我很困惑！我正在读这个技术说明 https://learn.microsoft.com/en-gb/cpp/mfc/tn020-id-naming-and-numbering-conventions它指出：

• Prefix Resource type Valid range
• IDR_ multiple 1 through 0x6FFF
• IDD_ dialog templates 1 through 0x6FFF
• IDC_,IDI_,IDB_ cursors, icons, bitmaps 1 through 0x6FFF
• IDS_, IDP_ general strings 1 through 0x7FFF
• ID_ commands 0x8000 through 0xDFFF
• IDC_ controls 8 through 0xDFFF

然后它指出：

Windows 实现限制将真实资源 ID 限制为小于或等于 0x7FFF。

MFC的内部框架保留了这些范围：

• 0x7000 到 0x7FFF（请参阅 afxres.h）

• 0xE000 到 0xEFFF（参见 afxres.h）

• 16000 到 18000（请参阅 afxribbonres.h）

这些范围可能会在未来的 MFC 实现中发生变化。

多个 Windows 系统命令使用 0xF000 到 0xFFFF 的范围。

1 到 7 的控件 ID 保留用于标准控件，例如IDOK and IDCANCEL.

字符串的 0x8000 到 0xFFFF 范围是为命令的菜单提示保留的。

现在我完全困惑了。

• 28672 - 32767 已保留。
• 32768 - 57343 用于ID_ Commands.
• 57344 - 61439 已保留。

上面说的有道理。但是我们有：

• 1 - 32767 是字符串
• 32768 - 65535 已保留。啊？这会消除命令范围！

有人可以用十进制和简单的英语提供各种资源的正确范围吗？

我问的原因是因为在使用 ResOrg 时它指出：

然而，它会将命令标记为超出范围：

这些值在范围内0x8000 到 0xDFFF.

我使用 Excel 和公式来过滤列表，因为我了解范围，结果如下：

首先：0x8000 及以上的命令没有必需的范围。

此要求出现在 MFC 的一些非常早期的版本中，其中命令路由检查此范围以减少通常低于此范围的控件的正常命令 ID 的“往返”。

我刚刚重新检查了最旧的 MFC 代码（我在 VM 中仍然有 VC6.0），并且在 MFC 代码中也找不到任何与此相关的限制。

但这是我的经验，正如您在代码中看到的那样。 ID 低于 0x8000 的命令可以工作...并阅读下面我关于功能区代码扩展的注释。

命令 ID（菜单、工具栏、功能区）必须低于 0xF000，因为系统的命令 ID 大于等于 0xF000。

即使菜单 ID 与命令行或工具提示的相应提示的组合也不是问题。您可以使用 0x0001 到 0xDFFF 范围内的任何数字。

MFC 中的字符串 ID 扩展到 0xFEFF。

一些对话框、光标和位图的范围是 0x7800 到 0x7FFF，其中有一些真正的大间隙。

来自 MFC 的保留 ID 是另一回事。但是你有头文件，你可以查看它使用了什么或没有使用什么。查看当前头文件，使用的命令范围从 0xE000 开始，一直到 0xEFFF。

另外，我看不到其他 ID 范围（图标等）限制的原因。我在 MFC 代码和 Win32 代码中都看不到它们。所以这里的范围只是Win32环境允许的范围。

即使加载资源也始终需要 HINSTANCE 值。在 MFC 中如何评估它是很棘手的，因为它们具有扩展 DLL，但这有助于避免与库存 ID 发生冲突。

Ribbon 的内容使用从 0x3E80 到 0x4650 的 Id（实际上它停在 0x4330）。 这里有趣的是，功能区仅使用此范围内的命令 ID。 （参见 ID_AFX_TOOL...），因此他们不关心命令范围（0x8000 以上）。

因此，根据我拥有的代码库和我的经验，我唯一能说的是：不要与现有 ID 发生冲突。但可以随意使用它们。

因此，即使像 resorg 工具那样重新编号 ID，也不是真正需要的。因为我们附加了帮助生成，即使我们在完全重新编号 ID 时使用生成的帮助头文件，有时也会感到困惑，因此我们将对 ID 范围的更改减少到最小。

所以你可以忽略旧RESORG工具的警告。