テクニカル ノート 57: MFC コンポーネントのローカライズ
注意
次のテクニカル ノートは、最初にオンライン ドキュメントの一部とされてから更新されていません。 結果として、一部のプロシージャおよびトピックが最新でないか、不正になります。 最新の情報について、オンライン ドキュメントのキーワードで関係のあるトピックを検索することをお勧めします。
ここでは、ユーザー定義のコンポーネント (MFC を使用するアプリケーション、OLE コントロール、または DLL) をローカライズするためのデザインと手順について説明します。
概要
MFC を使用するコンポーネントをローカライズする場合、解決すべき課題は 2 つあります。 まず、文字列、ダイアログ、およびその他のコンポーネント固有のリソースをローカライズする必要があります。 MFC を使用して構築されたほとんどのコンポーネントでは、MFC で定義された数多くのリソースが含まれていたり使用されたりしています。 これらの MFC リソースもローカライズする必要があります。 さいわい、MFC 自体が既に数か国語で提供されています。
さらに、コンポーネントを対象の環境 (ヨーロッパ言語の環境または DBCS 環境) で実行できるように準備する必要があります。 これは、ほとんどの場合、アプリケーションで上位ビットが設定されている文字を正しく扱っているかどうか、またダブル バイト文字を含む文字列を処理しているかどうかに依存します。 既定では、MFC はこれらの環境の両方で使用でき、1 つの万国共通のバイナリに対してセットアップ時に異なるリソースをプラグインすることで、すべてのプラットフォームで使用できるようになっています。
コンポーネントのリソースのローカライズ
アプリケーションや DLL のローカライズ作業では、リソースを対象の言語と一致するリソースに置き換えます。 独自のリソースの場合は、これは比較的簡単です。リソース エディターでリソースを編集し、アプリケーションを構築します。 コードが適切に記述されており、ローカライズ対象の文字列やテキストが C++ ソース コードに直接コーディングされていない場合は、単にリソースを変更するだけでローカライズは完了します。 実際、ユーザー定義のコンポーネントを実装するときに、元のコードをビルドせずにローカライズされたバージョンを提供できます。 この方法は複雑ですが試してみる価値はあり、MFC 自体でも使用されている方法です。 EXE ファイルや DLL ファイルをリソース エディターに読み込んでリソースを直接編集する方法でも、アプリケーションをローカライズできます。 ただし、この方法では、アプリケーションの新しいバージョンをビルドするたびに変更点を再適用する必要があります。
これを回避するため、すべてのリソースを 1 個の DLL にまとめるという方法があります。このような 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 が検索するとき、アプリケーションのインスタンスは検索対象になりません。 この方法は OLE コントロールと同様に標準 DLL にも当てはまります。 セットアップ プログラムでは、ユーザーが使用するリソース ロケールに応じて適切なバージョンの MYRES.DLL がコピーされます。
リソースのみの DLL を作成するのは比較的簡単です。 DLL プロジェクトを作成し、.RC ファイルを追加してから、必要なリソースを追加します。 この方法を採用していない既存プロジェクトの場合は、そのプロジェクトからリソースをコピーできます。 プロジェクトにリソース ファイルを追加したら、プロジェクトをビルドする準備はほぼ完了です。 後は、/NOENTRY を含めるように、リンカー オプションを設定するだけです。 これにより、リンカーは DLL にエントリ ポイントを作成しません。コードがないため、エントリ ポイントも作成されません。
注意
Visual C++ 4.0 以降のリソース エディターでは .RC ファイルごとに複数の言語がサポートされています。 これにより、1 つのプロジェクトでのローカライズを簡単に管理できます。 各言語用のリソースは、リソース エディターが生成するプリプロセッサ ディレクティブによって制御されます。
ローカライズ済みの MFC リソースの使用
MFC アプリケーションは、MFC から 2 つの再利用します。コードおよびリソース。 つまり、MFC には MFC クラスで使用されるエラー メッセージ、組み込みダイアログ、およびその他のリソースが含まれます。 アプリケーションを全面的にローカライズするには、アプリケーションのリソースだけでなく、MFC から直接読み込んでいるリソースもローカライズする必要があります。 MFC では多数の言語リソース ファイルが自動的に提供されるため、対象の言語が MFC でサポートされていれば、ローカライズされたその言語のリソースを使用することを確認するだけで十分です。
現時点で 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 がある場合は MFC7xLOC.DLL から読み込まれます。 これについては、2 つの方法で対処できます。
複雑な方法としては、ローカライズされた MFC7xLOC.DLL (たとえば、ドイツ語の場合は MFC7xDEU、スペイン語の場合は MFC7xESP.DLL) を出荷し、ユーザーがアプリケーションをインストールするときに適切な MFC7xLOC.DLL がシステム フォルダーにインストールされるようにする方法があります。 これは開発者とエンド ユーザーの両方にとって複雑な方法であるため、あまりお勧めできません。 この方法および注意事項の詳細については、「テクニカル ノート 56: ローカライズされた MFC コンポーネントのインストール」を参照してください。
最も簡単で安全な方法は、アプリケーションまたは DLL 自体 (または使用している場合はそのサテライト DLL) に、ローカライズされた MFC リソースを組み込むことです。 これにより、MFC7xLOC.DLL を適切にインストールしなくてはならないという問題を回避できます。 この方法を採用するには、上に説明した静的リンクの場合の手順に従って、RC コマンド ラインでローカライズされたリソースを適切に指定します。ただし、AppWizard によって追加された /D_AFXDLL の定義を削除する必要があります。 /D_AFXDLL が定義されていると、AFXRES.H (およびその他の MFC の RC ファイル) では実際には何もリソースを定義せず、代わりに MFC の DLL からリソースが取り込まれてしまいます。