MFC-TN035-在Visual-C++中使用多个资源文件和头文件

MFC TN035 在Visual C+中使用多个资源文件和头文件翻译：kingyo本文描述了Visual C+是如何支持在一个工程或者多个工程中共享多个资源文件和头文件的，以及我们如何利用它。本文回答如下这些问题：l 当想把一个工程拆分成多个资源文件和头文件时，该怎么做？l 如何在两个.RC文件中共享一个公共头文件？l 如何将工程资源拆分成多个.RC文件？l Visual C+是如何管理.RC，.CPP，.H文件之间的编译依赖的？应该清楚，如果为工程增加一个额外的资源文件，ClassWizard是不会理会这个文件中的资源的。下面的几点是用来回答以上的问题的：l Visual C+管理资源文件和头文件的概述 描述了Visual C+的“Resource Includes”（资源包含）命令是如何让我们可以在一个工程中使用多个资源文件和头文件的。l AppWizard创建的.RC文件和.H文件的分析 考察由AppWizard创建的应用程序所使用的多个资源文件和头文件，这些文件是我们要加入到工程中的资源文件和头文件的绝好参照。l 包含额外的头文件 描述了该在什么时候增加多个头文件，以及详细做法。l 在两个.RC文件之间共享一个头文件 展示了如何在不同工程（也可能是同一个工程）的多个.RC文件中共享一个头文件。l 在同一个工程中使用多个资源文件 描述了该在什么时候将工程拆分成多个.RC文件，以及详细做法。l 设置成不允许Visual C+编辑的文件 描述了如何确定Visual C+不会无意中改掉一个自定义的资源。l 管理在Visual C+可编辑.RC文件中共享的符号 描述了如何在多个.RC文件中共享相同的符号，以及如何避免出现重复的ID值。l 管理.RC，.CPP，.H文件依赖 描述了Visual C+是如何避免对依赖资源符号的.CPP文件产生不必要的重编译。l Visual C+如何管理资源包含信息 展示了Visual C+是如何跟踪多个（嵌套）.RC文件和一个.RC文件中包含的多个头文件的。Visual C+管理资源文件和头文件的概述Visual C+以捆绑的方式管理一个单独的.RC文件及其相应的.H文件。当修改并保存.RC文件中的资源时，会间接地修改并保存了相应.H文件。虽然可以同时打开多个.RC文件（用Visual C+的MDI界面），但是对于给定的.RC文件只能间接修改一个相应的头文件。符号头文件（Symbol Header File）默认时Visual C+总是将相应的头文件命名为RESOURCE.H而不管资源文件的名字（如MYAPP.RC）。使用Visual C+的“Resource Includes”命令，可以通过在“Resource Includes”对话框中更新“Symbol Header File”来改变这个默认头文件的名字。只读符号指令（Read-Only Symbol Directives）虽然Visual C+只为给定的.RC文件维护一个头文件，但是它也支持引用其他的只读头文件。使用“Resource Include”命令，你能在“Read-Only Symbol Directives”中指定任意数量的其他只读头文件。“只读”的限制表明当在.RC文件中增加一个新资源时，能使用在只读头文件中定义的符号，但是当删除资源时，这个符号仍然留在只读头文件中。不能改变只读符号的值。编译时指令（Compile-Time Directives）Visual C+也支持资源文件的嵌套，一个.RC文件可以被另外一个#include（包含）。当用Visual C+编辑一个给定的.RC文件时，任何在#include语句中的资源都是不可见的，但是当编译.RC文件时，这些在#include语句中的资源也被编译。使用“Resource Include”命令，能指定任意数量的.RC文件作为编译时指令。要注意当Visual C+读入一个包含了其他.RC文件但不指定为编译时指令的.RC文件时会发生什么，产生这种情况的原因可能是给了Visual C+一个以前用文本编辑手工维护的.RC文件。当Visual C+读入被包含的.RC文件时会将它与父.RC文件合并。当保存父.RC文件时，#include语句就会由被包含的资源替代。如果不希望这种合并发生，应当在Visual C+读入之前把#include语句从父.RC文件中删除。然后再用Visual C+把同样的#include语句加到“Compile-Time Directives”。Visual C+在#include指令符和TEXTINCLUDE资源中保存一个.RC文件中用到的上述三种资源包含信息（符号头文件、只读符号指令、编译时指令）。TEXTINCLUDE资源，一般情况下不需要处理，这在Visual C+如何管理资源包含信息中有说明。AppWizard创建的.RC文件和.H文件的分析查看AppWizard产生的应用程序代码能使我们了解Visual C+是如何管理多个资源文件和头文件的。下面的代码是从一个由AppWizard在默认选项下产生的MYAPP应用层程序中摘录的。一个AppWizard创建的应用程序使用多个资源文件和头文件，就像下图显示的那样：RESOURCE.H AFXRES.H / / MYAPP.RC | | RESMYAPP.RC2 AFXRES.RC AFXPRINT.RC能通过Visual C+的“Resource Include”命令参看这几个文件之间的关系。MYAPP.RC应用程序的资源文件，用Visual C+编辑。RESOURCE.H是应用程序专用的头文件，AppWizard总是称之为RESOURCE.H，这与Visual C+默认的头文件一致。#include是这个资源文件（MYAPP.RC）的第一个语句：/Microsoft Visual C+ generated resource script/#include resource.hRESMYAPP.RC2包含了不由Visual C+编辑但是包含到最终编译的.EXE中的资源。AppWizard默认不产生这样的资源，因为Visual C+能处理所有的标准资源，包括版本信息。AppWizard只产生一个空文件，万一需要自定义格式的时可用。当需要自定义格式的资源，将其加入到RESMYAPP.RC2，并用Visual C+的文本编辑器编辑。AFXRES.RC和AFXPRINT.RC包含框架所需特定特性的标准资源。与RESMYAPP.RC2一样，这两个框架提供的资源文件包含在MYAPP.RC的结尾，同时他们也在“Resource Include”对话框的“Compile-Time Directives”中指定。这样在Visual C+中编辑MYAPP.RC时，不能直接看到或者编辑这些框架提供的资源，但是他们会被编译到应用程序的二进制.RES文件和最终的.EXE中。更多关于框架的标准资源，包括修改的方法，请看Technical Note 23.AFXRES.H定义了框架尤其是AFXRES.RC使用的标准符号，如ID_FILE_NEW。AFXRES.H也#include WINRES.H，它是WINDOWS.H的一个子集，包含了Visual C+产生的.RC文件所需的符号。在编辑应用程序资源文件(MYAPP.RC)时，AFXRES.H中定义的符号是有效的，如ID_FILE_NEW在MYAPP.RC中的菜单资源“File New”中用到。不能改变或者删除这些框架定义的符号。包含额外的头文件AppWizard创建的应用程序只包含两个头文件：RESOURCE.H和AFXRES.H，只有RESOURCE.H是应用程序的。在下面的一些情况下，可能需要包含只读的头文件：头文件由外部提供，或者希望在多个工程或者一个工程的多个部分共享头文件。头文件中包含不希望Visual C+更改的或者在保存时要过滤的格式和内容。例如，也许希望保留使用符号运算的#define：#define RED 0#define BLUE 1#define GREEN 2#define ID_COLOR_BUTTON 1001#define ID_RED_BUTTON (ID_COLOR_BUTTON + RED)#define ID_BLUE_BUTTON (ID_COLOR_BUTTON + BLUE)#define ID_GREEN_BUTTON (ID_COLOR_BUTTON + GREEN)可以通过“Resource Include”命令在只读符号指令中指定第二个#include语句来包含额外的只读头文件：#include afxres.h#include second.h新的关系图现在看起来像这样：AFXRES.H RESOURCE.H SECOND.H / / MYAPP.RC | | RESMYAPP.RC2 AFXRES.RC AFXPRINT.RC在两个.RC文件之间共享一个头文件也许希望在不同工程或者同一工程的两个.RC文件之间共享一个头文件。要做到这点，仅需对两个.RC都使用上述的只读符号指令。当两个.RC文件是来源于不同的应用程序（不同的工程）时，结果如下图所示：RESOURCE.H AFXRES.H RESOURCE.H (for MYAPP1) SECOND.H (for MYAPP2) / / / / MYAPP1.RC MYAPP2.RC / / / / RESMYAPP1.RC2 AFXRES.RC RESMYAPP2.RC2 AFXPRINT.RC第二个头文件被一个程序（工程）的两个.RC文件共享的情况在下面讨论。在同一个工程中使用多个资源文件通过一个.RC文件#include另外一个.RC文件的方式，Visual C+和资源编译器支持同一个工程中使用多个资源文件，多重嵌套也是允许的。将工程资源文件拆分成多个资源文件的原因有几个：l 将资源文件拆分成多个.RC文件，更容易在多个工程团队成员之间管理大量的资源。如果使用源代码控制管理来签出文件和签入更改，将资源拆分成多个.RC文件能更好的管理资源的改动。l 如果希望使用预处理指令作为将资源分成几部分，如#ifdef，#endif，#define，必须把他们隔离到会被资源编译器编译的只读资源中。l Visual C+加载和保存分散的.RC文件比一个集中的.RC更快。l 如果希望用文本编辑器以易读的方式维护一个资源，则应该在Visual C+编辑的.RC文件之外保存。l 如果需要一个由其他数据编辑器解释的二进制或者文本格式的用户自定义资源，也需要分离到单独的.RC文件中，防止Visual C+将其修改为十六进制数据格式。在MFC高级主题示例SPEAKN中的.WAV(声音)文件资源就是一个很好的例子。可以在“Resource Include”对话框的“Compile-Time Directives”中#include第二个资源文件SECORND.RC:#include resmyapp.rc2 / non-Visual C+ edited resources#include second.rc / THE SECOND .RC FILE#include afxres.rc / Standard components#include afxprint.rc / printing/print preview resources结果显示在下图：RESOURCE.H AFXRES.H / / MYAPP.RC | | RESMYAPP.RC2 SECOND.RC AFXRES.RC AFXPRINT.RC使用“Compile-Time Directives”，可以将Visual C+可编辑和不可编辑的资源组织到多个.RC文件，这里“主”MYAPP.RC只包含其他.RC文件，不做其他事情。如果正在使用Visual C+工程的.MAK文件，那么需要在工程中包含“主”.RC文件，这样所有的被包含的资源都会编译到程序中。设置成不允许Visual C+编辑的文件AppWizard创建的RESMYAPP.RC2就是一个示例文件，包含你不希望Visual C+意外读入并写回的内容。为了保护这个，将下面几行放到RESMYAPP.RC2文件的的开头：#ifdef APSTUDIO_INVOKED #error this file is not editable by Visual C+#endif /APSTUDIO_INVOKED当Visual C+编译.RC文件时，定义了APSTUDIO_INVOKED和RC_INVOKED。如果AppWizard创建的文件结构不正确，当Visual C+读取到上面的#error行时，会报告一个错误并中止读取.RC文件。管理在Visual C+可编辑.RC文件中共享的符号想要在Visual C+中分别编辑而将资源拆分到多个.RC文件会有两个问题：l 希望跨多个.RC文件共享相同的符号。l 需要协助Visual C+避免给不同的资源符号赋相同的ID值。下图描述了处理第一个问题的.RC和.H的组织方式：MYAPP.RC / / MYSTRS.H / MYSHARED.H MYMENUS.H / / / / MYSTRS.RC MYMENUS.RC这个例子中，字符串资源位于MYSTR.RC中，菜单资源在MYMENU.RC中，一些符号（像表示命令的符号），需要在这两个文件中共享。例如，ID_TOOLS_SPELL可能是一个工具菜单中拼写菜单项的命令ID，同时，它也是应用程序主窗体状态栏中显示的状态提示的字符串ID。ID_TOOLS_SPELL符号位于共享的头文件MYSHARED.H中，用文本编辑器手动维护该文件，Visual C+不直接编辑它。为了MYAPP.CPP，在MYSTRS.RC和MYMENU.RC的“Read-Only Symbol Directives”中#include MYSHARED.H，就像之前描述的那样。在使用一个符号来表示资源之前如果能预计到它将被共享，这将带来很大便利。将这个符号加到共享头文件中，如果你还没有在.RC文件的“Read-Only Symbol Directives”中#include这个共享的头文件，那么需要在使用这个符号之前先#include好。如果不能预计到，那么在MYSTRS.RC文件使用这个符号之前，必须手工（使用文本编辑器）把#define语句从MYMENU.H移到MYSHARED.H中。在多个.RC文件中管理符号时，必须协助Visual C+避免给不同的资源赋相同的ID值。对于任何一个.RC文件，Visual C+分别为四个ID域增量式赋值。在编辑过程中，Visual C+在.RC文件的头文件中记录着每个域最后赋值的ID。这就是一个空的（新的）.RC文件的_APS_NEXT值：#define _APS_NEXT_RESOURCE_VALUE 101#define _APS_NEXT_COMMAND_VALUE 40001#define _APS_NEXT_CONTROL_VALUE 1000#define _APS_NEXT_SYMED_VALUE 101_APS_NEXT_RESOURCE_VALUE是对话框资源、菜单资源等用到的下一个ID值，资源ID值的有效范围是1-0x6FFF。_APS_NEXT_COMMAND_VALUE是命令标示用到的下一个ID值，命令ID值的有效范围是0x8000-0xDFFF。_APS_NEXT_CONTROL_VALUE是对话框控件用到的下一个ID值，对话框控件ID值的有效范围是8-0xDFFF。_APS_NEXT_SYMED_VALUE是在“Resource Symbol”对话框中新建一个ID值时用到的下一个ID值。Visual C+在创建一个新的.RC文件时会从比最低范围稍微高一点的开始赋值。AppWizard也会用更适合MFC应用程序的来初始化这些值。有关ID值的范围，请看Technical Note 20。每次创建一个新的资源文件，就算是在同一个工程中，Visual C+都会定义相同的_APS_NEXT值。这就是说，当你在两个不同.RC文件中增加对话框时，他们很可能都将具有相同的#define值。例如，在第一个.RC文件中的IDD_MY_DLG1和第二个.RC文件中的IDD_MY_DLG2很可能都赋相同的值101。为了避免这种情况，必须为各个.RC文件的四个域分配不同的数值范围。要实现此目的，在增加资源之前就手动更新_APS_NEXT值。例如，如果第一个.RC文件使用默认的_APS_NEXT值，那么第二个.RC文件应该赋为下面的值：#define _APS_NEXT_RESOURCE_VALUE 2000#define _APS_NEXT_COMMAND_VALUE 42000#define _APS_NEXT_CONTROL_VALUE 2000#define _APS_NEXT_SYMED_VALUE 2000当然，如果第一个.RC文件中分配了太多的ID，ID值也会越界到第二个.RC文件的ID范围中，必须保留足够大的范围以避免这种情况的出现。管理.RC，.CPP，.H文件依赖当Visual C+保存一个.RC文件时，它也同时保存相应RESOURCE.H中的符号。任何引用.RC中资源的.CPP文件必须包含相应的RESOURCE.H，这通常是从工程主头文件中包含。由于开发环境内部的工程管理会为了头文件依赖扫描源文件，这将导致一个不合理的副作用：每次在Visual C+中增加一个新的符号时，所有包含RESOURCE.H的.CPP都会重新编译。在Visual C+中，为了阻止依赖于RESOURCE.H，可以将下面的注释行包含到RESOURCE.H文件的第一行：/NO_DEPENDENCIES开发环境解释这句注释并忽略RESOURCE.H的更改，这样依赖于它的.CPP文件就不会重新编译。Visual C+在保存一个.RC文件时总会给他加上/NO_DEPENDENCIES注释行。有时候，阻止对于RESOURCE.H的依赖会导致链接时无法发现的运行时错误。例如，如果用“Resource Symbol”修改了一个资源ID的值，而对应的资源文件没有被重新编译，那么在运行时就不能正确的找到并加载该资源。在这种情况下，必须显式重新编译所有依赖于该资源的.CPP或者重新编译全部。如果会很频繁修改某些资源的符号值，将这些符号拆分到一个独立的只读头文件中会更加便捷和安全，就像上面几节描述的那样。Visual C+如何管理资源包含信息通过以上讨论的，知道Resource Include命令可以指定三种信息：l 符号头文件l 只读符号指令l 编译时指令下面描述了Visual C+是如何在一个.RC文件中维护这些信息的，这些信息对于使用Visual C+不是必须的，但是能让你更好的理解、更有把握地使用资源包含特性。上述三种资源包含信息在.RC文件中保存成两种格式：(1)以#include或者其他资源编译器能解释的指令，(2)以只能由Visual C+解释的特殊TEXTINCLUDE资源。TEXTINCLUDE资源的目的是将资源包含信息安全地存储为Visual C+资源包含对话框能理解的格式。TEXTINCLUDE是Visual C+定义的一种资源类型，Visual C+能识别三种特殊的TEXTINCLUDE资源，其资源标示为1,2,3：T