注
次のテクニカル ノートは、最初にオンライン ドキュメントに含まれてから更新されていません。 その結果、一部の手順やトピックが古くなっているか、正しくない可能性があります。 最新情報については、オンライン ドキュメント インデックスで関心のあるトピックを検索することをお勧めします。
このメモでは、コンポーネントをローカライズするために使用できる設計と手順の一部について説明します(アプリケーション、OLE コントロール、MFC を使用する DLL など)。
概要
MFC を使用するコンポーネントをローカライズするときに解決する必要がある問題は、実際には 2 つあります。 まず、コンポーネントに固有の文字列、ダイアログ、その他のリソースなど、独自のリソースをローカライズする必要があります。 MFC を使用して構築されたほとんどのコンポーネントには、MFC によって定義されている多数のリソースも含まれており、使用されます。 ローカライズされた MFC リソースも提供する必要があります。 幸いにも、MFC 自体には既にいくつかの言語が用意されています。
さらに、コンポーネントをターゲット環境 (ヨーロッパまたは DBCS 対応環境) で実行できるように準備する必要があります。 ほとんどの場合、これはアプリケーションが上位ビット セットの文字を正しく処理し、2 バイト文字の文字列を処理するかどうかによって異なります。 MFC は、既定では両方の環境で有効になっており、セットアップ時に異なるリソースのみを接続しているすべてのプラットフォームで使用される単一のワールドワイド バイナリを使用できます。
コンポーネントのリソースのローカライズ
アプリケーションまたは DLL をローカライズするには、単にリソースをターゲット言語に一致するリソースに置き換える必要があります。 独自のリソースの場合、これは比較的簡単です。リソース エディターでリソースを編集し、アプリケーションをビルドします。 コードが正しく記述されている場合、C++ ソース コードにハードコーディングされた文字列やテキストは存在しません。すべてのローカライズは、リソースを変更するだけで実行できます。 実際には、ローカライズされたバージョンを提供するすべてのコンポーネントに元のコードのビルドが含まれていないようなコンポーネントを実装できます。 これはより複雑ですが、その価値があり、MFC 自体に対して選択されたメカニズムです。 また、EXE または DLL ファイルをリソース エディターに読み込み、リソースを直接編集することで、アプリケーションをローカライズすることもできます。 可能な限り、アプリケーションの新しいバージョンをビルドするたびに、これらの変更を再適用する必要があります。
この問題を回避する 1 つの方法は、サテライト DLL とも呼ばれる個別の DLL 内のすべてのリソースを見つけることです。 その後、この DLL は実行時に動的に読み込まれ、すべてのコードでメイン モジュールからではなく、その DLL からリソースが読み込まれます。 MFC は、このアプローチを直接サポートします。 MYAPP.EXEというアプリケーションを考えてみましょう。すべてのリソースを MYRES.DLL と呼ばれる DLL に配置できます。 アプリケーションの InitInstance では、次のように実行して DLL を読み込み、MFC がその場所からリソースを読み込みます。
CMyApp::InitInstance()
{
// one of the first things in the init code
HINSTANCE hInst = LoadLibrary("myres.dll");
if (hInst != NULL)
AfxSetResourceHandle(hInst);
// other initialization code would follow
// ...
}
それ以降、MFC は、myapp.exeからではなく、その DLL からリソースを読み込みます。 ただし、すべてのリソースは、その DLL に存在する必要があります。MFC は、特定のリソースを検索してアプリケーションのインスタンスを検索しません。 この手法は、通常の MFC DLL と OLE コントロールにも同様に適用されます。 セットアップ プログラムは、ユーザーが希望するリソース ロケールに応じて、適切なバージョンのMYRES.DLLをコピーします。
リソースのみの DLL を作成するのは比較的簡単です。 DLL プロジェクトを作成し、.RC ファイルを作成し、必要なリソースを追加します。 この手法を使用しない既存のプロジェクトがある場合は、そのプロジェクトからリソースをコピーできます。 リソース ファイルをプロジェクトに追加すると、プロジェクトをビルドする準備がほぼ完了します。 必要な操作は、 /NOENTRY を含むようにリンカー オプションを設定することだけです。 これにより、DLL にエントリ ポイントがないことをリンカーに通知します。コードがないため、エントリ ポイントがありません。
注
Visual C++ 4.0以降のリソースエディターでは、.RCファイルごとに複数の言語がサポートされています。 これにより、1 つのプロジェクトでローカライズを非常に簡単に管理できます。 各言語のリソースは、リソース エディターによって生成されたプリプロセッサ ディレクティブによって制御されます。
提供された MFC ローカライズされたリソースの使用
ビルドする MFC アプリケーションは、MFC のコードとリソースの 2 つを再利用します。 つまり、MFC には、MFC クラスで使用されるさまざまなエラー メッセージ、組み込みダイアログ、およびその他のリソースがあります。 アプリケーションを完全にローカライズするには、アプリケーションのリソースだけでなく、MFC から直接取得されるリソースもローカライズする必要があります。 MFC にはさまざまな言語リソース ファイルが自動的に用意されているため、対象となる言語が MFC で既にサポートされている言語の 1 つである場合は、それらのローカライズされたリソースを使用する必要があります。
この執筆時点で、MFC は中国語、ドイツ語、スペイン語、フランス語、イタリア語、日本語、韓国語をサポートしています。 これらのローカライズされたバージョンを含むファイルは、MFC\INCLUDE\L.* ('L' はローカライズされたディレクトリを表します) にあります。 たとえば、ドイツ語ファイルは MFC\INCLUDE\L.DEU にあります。 アプリケーションで MFC\INCLUDE にあるファイルではなく、これらの RC ファイルを使用するには、RC コマンド ラインに /IC:\PROGRAM FILES\MICROSOFT VISUAL STUDIO .NET 2003\VC7\MFC\INCLUDE\L.DEU を追加します (これは単なる例です。選択したロケールと Visual C++ をインストールしたディレクトリを置き換える必要があります)。
上記の手順は、アプリケーションが MFC と静的にリンクしている場合に機能します。 ほとんどのアプリケーションは動的にリンクします (AppWizard の既定値であるため)。 このシナリオでは、コードが動的にリンクされているだけでなく、リソースも同様です。 その結果、アプリケーションでリソースをローカライズできますが、MFC 実装リソースは引き続きMFC7x.DLL (またはそれ以降のバージョン) から、または存在する場合はMFC7xLOC.DLLから読み込まれます。 これは、2 つの異なる角度からアプローチできます。
より複雑な方法は、ローカライズされた MFC7xLOC.DLL (MFC7xDEU、ドイツ語、スペイン語のMFC7xESP.DLLなど) のいずれか、またはそれ以降のバージョンを出荷し、ユーザーがアプリケーションをインストールするときに適切なMFC7xLOC.DLLをシステム ディレクトリにインストールすることです。 これは、開発者とエンド ユーザーの両方にとって非常に複雑な場合があります。そのため、推奨されません。 この手法とその注意事項の詳細については、 テクニカル ノート 56 を参照してください。
最も簡単で安全な方法は、ローカライズされた MFC リソースをアプリケーションまたは DLL 自体 (またはサテライト DLL を使用している場合はサテライト DLL) に含める方法です。 これにより、MFC7xLOC.DLLを正しくインストールする際の問題が回避されます。 これを行うには、AppWizard によって追加された /D_AFXDLL 定義も削除する必要がある点を除き、上記の静的なケースに対して同じ手順に従います (ローカライズされたリソースを指すように RC コマンド ラインを適切に設定します)。
/D_AFXDLLが定義されている場合、AFXRES。H (およびその他の MFC RC ファイル) は、実際にはリソースを定義しません (代わりに MFC DLL からプルされるため)。