テクニカル ノート 35: Visual C++ における複数のリソース ファイルとヘッダー ファイルの使用
[!メモ]
次のテクニカル ノートは、最初にオンライン ドキュメントの一部とされてから更新されていません。結果として、一部のプロシージャおよびトピックが最新でないか、不正になります。最新の情報について、オンライン ドキュメントのキーワードで関係のあるトピックを検索することをお勧めします。
ここでは、一つのプロジェクトでこのサポートを利用できるかをどのように共有したり、複数のプロジェクト間で共有される Visual C++ リソース エディターは複数のリソース ファイルとヘッダー ファイル、およびついて説明します。ここでは、これらの質問に答える:
いつ複数のリソース ファイルとヘッダー ファイルにプロジェクトを分割し、どのように、または。
共通ヘッダーを共有するか。2 個の .RC ファイル間の H ファイルか。
どのように複数の .RC ファイルにプロジェクト リソースを分割できます。
どのようにする方法、およびツール （） .RC、 .cpp ビルド間の依存関係を管理します。H ファイルか。
プロジェクトに追加情報ファイルを追加すると、 ClassWizard は、追加したファイルのリソースを認識しないことに注意する必要があります。
ここでは、次のように上の質問に回答するために構成されます:
Overview of How Visual C++ Manages Resource Files and Header Files は、リソース セットが Visual C++ に反映するためにコマンドを同じで複数のリソース ファイルとヘッダー ファイルを使用することを許可するように含める方法の概要を示します。
Analysis of AppWizard-created .RC and .H Files は、 AppWizard 作成されたアプリケーションで使用されるヘッダー ファイル、および複数のリソースが表示されます。これらのファイルは、プロジェクトに追加できるヘッダー ファイルと追加情報ファイルの商品のモデルとして動作します。
Including Additional Header Files がどこで複数のヘッダー ファイルをインクルードする場合があります。説明し、または方法を詳細を提供します。
Sharing a Header File Between Two .RC Files は異なるプロジェクトで複数の .RC ファイル間の 1 種類のヘッダー ファイルを共有できると、同じプロジェクトでかを示します。
Using Multiple Resource Files in the Same Project がどこで複数の .RC ファイルにプロジェクトを分割することがあります。説明し、または方法を詳細を提供します。
Enforcement of Non-Editable Visual C++ Files がどのように Visual C++ では、カスタム リソースを編集せず、意図せずにドキュメントし直さないようにする方法について説明します。
複数のManaging Symbols Shared by Multiple Visual C++-Edited .RC Files は .RC ファイルにわたって同じシンボルを共有する方法と、重複する ID に数値を割り当てる回避する方法について説明します。
Managing Dependencies Between .RC, .CPP, and .H Files は、 Visual C++ がリソース シンボル ファイルに依存する不要な再コンパイル .cpp ファイルを回避する方法について説明します。
How Visual C++ Manages Set Includes Information は、 Visual C++ は .RC ファイルによって #include'd 実行する複数のヘッダー ファイルおよび複数の （入れ子になった） .RC ファイルの追跡するか、技術的な詳細を提供します。
Visual C++ がリソース ファイルとヘッダー ファイルを管理する方法の概要
Visual C++ では、 .RC のリソース ファイルおよびそれを管理します。ファイルの密に結合ペアとして H のヘッダー ファイル。.RC ファイルのリソースを編集、保存すると、間接的に対応のシンボルを編集して保存します。H ファイル。開いて編集できますが複数の .RC は、間接的に対応する 1 とおりのヘッダー ファイルを正確に編集する特定の .RC ファイルの場合 （Visual C++ の MDI のユーザー インターフェイスを使用）一度に格納します。
シンボル ヘッダー ファイル
既定では、 Visual C++ はリソース ファイル （MYAPP.RC）の名前に関係なく対応するヘッダー ファイルを RESOURCE.H、常に指定します。Visual C++ の 表示 のメニューの Resource Includes コマンドを使用して、 Set Includes のダイアログ ボックスのシンボル ヘッダー ファイルのファイルを更新することで、このヘッダー ファイルの名前を変更できます。
読み取り専用シンボルのディレクティブ
Visual C++ が特定の .RC ファイルの 1 種類のヘッダー ファイルのみを編集すると、 Visual C++ は追加読み取り専用ヘッダー ファイルに定義されているシンボルへの参照をサポートします。Visual C++ の 表示 のメニューの Resource Includes コマンドを使用して、読み取り専用シンボルのディレクティブとして追加読み取り専用ヘッダー ファイルをいくつでも指定できます。「読み取り専用」制限は .RC ファイルの新しいリソースを追加すると、読み取り専用ヘッダー ファイルで定義されたシンボルを使用できることを意味します; ただし、リソースを削除すると、シンボルがまだ読み取り専用ヘッダー ファイルに定義されています。読み取り専用シンボルに割り当てられた数値を変更できません。
コンパイル時ディレクティブ
Visual C++ では、 1 種類の .RC ファイルが別の内の #include'd にあるリソース ファイルの入れ子をサポートします。Visual C++ を使用して特定の .RC ファイルを編集すると、 #include'd ファイルのリソースは表示されません。ただし、 .RC ファイルをコンパイルするときに、 #include'd ファイルは、コンパイルされます。Visual C++ の 表示 のメニューの Resource Includes コマンドを使用して、コンパイル時ディレクティブとして #include'd .RC ファイルをいくつでも指定できます。
Visual C++ に .RC ファイルを、コンパイル時の #include ディレクティブとして指定されていない別の .RC ファイル読込めば処理をメモ。この状況は、 Visual C++ には、テキスト エディターと前に手動で保持されていた .RC ファイルを取り込むと発生する場合があります。Visual C++ は #include'd .RC ファイルを読み取る場合、親 .RC ファイルに #include'd のリソースをマージします。親 .RC ファイルを保存すると、 #include ステートメントは、実際には、 #include'd のリソースで置き換えられます。このマージに発生しない Visual C++ に、コードを読む 前に 親 .RC ファイルの #include ステートメントを削除する必要があります。; その後、 Visual C++ を使用して、コンパイル時ディレクティブと同じ #include ステートメントを追加します。
Visual C++ は、上記の設定の 3 種類がの #include ディレクティブ と TEXTINCLUDE のリソースに情報 （シンボル ヘッダー ファイル、読み取り専用シンボルのディレクティブとディレクティブ コンパイル時）を含める .RC ファイルに格納します。TEXTINCLUDE のリソース、通常処理する必要はない実装の詳細は 設定された Visual C++ の管理情報がどのように含まれているかに示します。
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 は、アプリケーション固有のヘッダー ファイルです。これには、 Visual C++ ヘッダー ファイルの既定の名前に一貫した AppWizard によって RESOURCE.H と常にという名前です。このヘッダー ファイルの #include は、リソース ファイル （MYAPP.RC）の最初のステートメントです:
//Microsoft Visual C++ generated resource script
//
#include "resource.h"
- RES \MYAPP.RC 2
Visual C++ で編集できませんが、または終了してコンパイルされた .exe ファイルに含まれているリソースを返します。AppWizard は、 Visual C++ の標準すべてのリソースを編集できるため、バージョン リソース （このリリースの新しい機能）を含むそのようなリソースが既定で作成されません。空のファイルは、 AppWizard に、カスタムして書式設定リソースを所有するには、このファイルに追加場合に生成されます。
カスタムして書式設定リソースを使用すると、 RES \MYAPP.RC2 and edit them using the Visual C ++ のテキスト エディターに追加できます。
AFXRES.RC と AFXPRINT.RC は、フレームワークの一部の機能に必要な標準リソースが含まれます。RES \MYAPP.RC2， these two framework-provided resource files are #include'd at the end of MYAPP.RC， and they are specified in the Compile-Time Directives of the Set Includes のダイアログ ボックスに似た。Visual C++ の MYAPP.RC を編集しますが、アプリケーションのバイナリ .RES ファイルと最終の .exe ファイルにコンパイルされますが、直接これらのフレームワークのリソースを表示したり編集できません。変更する手順を含む標準フレームワークのリソースの詳細については、 テクニカル ノート 23を参照してください。
AFXRES.H は、標準のシンボルを、フレームワークによって使用され、特に AFXRES.RC で使用される ID_FILE_NEWのような定義します。また、 AFXRES.H の #include の WINRES.H の WINDOWS.H のサブセットを含む Visual C++ で必要とされる .RC ファイル、または AFXRES.RC を生成しました。AFXRES.H で定義されたシンボルは、アプリケーションのリソース ファイル （MYAPP.RC）を編集するために使用できます。たとえば、 ID_FILE_NEW は MYAPP.RC のメニュー リソースにコンテナーに存在するファイルの新しいメニュー項目で使用されます。これらのフレームワークで定義されたシンボルを変更または削除することはできません。
追加ヘッダー ファイルをインクルード
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)
2 番目の読み取り専用シンボルのディレクティブとして #include ステートメントを指定する Resource Includes のようにコマンドを使用して追加読み取り専用ヘッダー ファイルをインクルードできます:
#include "afxres.h"
#include "second.h"
新しいファイルの関係の図は次のようになります。:
AFXRES.H
RESOURCE.H SECOND.H
\ /
\ /
MYAPP.RC
|
|
RES\MYAPP.RC2
AFXRES.RC
AFXPRINT.RC
2 .RC 間のヘッダー ファイルを共有することです
異なるプロジェクトにある、または同じ場合は、を 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 番目のヘッダー ファイルが同じアプリケーション （プロジェクト）の 2 種類の .RC ファイルで共有されている場合は、後で説明します。
同じプロジェクト内の複数のリソース ファイルを使って
別の内の 1 種類の .RC ファイルの #include を使用して同じプロジェクトの Visual C++ とリソース コンパイラ サポート複数の .RC ファイル。複数の入れ子は許可されます。複数の .RC ファイルにプロジェクト リソースを分割するさまざまな原因があります:
複数の .RC ファイルにリソースを分割すると複数プロジェクトのチーム メンバー間の多くのリソースを管理する方が簡単です。ファイルをチェックし、変更をチェックインのソース コントロール管理パッケージを使用すると、複数の .RC ファイルにリソースを分割すると、リソースへの変更の細かく制御できます。
プリプロセッサ ディレクティブを、 #ifdef など、 #endif 使用する場合は、リソースの一部に対する #define、リソース コンパイラでコンパイルされた読み取り専用リソースの変更を分離します。
構成 .RC ファイルは、 Visual C++ に 1 個の複合 .RC ファイルよりも読み取り、保存します。
ユーザーが認識できる形式のテキスト エディターを使用してリソースを保持する場合は、 Visual C++ 1 の編集とは別に .RC ファイルでおく必要があります。
または別の特化されたデータのエディターでインタープリターが解釈できるバイナリ形式であるテキストでユーザー定義のリソースを保持する必要がある場合は、別の .RC ファイルで保持する必要があるため、 Visual C++ 16 進数のデータにフォームは変更されません。MFC の高度な概念のサンプル SPEAKN の （.WAV の正常な）ファイルのリソースの例です。
設定のコンパイル時ディレクティブの SECOND.RC がダイアログ ボックスを含む #include する場合:
#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++ 編集可能なを整理し、 「マスター」 MYAPP.RC が #include を他の .RC する複数の .RC ファイルへの編集できないリソースは、ファイル。Visual C++ プロジェクト .MAK ファイルを使用すると、すべての #include'd のリソースをアプリケーションにコンパイルされるように、プロジェクトに 「マスター」 .RC ファイルを含める必要があります。
Noneditable Visual C++ ファイルの適用
AppWizard 作成された RES \MYAPP.RC 2 のファイルは、誤って Visual C++ に読み込んだりする場合は、それを書き込むには、書式設定情報の損失を中止するリソースを含むファイルの例です。これを防ぐためには、 RES \MYAPP.RC 2 ファイルの先頭に次の行を追加します:
#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 ファイルで共有される管理の文字
2 種類の問題は、 Visual C++ で個別に編集する複数の .RC ファイルにリソースを分割する場合に発生します:
複数の .RC ファイルにわたって同じシンボルを共有する場合があります。
個別のリソース （シンボル）に同じ ID に数値を割り当てる回避するために、 Visual C++ を支援する必要があります。
次の図は、 .RC の構成について説明します。H ファイルの最初の問題を処理する:
MYAPP.RC
/ \
/ \
MYSTRS.H / MYSHARED.H \ MYMENUS.H
\ / / \ \ \
\ / / \ \ \
MYSTRS.RC MYMENUS.RC
この例では、文字列リソースは 1 種類のリソース ファイル、 MYSTRS.RC に保存され、メニューは別の、 MYMENUS.RC に保持されます。コマンドのなどのシンボルは、 2 ファイルの間で共有する必要がある場合があります。たとえば、 ID_TOOLS_SPELL は [ツール] メニューのスペルの項目のメニュー コマンドの ID である可能性があります。; とまた、アプリケーションのメイン ウィンドウのステータス バーに、フレームワークによって表示されるコマンド プロンプト文字列の ID である場合があります。
ID_TOOLS_SPELL のシンボルは共有ヘッダー ファイル、 MYSHARED.H. で保持されます。テキスト エディターでこの共有ヘッダー ファイルを手動で保持します; Visual C++ は直接それを編集できません。2 種類のリソース ファイル MYSTRS.RC と MYMENUS.RC では、前述したように、 Resource Includes コマンドを使用して、 MYAPP.RC の場合は読み取り専用で #include ディレクティブ MYSHARED.H を指定します。
リソースを識別するを使用する前に、共有するシンボルを予測できると便利です。シンボルを共有ヘッダー ファイルに追加し、シンボルを使用する前に .RC ファイルの読み取り専用のディレクティブで #include'd を共有ヘッダー ファイル既にある場合、そのします。シンボルをこの方法で共有することを想定していない場合は、 MYMENUS.H から MYSHARED.H に MYSTRS.RC で使用する前に手動ではになります （テキスト エディターを使用して移動します）シンボルのステートメントを #define。
複数の .RC ファイルのシンボルを管理する場合、または個別のリソース （シンボル）に同じ ID に数値を割り当てる避けるように、 Visual C++ を手助けする。特定の .RC ファイルでは、 Visual C++ では、徐々に 4 個の ID のドメインの ID を割り当てます。セッションの編集時に、 Visual C++ は .RC ファイルのシンボル ヘッダー ファイルのドメインのそれぞれに代入された最後の ID を追跡します。ここで APS_NEXT 値が空の （新しい） .RC ファイルのためのフォルダーです:示します。
#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 は、ダイアログ リソース、メニュー リソース用に使用される次のシンボル値です。リソース シンボル値の有効範囲は 0x6FFF に 1 です。
_APS_NEXT_COMMAND_VALUE はコマンド ID で使用される次のシンボル値です。コマンド シンボル値の有効範囲は 0x8000 に 0xDFFF です。
_APS_NEXT_CONTROL_VALUE は、ダイアログ コントロールに使用される次のシンボル値です。ダイアログ コントロールのシンボル値の有効範囲は 0xDFFF に 8 です。
_APS_NEXT_SYMED_VALUE は、シンボルのブラウザーの新しいコマンドを使用して手動でシンボル値を割り当てるときに問題次のシンボル値です。
Visual C++ は、少し高い値と新しい .RC ファイルを作成する場合に最も低い有効な値を起動します。AppWizard は、 MFC アプリケーションにより適切なものにこれらの値を初期化します。ID 値の範囲についての詳細については、 テクニカル ノート 20を参照してください。
新しいリソース ファイルを作成するたびに同じ現在のは、 Visual C++ 定義します _APS_NEXT_ 同じ値を射影します。これは .RC 2 の複数のダイアログを追加する場合と同じ #define 値が異なるダイアログに割り当てることのファイルが、非常に高くなります意味します。たとえば、最初の .RC ファイルの IDD_MY_DLG1 は、 IDD_MY_DLG2、 .RC ファイルと同じ 101 という番号を割り当てることがあります。
これを回避するには、それぞれ .RC ファイルの ID の 4 種類のドメインごとに異なる数値の範囲を予約する必要があります。手動で、リソースの追加を開始する .RC ファイル before の _APS_NEXT 値を更新することによって、これを行います。たとえば、最初の .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
もちろん 2 番目の .RC ファイル用に予約されている数値がそれらを複製すると、 Visual C++ が最初の .RC ファイルのため、多くの ID を割り当てるには、あります。これが起こらないように十分に大きい範囲を予約する必要があります。
.RC、 .cpp ファイル間の依存関係の管理。H ファイル
Visual C++ は .RC ファイルを保存すると、対応する RESOURCE.H ファイルへのシンボルの変更を保存します。.RC ファイルのリソースを示す .cpp ファイルのいずれかが #include プロジェクトのマスターのヘッダー ファイルからの RESOURCE.H ファイル、通常です。これにより、ヘッダーの依存関係のソース ファイルをスキャンする開発環境の内部プロジェクト プロジェクト管理に望ましくない結果が発生します。Visual C++ の新しいシンボルを追加するたびに、 #include 再コンパイルする RESOURCE.H 必要があるすべての .cpp ファイル。
Visual C++ では、次のコメントを含めることによって、 RESOURCE.H ファイルの最初の行として RESOURCE.H の依存関係を回避できます:
//{{NO_DEPENDENCIES}}
開発環境では RESOURCE.H への変更を無視することによって依存 .cpp ファイルを再コンパイルする必要がない場合は、この注釈を解釈します。
Visual C++ は .RC ファイルに保存すると //の NO_DEPENDENCIES {{}} コメント行を常に追加します。場合によっては、 RESOURCE.H のビルド依存関係を回避するには、リンク時に検出されないままされていない実行時エラーが発生する場合があります。たとえば、リソースのシンボルに割り当てられた数値を変更するためにシンボルのブラウザーを使用してリソースは、アプリケーション ランタイムに適切にリソースを示す .cpp ファイルが再コンパイルされていない取得し、読み込まれません。このような場合は、明示的に指定する RESOURCE.H のシンボルの変更の影響を受けるか、選択する Rebuild Allがわかっている .cpp ファイルを再コンパイルする必要があります。多くの場合、リソースの特定のグループのシンボル値を変更する必要がある場合、上記のセクション 追加ヘッダー ファイルをインクルードに説明されているように、別の読み取り専用ヘッダー ファイルにこれらのシンボルは、作成と便利で、安全なります。
設定された Visual C++ の管理情報がどのように含まれているか
上で説明したように、ファイル セットがメニュー コマンドを 3 種類の情報を指定することも可能です:
シンボル ヘッダー ファイル
読み取り専用シンボルのディレクティブ
コンパイル時ディレクティブ
以下は Visual C++ は .RC ファイルの情報をどのように管理する方法について説明します。この情報は、 Visual C++ を使用する必要はありませんが含まれている機能をさらに確信を受ける設定を使用できるようになったを増やすことがあります。
設定の上の 3 種類の型は、 2 とおりの形式の .RC ファイルで格納されますが含まれています: リソース コンパイラによって、 Visual C++ でのみインタープリターが解釈できる特別な TEXTINCLUDE のリソースとして （2）インタープリターが解釈できる #include または他のディレクティブとして （1）。
TEXTINCLUDE のリソース オブジェクトは、 Visual C++ の Set Includes のダイアログ ボックスで簡単にしたり、表現のフォームに含める情報を安全に設定を保存します。TEXTINCLUDE は、 Visual C++ で定義されている リソースの種類 です。Visual C++ は、リソース id 番号 1、 2、および 3 を持つ 3 個の特定の TEXTINCLUDE のリソースを認識します:
TEXTINCLUDE のリソース id |
設定の型は情報が含まれます。 |
|---|---|
1 |
シンボル ヘッダー ファイル |
2 |
読み取り専用シンボルのディレクティブ |
3 |
コンパイル時ディレクティブ |
設定の 3 種類の型は、既定 MYAPP.RC と AppWizard によって作成された RESOURCE.H ファイルによって情報を示します。次のように含まれています。ゼロを指定する \0 and "" tokens between BEGIN and END blocks are required by the RC の特別な構文は、文字列と二重引用符文字を終了しました。
シンボル ヘッダー ファイル
リソース コンパイラが解釈するシンボル ヘッダー ファイル情報の形式は #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