有效的MFC ID范围 [英] Valid MFC ID Ranges

问题描述

这让我感到困惑！我正在阅读技术说明并指出:

This is confusing me! I am reading this technical note and it states:

• 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

• 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.

Windows implementation limitations restrict true resource IDs to be less than or equal to 0x7FFF.

MFC的内部框架保留以下范围:

MFC's internal framework reserves these ranges:

• 0x7000到0x7FFF(请参阅afxres.h)

• 0x7000 through 0x7FFF (see afxres.h)

0xE000到0xEFFF(请参阅afxres.h)

0xE000 through 0xEFFF (see afxres.h)

16000到18000(请参阅afxribbonres.h)

16000 through 18000 (see afxribbonres.h)

这些范围在将来的MFC实现中可能会更改.

These ranges may change in future MFC implementations.

几个Windows系统命令使用的范围是0xF000到0xFFFF.

Several Windows system commands use the range of 0xF000 through 0xFFFF.

从1到7的控件ID保留用于IDOK和IDCANCEL之类的标准控件.

Control IDs of 1 through 7 are reserved for standard controls such as IDOK and IDCANCEL.

字符串的0x8000到0xFFFF的范围保留给命令菜单提示.

The range of 0x8000 through 0xFFFF for strings is reserved for menu prompts for commands.

现在我完全困惑了.

• 28672-32767已保留.
• 32768-57343适用于ID_ 命令.
• 57344-61439保留.

• 28672 - 32767 are reserved.
• 32768 - 57343 are for ID_ Commands.
• 57344 - 61439 are reserved.

以上是合理的.但是我们有:

The above makes sense. But then we have:

• 1-32767是字符串
• 32768-65535保留. ??这样就消除了命令范围！

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

Can somebody provide in decimal and in plain English the correct ranges for the various resources?

我问的原因是因为使用ResOrg时会指出:

The reason I am asking is because when using ResOrg it states:

但是，它会将命令标记为超出范围:

Yet, it is flagging commands as out of range:

这些值在 0x8000到0xDFFF 之间.

当我了解范围时，我使用了带有公式的Excel来过滤列表，这就是结果:

I used Excel with formula to filter the list as I understand the ranges and this is the results:

推荐答案

首先:0x8000及更高版本的命令没有必需的范围.

First of all: There is no required range for commands from 0x8000 and up.

此要求是在MFC的某些非常早期的版本中进行的，在该版本中，命令路由检查了此范围以减少通常低于此范围的控件的正常命令ID的往返".

This requirement was in some very early versions of the MFC, where the command routing checked this range to reduce "roundtrips" for normal command IDs of controls, that are usually below this range.

我刚刚重新检查了最早的MFC代码(VM中仍然有VC6.0)，在那儿的MFC代码中也找不到任何限制.

I just rechecked the oldest MFC code (VC6.0 I still have in a VM) and I couldn't find any limitation about this in the MFC code there too.

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

But this is my experience and as you see in your code. Commands with IDs below 0x8000 work... and read my notes below about the ribbon code extension.

命令ID(菜单，工具栏，功能区)必须低于0xF000，因为系统的命令ID等于0xF000.

Command IDs (menu, toolbar, ribbon) must be below 0xF000 because the command IDs for the system are greater equal 0xF000.

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

Even the combination of the menu IDs with the corresponding prompt for the command line or Tooltip isn't a problem. You can use any number in the range of 0x0001 up to 0xDFFF.

MFC中的字符串ID最多扩展为0xFEFF.

String IDs in the MFC extend up to 0xFEFF.

某些对话框，光标和位图在0x7800到0x7FFF的范围内，存在一些较大的空白.

Some dialogs and cursors and bitmaps are in the range of 0x7800 to 0x7FFF with some real large gaps.

从MFC保留的ID是另一回事.但是您有头文件，可以查看是否使用了头文件.查看当前的头文件，使用的命令范围从0xE000开始，直至0xEFFF.

Reserved IDs from the MFC are a different thing. But you have the header files and you can look into it what is used or not. Looking into the current header files, the used command ranges starts at 0xE000 and goes up to 0xEFFF.

我也看不到其他ID范围(图标等)受到限制的原因，在MFC代码和Win32代码中都看不到它们.因此，这里的范围仅是Win32环境所允许的范围.

Also I can't see the reasons for a limitation of other ID ranges (icons etc.) I can't see them neither in the MFC code nor in the Win32 code. So the ranges here are just the ranges that are allowed for the Win32 environment.

即使资源加载也总是需要一个HINSTANCE值.在MFC中对其进行评估是很棘手的，因为它们具有扩展DLL，但有助于避免与库存ID发生冲突.

Even loading of the resources require always a HINSTANCE value. It is tricky how it is evaluated in the MFC because they have extension DLLs, but it helps to get not into conflict to the stock IDs.

功能区的东西使用从0x3E80到0x4650的ID(实际上，它在0x4330处停止). 有趣的是，功能区仅使用此范围内的命令ID. (请参阅ID_AFX_TOOL ...)，因此他们不在乎命令范围(0x8000以上).

The ribbon stuff uses Ids from 0x3E80 to 0x4650 (in fact it stops at 0x4330). The funny thing in here is that the ribbon just uses command IDs in this range. (See ID_AFX_TOOL...), so they don't care about the command range (above 0x8000).

因此，从我拥有的代码库和我的经验中，我唯一能说的就是:不要与现有的ID发生冲突.但是，您可以自由使用它们.

So the only thing I can say from the code base I have and from my experience: Don't get into conflicts with the existing IDs. But use them freely as you like.

因此，甚至不需要像resorg工具那样对ID进行重新编号.因为我们附加了帮助生成"功能，即使在对ID完全重新编号时使用生成的帮助头文件，有时也会使它们感到困惑，所以我们将对ID范围的更改减少到最低限度.

So even renumbering the IDs like the resorg tools does, isn't really needed. Because we have attached Help generation that sometimes get confused even if we use the generated help header files when we renumber IDs completely we reduce changes to the ID range to a cosmetic minimum.

因此，您可能只是忽略了旧的RESORG工具的警告.

So you may just ignore the warning of the old RESORG tool.

这篇关于有效的MFC ID范围的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！