テクニカル ノート 35: Visual C++ における複数のリソース ファイルとヘッダー ファイルの使用
更新 : 2007 年 11 月
メモ : |
---|
次のテクニカル ノートは、最初にオンライン ドキュメントの一部とされてから更新されていません。結果として、一部のプロシージャおよびトピックが最新でないか、不正になります。最新の情報について、オンライン ドキュメントのキーワードで関係のあるトピックを検索することをお勧めします。 |
このテクニカル ノートでは、Visual C++ リソース エディタを使用して、1 つのプロジェクトや複数のプロジェクトで共有される複数のリソース ファイルとヘッダー ファイルをサポートする方法、およびこのサポートを利用する方法について説明します。また、以下のような問題とその対処方法を説明します。
1 つのプロジェクトを複数のリソース ファイルやヘッダー ファイルに分割する方法
2 つの .RC ファイル間で 1 つの .H ファイル (ヘッダー ファイル) を共有する方法
プロジェクト リソースを複数の .RC ファイルに分割する方法
複数の .RC、.CPP、.H ファイル間のビルド依存関係を管理する方法およびツール
プロジェクトにリソース ファイルを後から追加した場合、追加したファイルに含まれているリソースは ClassWizard には認識されませんので注意してください。
上の問題に対する対処方法として、このテクニカル ノートは以下の項目から構成されています。
「Visual C++ によるリソース ファイル、ヘッダー ファイルの管理方法」では、Visual C++ の [表示] メニューの [インクルードファイルの設定] コマンドを使用し、1 つのプロジェクトで複数のリソース ファイルやヘッダー ファイルを使用する方法について説明します。
「AppWizard で生成した .RC ファイルと .H ファイルの解析」では、AppWizard で生成したアプリケーションが使用する複数のリソース ファイルとヘッダー ファイルについて説明します。このファイル構成は、プロジェクトに新しいリソース ファイルやヘッダー ファイルを追加する場合のモデルとして参考になります。
「その他のヘッダー ファイルのインクルード」では、どのような場合に複数のヘッダー ファイルをインクルードするのか解説します。また、実際に複数のヘッダー ファイルを作成する作業についても説明します。
「2 つの .RC ファイルで 1 つのヘッダー ファイルを共有する方法」では、1 つのヘッダー ファイルを異なるプロジェクトまたは 1 つのプロジェクトに属する複数の .RC ファイル間で共有する方法について説明します。
「1 つのプロジェクトで複数のリソース ファイルを使用する方法」では、どのような場合に 1 つのプロジェクトを複数の .RC ファイルに分割するのかについて解説します。また、実際に複数の .RC ファイルを作成する作業についても説明します。
「Visual C++ にファイルを変更させない方法」では、Visual C++ がカスタム リソースを誤って編集しないように設定する方法について説明します。
「Visual C++ で編集した複数の .RC ファイル間でシンボルを共有する方法」では、複数の .RC ファイルで同じシンボルを共有する方法と、ID 値の重複を避ける方法について解説します。
「.RC ファイル、.CPP ファイル、.H ファイルの依存関係の管理」では、リソース シンボル ファイルに依存する .CPP ファイルを不必要に再コンパイルしない方法について説明します。
「インクルード ファイルの管理方法」では、複数の (入れ子になった) .RC ファイルや、.RC ファイルによってインクルードされるヘッダー ファイルを Visual C++ が管理するしくみについて説明します。
Visual C++ によるリソース ファイル、ヘッダー ファイルの管理方法
Visual C++ は、リソース ファイル (.RC ファイル) とそれに対応するヘッダー ファイル (.H ファイル) を結び付けて管理します。作成したリソースを .RC ファイルに保存すると、対応する .H ファイルの中にシンボルが保存されます。複数の .RC ファイルを Visual C++ の MDI ユーザー インターフェイスを使用して同時に編集できますが、この場合も各 .RC ファイルに対応するヘッダー ファイルが間接的に編集されます。
シンボル用のヘッダー ファイル
リソース ファイルに対応するヘッダー ファイルの名前は、既定で RESOURCE.H になり、リソース ファイル名には影響されません。このヘッダー ファイル名は Visual C++ の [表示] メニューの [インクルード ファイルの設定] コマンドを使用して変更できます。[インクルード ファイルの設定] ダイアログ ボックスの [シンボル用のヘッダー ファイル] を更新します。
読み取り専用シンボル ディレクティブ
Visual C++ は .RC ファイルに対して 1 つのヘッダー ファイルだけを編集しますが、それ以外の読み取り専用ヘッダー ファイルで定義されているシンボルを参照することもできます。Visual C++ の [表示] メニューの [インクルード ファイルの設定] をクリックすると、任意の数の読み取り専用ヘッダー ファイルを読み取り専用シンボル ディレクティブとして参照できます。この場合の "読み取り専用" の意味は、.RC ファイル中に新しいリソースを追加するときに、これらのヘッダー ファイルに定義されているシンボルを使用することができるということです。リソースを削除しても、読み取り専用ヘッダー ファイル内のシンボルは削除されません。また、読み取り専用シンボルに割り当てられている数値は変更できません。
コンパイル時ディレクティブ
Visual C++ ではリソース ファイルを入れ子にできます。つまり、リソース ファイルの中に別のリソース ファイルをインクルードできます。Visual C++ を使用して .RC ファイルを編集すると、インクルードされるファイルで定義されているリソースは見ることができません。しかしこの .RC ファイルをコンパイルすると、その中にインクルードされているファイルもコンパイルされます。Visual C++ の [表示] メニューの [インクルード ファイルの設定] をクリックすると、任意の数の .RC ファイルをコンパイル時ディレクティブとしてインクルードできます。
Visual C++ が読み込む .RC ファイルの中で、コンパイル時ディレクティブを使用せずに #include ディレクティブによってほかの .RC ファイルをインクルードしているときは注意してください。従来のようにテキスト エディタを使用して編集した .RC ファイルを Visual C++ に取り込む場合はこの点が問題となります。Visual C++ はインクルードされている .RC ファイルを読み込み、その中に定義されているリソースをインクルード元の .RC ファイルのリソースにマージします。インクルード元の .RC ファイルを保存すると、ファイルの中の #include ステートメントがインクルードされるリソースに置き換えられます。このようなリソースのマージを避けたい場合は、まず .RC ファイルを Visual C++ に読み込む前に .RC ファイル中の #include ステートメントを一度削除します。次に、削除後のファイルを Visual C++ に読み込み、削除した #include ステートメントの代わりにコンパイル時ディレクティブを指定します。
Visual C++ では、[表示] メニューの [インクルード ファイルの設定] を使用して、3 とおりの方法で #include ディレクティブや TEXTINCLUDE リソースによるインクルード情報を .RC ファイル中に書き込むことができます (シンボル ヘッダー ファイル、読み取り専用シンボル ディレクティブ、コンパイル時ディレクティブ)。TEXTINCLUDE リソースの詳細については、「インクルード ファイルの管理方法」を参照してください。
AppWizard で生成した .RC ファイルと .H ファイルの解析
AppWizard で作成したアプリケーション コードを調べることにより、Visual C++ による複数のリソース ファイルやヘッダー ファイルの操作方法がわかります。このテクニカル ノートで引用するコードは、AppWizard が既定のオプションで生成したアプリケーション MYAPP からの抜粋です。
AppWizard で作成したアプリケーションは、次に示す包含関係にある、複数のリソース ファイルとヘッダー ファイルを使います。
RESOURCE.H AFXRES.H
\ /
\ /
MYAPP.RC
|
|
RES\MYAPP.RC2
AFXRES.RC
AFXPRINT.RC
これらのファイルの依存関係は Visual C++ の [表示] メニューの [インクルード ファイルの設定] を使用して調べることができます。
- MYAPP.RC
Visual C++ を使用して編集できるアプリケーション リソース ファイルです。
RESOURCE.H はアプリケーション固有のヘッダー ファイルです。このファイルには AppWizard によって必ず RESOURCE.H という名前が付けられます。RESOURCE.H は Visual C++ のヘッダー ファイル名前付け規則に従って付けられています。リソース ファイル (MYAPP.RC) の先頭には、このヘッダー ファイルに対する #include ディレクティブが記述されます。
//Microsoft Visual C++ generated resource script
//
#include "resource.h"
- RES\MYAPP.RC2
保存されるリソースは、Visual C++ によって操作することができませんが、最終的にコンパイルされる .EXE ファイルに取り込まれます。Visual C++ ですべての標準リソース (このリリースの新機能であるバージョン リソースを含む) を編集できますが、AppWizard は既定で上のようなリソースは作成しません。このファイルにカスタム形式のリソースを追加するときは、AppWizard で空のファイルを作成します。
カスタム形式のリソースを追加するときは、リソースを RES\MYAPP.RC2 に保存して Visual C++ テキスト エディタを使用して編集します。
AFXRES.RC と AFXPRINT.RC にはフレームワーク処理の中で使用される標準リソースが保存されています。RES\MYAPP.RC2 と同じように、これらのリソース ファイルは MYAPP.RC の末尾で #include します。これらのリソースは [インクルード ファイルの設定] ダイアログ ボックスの [コンパイル時に追加するファイル] で指定します。Visual C++ で MYAPP.RC を編集するときは、これらのフレームワーク リソースを直接開いたり編集しないでください。これらのリソースはアプリケーションの .RES バイナリ ファイルや .EXE ファイルにコンパイルされます。標準フレームワーク リソースの内容や変更方法については、「テクニカル ノート 23: MFC の標準リソース」を参照してください。
AFXRES.H にはフレームワークが使用する標準シンボル (ID_FILE_NEW など) が定義されています。これらのシンボルは AFXRES.RC で使用されます。また AFXRES.H は WINRES.H をインクルードします。WINRES.H は WINDOWS.H のサブセットで、AFXRES.RC や Visual C++ で生成した .RC ファイルを使用するときに必要です。AFXRES.H に定義されているシンボルは、アプリケーション リソース ファイル (MYAPP.RC) を編集するときに使用できます。たとえば、MYAPP.RC のメニュー リソースにある [ファイル] メニューの [新規作成] の代わりに ID_FILE_NEW を使用できます。フレームワークで定義されているこれらのシンボルを変更または削除することはできません。
その他のヘッダー ファイルのインクルード
AppWizard で作成したアプリケーションは 2 つのヘッダー ファイル (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)
[表示] メニューの [インクルード ファイルの設定] を使用して #include ステートメントを作成すると、読み取り専用のヘッダー ファイルを第 2 の読み取り専用シンボル ディレクティブとしてインクルードできます。この結果、次のような #include ディレクティブが作成されます。
#include "afxres.h"
#include "second.h"
これによってファイルの包含関係は次のようになります。
AFXRES.H
RESOURCE.H SECOND.H
\ /
\ /
MYAPP.RC
|
|
RES\MYAPP.RC2
AFXRES.RC
AFXPRINT.RC
2 つの .RC ファイルで 1 つのヘッダー ファイルを共有する方法
異なるプロジェクトまたは単一のプロジェクトに属する 2 つの .RC ファイル間でヘッダー ファイルを共有する場合があります。このような場合は、両方の .RC で上で説明した読み取り専用ディレクティブの技法を使用します。2 つの .RC ファイルが異なるアプリケーション (異なるプロジェクト) で使用される場合は、この結果は次のようになります。
RESOURCE.H AFXRES.H RESOURCE.H
(for MYAPP1) SECOND.H (for MYAPP2)
\ / \ /
\ / \ /
MYAPP1.RC MYAPP2.RC
/ \ / \
/ \ / \
RES\MYAPP1.RC2 AFXRES.RC RES\MYAPP2.RC2
AFXPRINT.RC
2 つのヘッダー ファイル (SECOND.H) が同一プロジェクト内の 2 つの .RC ファイルで共有される場合については、次のセクションで説明します。
1 つのプロジェクトで複数のリソース ファイルを使用する方法
Visual C++ とリソース コンパイラでは、.RC ファイルに #include ディレクティブで別の .RC ファイルをインクルードすることにより、1 つのプロジェクトの中で複数の .RC ファイルが使用できます。インクルードは入れ子にできます。次のような場合に、リソースを複数の .RC ファイルに分割する必要があります。
大量のリソースを大勢の開発人員によって作成する場合は、複数の .RC を使用すると管理が容易になります。ソース コードのバージョン管理パッケージを使用しファイルのチェックアウトと変更のチェックインを行うときは、リソースを複数の .RC ファイルに分割することによって、より精密なリソースのバージョン管理ができます。
リソース ファイルの中で #ifdef、#endif、#define などのプリプロセス ディレクティブを使用するときは、その部分を読み取り専用のリソース ファイルとして分離し、リソース コンパイラでコンパイルする必要があります。
1 つの巨大な .RC ファイルよりも、分割された .RC ファイルの方が、Visual C++ における読み込みや保存が高速です。
テキスト エディタを使用してユーザーが認識できる形式でリソースを管理する場合は、その部分を Visual C++ が編集するリソースと分離して保存する必要があります。
バイナリ形式またはテキスト形式でユーザー定義のリソースを専用のデータ エディタを使用して編集する場合は、それらのリソースを独立した .RC ファイルに保存し、Visual C++ の編集によって 16 進形式に変換されないようにします。たとえば『MFC サンプル』の「SPEAKN サンプル : ユーザー定義のリソースを使用したマルチメディア サウンドの例」の .WAV ファイルのリソース (サウンド リソース) がこの場合に該当します。
SECOND.RC は [インクルード ファイルの設定] ダイアログ ボックスの [コンパイル時に追加するファイル] でインクルードできます。
#include "res\myapp.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
|
|
RES\MYAPP.RC2
SECOND.RC
AFXRES.RC
AFXPRINT.RC
コンパイル時ディレクティブを使用し Visual C++ に編集させるリソースと編集させないリソースを異なる .RC ファイルにまとめることができます。この場合、"マスター リソース ファイル" である MYAPP.RC にはほかの .RC ファイルをインクルードする #include ディレクティブだけを記述します。Visual C++ プロジェクトの .MAK ファイルを使用するときは、マスターの .RC ファイルをプロジェクトにインクルードするだけですべてのリソースがインクルードされ、アプリケーションと一緒にコンパイルされます。
Visual C++ にファイルを変更させない方法
前の例に示した AppWizard が生成する RES\MYAPP.RC2 ファイル内のリソースは、誤って Visual C++ に読み込まれて更新された場合、書式情報が失われます。これを防ぐには、RES\MYAPP.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 ファイル間でシンボルを共有する方法
リソースを複数の .RC ファイルに分割して Visual C++ で個別に編集する場合、次の 2 つの問題があります。
複数の .RC ファイルで共通のシンボルを使用する場合がある。
異なるリソース (シンボル) に同一の ID 値が割り当てられることを防ぐ必要がある。
次に示す .RC ファイルと .H ファイルの編成は、最初の問題に対する対策の例です。
MYAPP.RC
/ \
/ \
MYSTRS.H / MYSHARED.H \ MYMENUS.H
\ / / \ \ \
\ / / \ \ \
MYSTRS.RC MYMENUS.RC
文字列リソースは MYSTRS.RC に、メニュー リソースは MYMENUS.RC に保存されている場合、この 2 つのファイルの間では、コマンド シンボルなどを共有する必要があります。たとえば [ツール] メニューの [スペルチェック] コマンドを表す ID_TOOLS_SPELL は、アプリケーションのメイン ウィンドウでステータス バーに表示される、コマンド プロンプト文字列の ID でもあります。
ID_TOOLS_SPELL シンボルは共有ヘッダー ファイル MYSHARED.H に保存されています。このヘッダー ファイルをテキスト エディタを使用して編集する場合は、Visual C++ はこのファイルを直接編集しません。このため 2 つのリソース ファイル MYSTRS.RC と MYMENUS.RC 内で、前に説明した [表示] メニューの [インクルード ファイルの設定] を使用し、MYAPP.RC に対する読み取り専用ディレクティブで #include MYSHARED.H を指定します。
複数のファイルで共有する可能性のあるシンボルは、前もって共有ヘッダー ファイルに記述すると便利です。使用するシンボルに対するヘッダー ファイルがまだインクルードされていない場合は、シンボルを使用する前に、.RC ファイルに対する読み取り専用ディレクティブでインクルードします。このように前もってシンボルを共有していない場合、.RC ファイルで使用する前に、そのシンボルの #define ステートメントを (たとえば MYMENUS.H から MYSHARED.H に) 移動する必要があります。
また、複数の .RC ファイル内のシンボルを管理するときは、Visual C++ が同じ ID 値を異なるリソース (シンボル) に割り当てないように注意してください。.RC ファイルに対して Visual C++ は、4 つの ID 領域それぞれに 1 ずつ増える ID 値を割り当てていきます。Visual C++ は、編集処理終了後、次の編集処理までその .RC ファイルに対するシンボル ヘッダー ファイルの各領域で最後に割り当てた ID 値を記憶します。新しい (空の) .RC ファイルを開いたときに使用される "App Studio Next" 値 (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 は、ダイアログ リソースやメニュー リソースなどに対して割り当てられる次のシンボル値です。このリソース シンボル値の有効範囲は 1 から 0x6FFF までです。
_APS_NEXT_COMMAND_VALUE は、コマンド ID に対して割り当てられる次のシンボル値です。コマンド シンボル値の有効範囲は 0x8000 から 0xDFFF までです。
_APS_NEXT_CONTROL_VALUE は、ダイアログ コントロールに対して割り当てられる次のシンボル値です。ダイアログ コントロール シンボル値の有効範囲は 8 から 0xDFFF までです。
_APS_NEXT_SYMED_VALUE は、[シンボル ブラウザ] の [新規] コマンドを使用して直接シンボル値を割り当てたときに与えられる数値です。
新しい .RC ファイルを作成したとき最初に割り当てられる ID 値は、上の有効範囲の最小値よりも大きな値になります。また AppWizard は MFC (Microsoft Foundation Class) アプリケーションに対して適切な初期 ID 値を使用します。ID 値の有効範囲については、「テクニカル ノート 20: ID 名および番号に関する規約」を参照してください。
新しいリソース ファイルを作成するたびに、同一プロジェクト内でも同じ _APS_NEXT_ 値が定義されます。つまり、2 つの異なる .RC ファイルにそれぞれダイアログを追加すると、同じ ID を個別のダイアログに割り当てる #define ステートメントが生成されてしまいます。たとえば、第 1 の .RC ファイルの IDD_MY_DLG1 と第 2 の .RC ファイルの IDD_MY_DLG2 には同じ値 101 が割り当てられてしまいます。
これを避けるために、各 ID 領域に対して .RC ファイルごとに異なる範囲の ID 値が割り当てられるようにします。つまり、各 .RC ファイルにリソースを追加する前に _APS_NEXT 値を直接指定します。たとえば、第 1 の .RC ファイルに既定の _APS_NEXT 値を使用するときは、第 2 の .RC ファイルに次の _APS_NEXT 値を指定します。
#define _APS_NEXT_RESOURCE_VALUE 2000
#define _APS_NEXT_COMMAND_VALUE 42000
#define _APS_NEXT_CONTROL_VALUE 2000
#define _APS_NEXT_SYMED_VALUE 2000
このように設定した場合も、第 1 の .RC ファイルで大量の ID が割り当てられた場合は、第 2 の .RC で使用する範囲の値と重複します。したがって、_APS_NEXT 値の範囲を十分確保しておく必要があります。
.RC ファイル、.CPP ファイル、.H ファイルの依存関係の管理
Visual C++ は .RC ファイルを保存するときに、シンボルの変更内容を RESOURCE.H にも保存します。この .RC ファイル内のリソースを参照している .CPP ファイルは、プロジェクトのメイン ヘッダー ファイルを介して RESOURCE.H をインクルードしています。このため、Visual C++ の内部プロジェクト管理機構による副作用が発生します。プロジェクト管理機構はソース ファイルを走査してヘッダーの依存関係を調べるため、新しいシンボルが追加されると RESOURCE.H をインクルードしているすべての .CPP ファイルを再コンパイルする必要があります。
RESOURCE.H の先頭の行に次のコメントが記述される場合、Visual C++ は RESOURCE.H に対する依存性をチェックしません。
//{{NO_DEPENDENCIES}}
このコメントがある場合、Visual C++ は RESOURCE.H が更新されても依存する .CPP ファイルの再コンパイルを行いません。
Visual C++ は .RC ファイルを保存するとき、必ず先頭にコメント行 //{{NO_DEPENDENCIES}} を追加します。RESOURCE.H に対する依存性のチェックを抑止すると、リンク時に検出することができないランタイム エラーが発生する可能性があります。たとえば、[シンボル ブラウザ] を使用してリソース シンボルに割り当てられている数値を変更した場合、そのリソースを使用している .CPP ファイルを再コンパイルしない限り、実行時にリソースを正しく検出したり、読み込んだりすることはできません。この問題を解消するには、RESOURCE.H のシンボルの変更により影響を受ける .CPP ファイルを直接再コンパイルするか、[すべてリビルド] を実行します。特定されたグループのリソース シンボル値を頻繁に変更する場合は、そのグループのシンボルを独立した読み取り専用ヘッダー ファイルに保存します。この方法については、「その他のヘッダー ファイルのインクルード」を参照してください。
インクルード ファイルの管理方法
前に述べたように、[表示] メニューの [インクルード ファイルの設定] コマンドを使用して次の 3 種類の情報が指定できます。
シンボル用のヘッダー ファイル
読み取り専用シンボル ディレクティブ
コンパイル時ディレクティブ
ここでは Visual C++ が .RC ファイル内にあるこの 3 種類の情報を管理する方法について説明します。この説明は、Visual C++ を使用する上で不可欠な知識というわけではありませんが、より詳細なインクルード ファイルの設定機能のしくみを理解するために役に立ちます。
上の 3 つのインクルード ファイルの設定情報は次の 2 種類の形態で .RC ファイル内に保存されます。(1) リソース コンパイラが理解できる #include などのディレクティブ。(2) Visual C++ だけが理解できる TEXTINCLUDE リソース。
TEXTINCLUDE リソースの目的は、Visual C++ の [インクルード ファイルの設定] ダイアログ ボックスに表示される情報を安全な形式で保存することです。TEXTINCLUDE は Visual C++ によって定義されるリソースの種類です。Visual C++ は次の 3 つの TEXTINCLUDE リソースを認識します。これらのリソース ID 値はそれぞれ 1、2、3 です。
TEXTINCLUDE リソース ID |
インクルード ファイル設定情報のタイプ |
---|---|
1 |
シンボル用のヘッダー ファイル |
2 |
読み取り専用シンボル ディレクティブ |
3 |
コンパイル時ディレクティブ |
これらのインクルード ファイル設定情報は AppWizard で作成した既定の MYAPP.RC ファイルと RESOURCE.H ファイルの中に記述されています。この内容を次に示します。BEGIN と END で囲まれたブロックの中には、これらの情報以外にトークン "" と \0 が挿入されています。これは、RC 構文では文字列を二重引用符で囲み、末尾に NULL を付ける必要があるためです。
シンボル用のヘッダー ファイル
リソース コンパイラが解釈できるシンボル ヘッダー ファイル情報は、#include ステートメントです。
#include "resource.h"
これに対応する TEXTINCLUDE リソースは次のようになります。
1 TEXTINCLUDE DISCARDABLE
BEGIN
#resource.h\0"
END
読み取り専用シンボル ディレクティブ
読み取り専用シンボル ディレクティブは MYAPP.RC の先頭でインクルードされます。リソース コンパイラが解釈できる形式では次のようになります。
#include "afxres.h"
これに対応する TEXTINCLUDE リソースは次のようになります。
2 TEXTINCLUDE DISCARDABLE
BEGIN
"#include ""afxres.h""\r\n"
"\0"
END
コンパイル時ディレクティブ
コンパイル時ディレクティブは MYAPP.RC の末尾でインクルードされます。リソース コンパイラが解釈できる形式は次のようになります。
#ifndef APSTUDIO_INVOKED
///////////////////////
//
// From TEXTINCLUDE 3
//
#include "res\myapp.rc2" // non-Visual C++ edited resources
#include "afxres.rc" // Standard components
#include "afxprint.rc" // printing/print preview resources
#endif // not APSTUDIO_INVOKED
プリプロセス ディレクティブ #ifndef APSTUDIO_INVOKED がある場合、Visual C++ はコンパイル時ディレクティブを無視します。
これに対応する TEXTINCLUDE リソースは次のようになります。
3 TEXTINCLUDE DISCARDABLE
BEGIN
"#include ""res\myapp.rc2"" // non-Visual C++ edited resources\r\n"
"\r\n"
"#include ""afxres.rc"" // Standard components\r\n"
"#include ""afxprint.rc"" // printing/print preview resources\r\n"
"\0"
END