テクニカル: 既存の MFC アプリケーションを MFC 3.0 更新

このテクニカル ノートでは、主に MFC 1.0 アプリケーションは、MFC 2.0 ツールへの移行のガイドラインを示します。MFC 2.0、2.5、および 3.0 の追加違い最初のセクションでは、次の通りです。

MFC 4.0 ・ 3.0 の API を変更

既知の変更の変更を必要とする既存のコードが、文書化された MFC api はありません。もちろん、多くの追加機能を利用することがあります。これらの機能の詳細については、 Visual の C++ プログラマのガイドを参照してください。

MFC 2.5 API の変更

MFC 2.5 は、クラス ライブラリに 2 つの主要な機能を追加: OLE 2.0 をサポートしている OLE 1.0 サポートとデータベースへのアクセスを提供する ODBC サポートを交換してください。それはあなたの既存のコードに影響を与える可能性があります、API の変更点をカバーするためにこの technote の意図です。この technote では、覆われていない、これらの新機能については、「ビジュアル C++ プログラマ ガイドを参照してください。

CFrameWnd::RecalcLayoutが BOOL bNotify、追加のパラメーター。これは、OLE サーバーを通知するかどうかを指定します、彼らがレイアウトを変更します。それは通常 TRUE で、したがって、既定値です。あなたのプログラムがこの関数のオーバーライドを提供する場合と同様に、関数に、余分なパラメーターを追加する必要がありますのでこの関数が仮想、です。

MFC 2.5 ライブラリで文書化されていない関数に OLE 2.0 として ODBC をサポートするために他変更されました。非公開の MFC の Api のプログラムを使用する場合は、彼らがまだ有効であるかどうかを確認するなどのすべての使用を確認してください。

移行する MFC 1.0 アプリケーション MFC 2.0 に

重要: を理解し、以下に示す 2 つのアプローチを評価するには、あなた、ドキュメントとビュー アーキテクチャや、ツールなどの MFC 2.0 の概念に精通する必要があります。我々、少なくとも、MFC チュートリアル サンプルの仕事を提案する 落書きで既存のコードの移行を開始する前にチュートリアル。

Microsoft C7、mfc バージョン 2 のリリース移行の既存アプリケーションから MFC バージョン 1、2 つの基本的な方法します。

最小限の移行

「最小限に抑えて移行」の方法を使用して、必要な、最小の変更のみするように:

• 既存の MFC 1.0 アプリケーションをコンパイルし、正常に MFC 2.0 ライブラリとのリンク。
  
  
• Visual C を使用して、リソースを正常に編集できます。
  
  
• あなたのメッセージ ハンドラー関数とダイアログ データ ClassWizard によって認識されます。

これは、最も簡単なアプローチですが、豊富な機能を最大限に活用、MFC 2.0 ライブラリにしていません。「完全移行」の方法を選択した場合でも、理解し、、最小限の移行のための技術を練習する必要があります。

完全移行

「完全移行」を実行する場合は、MFC 2.0 ライブラリ最大限活用を取ることができます。最小限の移行方法を使用して、Visual C と ClassWizard を使用してアプリケーションを編集することができます。完全移行の方法を使用して、次の MFC 2.0 サポートを得る:

• 標準ファイル メニューとダイアログのユーザー インターフェイス。機能などの標準のファイルを開いて取得および保存ダイアログ、ファイル マネージャーやドラッグ アンド ドロップ、最近使用ファイル メニュー ・ インターフェイス、。
  
  
• 印刷。コードの表示を供給する;ライブラリ プリンター DC を取得の面倒を見るを中止を入れて、印刷ループの実行] ダイアログ ボックス。
  
  
• プレビューを印刷します。通常、アプリケーションで印刷プレビュー機能に余分なコーディングをしないする必要があります。
  
  
• ツールバーとステータス バー。彼らは今 Visual C および MFC 2.0 を使用して、アプリケーションに追加するは簡単です。
  
  
• 分割ウィンドウ。ビュー クラスに表示コードを構造化する場合は、[、非常に小さな追加の費用で分割ウィンドウで表示することができます。
  
  
• OLE2 サポート。「ドキュメント/ビュー」アーキテクチャを活用してアプリケーション、おそらく OLE の大量の作業なし有効にすることができます。

全体的に完全移行方法は、基本的に AppWizard の開始最初から MFC 2.0 アプリケーションの開発をエミュレートするためにです。最初から MFC 2.0 アプリケーションを開発してからもちろん、あなたが多くの理にかなっていると書いた MFC 1.0 コードとしてが借りれますされます。

最小限の移行

最小限に抑えて移行を実行するための詳細なガイドラインは次のサブセクションを提示します。

Windows 3.1 厳格な typedef に準拠

既定の MFC ライブラリを遵守するには、Windows 3.1 SDK で説明されている Windows 3.1 の厳格なtypedef 2.0 のビルドします。MFC 1.0厳格なオフになっていたが、デフォルトでSTRICT MFC 2.0 になりました。これは、業界の標準的な Windows API を追跡するために、堅牢なアプリケーションを簡単に開発する開発プラクティスを促進するための MFC のコミットメントです。厳格なtypedef 堅牢なソフトウェアを作成するには、MFC 2.0 クラスの開発者に役立つよう、だから、アプリケーション コードの開発では true になります。

最初にチェックする厳格な型を使用する場合、多くのコンパイル エラーが通常発生します。Windows 3.1厳格なtypedef に準拠するには、MFC 1.0 アプリケーションを変更が非常によくを最小限に抑えて移行作業の大部分を表す場合があります。

アプリケーションを厳格に準拠すると、さらに変更を実行可能ファイルをコンパイルすることができる場合があります。たとえば、ABOUT2 と FILEVIEW MFC 1.0 のサンプルは追加の変更をコンパイルしません。かれらはすでにSTRICT準拠とした使用しない変更 MFC Api。

MFC 2.0 API の変更

厳格に準拠したを超えて、ほとんど努力を最小限に抑えて移行を行うは識別し、比較的少数の MFC 2.0 API 変更に準拠するアプリケーション コードを変更するには。

1800 の MFC 1.0 Api の唯一の 20 された Api のコンパイル時のエラーの結果を変更しました。これらの変更は既存の MFC 1.0 アプリケーションをささいな変更のみが必要です。最も広範な変更は、OLE クラスの建築改革です。これらの変更が技術的なメモ 18で覆われています。

変化を予測するには、必要がありますを確認項「アルファベット API 変更」この technote 最後を参照していますください。それは MFC 2.0 では MFC 1.0 の Api が変更された、便利で簡単な概要します。

MFC 2.0 コードに対処する必要のすべての変更を確認はいない場合は、さまざまなコンパイルとリンクのエラーを取得します。これらのエラーは、ほとんど常に診断が容易です。あなたの診断を支援するには、コンパイラ エラー」この technote の終わりでいくつかのガイドラインを提供します。

次の MFC Api は、MFC 2.0 では削除されています。私たちには、適切な場所での代替 Api を推奨します。この一覧に文書化されていない api の変更は含まれません。

CDC::GetDCOrg

GetDCOrgは、Win32 ではないです。Windows 3.x アプリケーションだけは、ちょうど、Windows API を呼び出す:: GetDCOrg直接。

CRuntimeClass::m_pszClassName

このメンバー変数は、メモリ モデルに依存 char ※） ではなく、 LPSTRになりました。MFC 2.0 では、 m_lpszClassNameという名前します。

CMDIChildWnd::m_pMDIFrameWnd

MFC 1.0 では、このメンバー変数をクラスの MDIFrame 親を指摘しました。このメンバー変数は、メンバー関数CMDIChildWnd::GetMDIFrameで置き換えられます。複数ドキュメント インターフェイス (MDI) MFC 2.0 を使用している場合は、既定の MDI サポートをすべて、標準の MDI ウィンドウ メニュー コマンドの処理からほとんど使用CMDIChildWnd::m_pMDIFrameWnd (またはGetMDIFrame) は不要になりました。

CFrameWnd::GetChildFrame

MDI フレームの代わりにCMDIFrameWnd::MDIGetActiveを使用します。

次の API は MFC 2.0 では、1 の互換性をサポートするために残されているが、されていません。MFC の将来のバージョンから削除されます。

CMDIFrameWnd::CreateClient

この機能は、ビューの作成および改善の MFC 2.0 MDI サポートより一般的なOnCreateClientメカニズムによって置き換えられています。元のCreateClientは、( CMDIFrame::MDISetMenuを使用して) 自分 MDI フレーム ウィンドウのメニュー バーを管理する MDI アプリケーションをまだ使用できます。MFC 2.0 MDI サポートは、現在アクティブな MDI 子ウィンドウのメニューの MDI フレーム ウィンドウのメニュー バーを自動的に切り替えるされます。

その他の API 関連の変更

2 つの MFC クラスから afxwin.h afxext.h ヘッダー ファイルに移動されています。:

• CBitmapButton
  
  
• CMetaFileDC

これらのクラスを参照、.cpp ファイルに以下を追加します:

#include lt;afxext.h>

'Const' 修飾子の使用について厳密なので、多くの Api が変更されています。これらの変更より一貫性のある使用、LPCSTR 型の名前および新しい LPCRECT 型名。コンパイル時間問題ありませんこれらの変更により、任意の型を引数として使用する場合は、その型の const バージョン昇格することができますので注意してください。Const データ ポインター、コードを使用すると、厳格な変更のようなより堅牢なコードにこれをリードします。

今下記ウィンドウ作成関数は、追加のパラメーターが最後のパラメーターは既定値の NULL があるので、既存のコード変更せずに使用されます。これらの関数します。

• :Create
  
  
• CFrameWnd::Create
  
  
• CMDIFrameWnd::Create
  
  
• CMDIChildWnd::Create

次の関数は MFC 1.0 で仮想だったが、今 MFC 2.0 で非仮想です。:

• CFile::GetStatus
  
  
• CFrameWnd::GetParentFrame

これらの関数のいずれかの MFC 1.0 アプリケーションの派生クラスをオーバーライドする場合は、MFC 2.0 では、派生クラスで関数を呼び出されることがないです。また、 GetParentFrame CFrameWndからCWndにはより一般的に便利な API に移転。

すべての静的メンバーのクラス、関数、グローバル演算子/友人今呼び出し規約PASCALに従います。すべてのグローバル関数AFXAPI (パスカル) です。もう一度、このコンパイル時間の問題ではないがより速く、小さく生成されるコードにつながる。

実装はクラスや構造体の多くは、'C' プレフィックスを使用しないように名前が変更されています。たとえば、 CExceptionContext AFX_EXCEPTION_CONTEXTに名前が変更されています。これらのクラスは、記載されていないと、クラス ライブラリの実装の詳細を維持します。それは、これらに依存しているし、は一般的に、将来のバージョンで変更されるため、クラス ライブラリのドキュメント化されていない Api を使用しないようにすることをお勧め可能性がないです。

MFC 2.0 の既定の動作を変更します。

MFC の API の変更に対処は、コンパイラとリンカーによって報告されたエラーの助けを借りて簡単です。すべてのライブラリの変更点ライブラリのヘッダー ファイルで、しかし明らかにしています。いくつかの変更は、アプリケーションの実行時の動作で明らかにされます。それらを予測している限りこれらの変更は一般的に対処することは困難は。このような行動の変化を予測する次の情報が提供されます。

CDialogとCModalDialogは、1 つのクラスにマージされています。今すぐCModalDialog古いクラスと見なされます。ただし、MFC 1.0 の互換性のためCModalDialogへのすべての参照はまだ afxwin.h で移行マクロによって有効です。:

# define CModalDialog CDialog

多くの MFC 1.0 アプリケーションでは、この単純な #define で十分です。ただし、ここでこの番号を定義することは十分ではありません。

モードレス ダイアログ ボックスを実装し、 OnOKとOnCancelの既定「何もしない」動作に依存して場合は、今EndDialog (モーダル ダイアログ処理） をかけるのでこれらと既定動作をオーバーライドする必要があります。

CDialog::CreateIndirectはまだ、モードレス ダイアログ ボックスを作成します。作成するには、モーダル ダイアログ使用CDialog::InitModalIndirect削除されたCModalDialog::CreateIndirectの代わりに API。

ダイアログ ボックスとメッセージ ボックスの背景色、 CWinApp::SetDialogBkColor API を使用して現在グローバルに設定できます。既定のパラメーター、色灰色の背景をグレーに (ないCOLOR_BTNFACE) を設定します。その他の色を指定ことがあります。

SetDialogBkColor CWinAppのと呼ばれるないかどうか- InitInstance関数は、既定のウィンドウの背景色 (コントロール パネルの色のアプレットの設定) を使用を派生。

MFC 1.0 では、DLL にはCWinAppオブジェクト含まれている場合、 AfxWinTermの呼び出しは、 DllMainを提供する必要があります。MFC 2.0 を提供このDllMain、含まれているため、追加のコードは、 DllMain DLL の CWinApp::ExitInstanceメンバー関数に移行します。

CMDIChildWnd::Create今、正しくdwStyleパラメーターを使用します。今 MDI 子ウィンドウの完全なウィンドウ スタイルを指定する必要があります。DwStyleを指定する場合 = 0、アサーションの失敗を今CMDIChildWnd::PreCreateWindowになります。この問題を回避するには、WS_CHILD スタイルを指定する必要があります |WS_VISIBLE |MFC 1.0 との下位互換性を WS_OVERLAPPEDWINDOW。

必要に応じて、フレーム ウィンドウのコントロールのいくつかを削除することができますので MFC 2.0 は MDI 子ウィンドウでは、設定異なるスタイルをサポートします。

クラスCFrameWnd新しいデータ メンバーを BOOL CFrameWnd::m_bAutoMenuEnableしています。設定はデフォルトで TRUE にします。これは、 ON_UPDATE_COMMAND_UIまたはON_COMMANDハンドラーを自動的に無効にする必要はありませんのメニュー項目が発生します。メニュー項目のON_COMMANDハンドラーがないON_UPDATE_COMMAND_UIハンドラーが自動的に有効になります。

オプションのコマンドは、現在の選択に基づいて実装することは簡単でした。また、大きくON_UPDATE_COMMAND_UIハンドラーを有効または無効のメニュー項目を記述するアプリケーションの必要を減らします。たとえば、AppWizard で生成されたアプリケーションを編集切り取り/コピー/プログラマ ハンドラーを実装するまで無効に貼り付けが。

MFC 1.0 アプリケーションは、 ON_COMMANDおよびON_UPDATE_COMMAND_UIハンドラーを使用して更新されていない場合は、ただし、それm_bAutoMenuEnableを明示的にクリアする必要があります。無効にするメニューが自動的にでも有効にする場合にそれ以外の場合、。

(ビルド) のプロジェクトの変更

標準的なメイクファイルを使用して MFC 1.0 アプリケーションを構築する続行できます。までプロジェクトを移行する最も簡単な方法、depedencies、他プロジェクト オプション Visual C 環境を維持するために、Visual C プロジェクトの機能を使用するには。

一般的なリンク エラー COMDLG32 に未解決の外部参照です。DLL と SHELL32。DLL の Api。COMDLG32 とのリンクを確認してください。LIB と SHELL32。LIB。

ビルドを向上させることができる場合があります配置する ＃ 回含める lt;afxwin.h > プリコンパイル済みヘッダー。規則では、MFC 2.0 アプリケーションは、プリコンパイル済みヘッダーの"stdafx.h"を指定します。[モジュール stdafx.cpp には stdafx.h が含まれています。AppWizard と多くのサンプルは、MFC 2.0 で作成したコードでこの方法が示されています。

注特価;それは、定義も stdafx.h 内の _AFX_NO_XXX マクロの未定義ことが重要です。「サポート技術情報」(knowledge Base) 資料を参照してください「PRB: _AFX_NO_XXX を定義するときに問題が発生する。」「サポート技術情報」(knowledge Base) 記事を見つけることができますには、MSDN ライブラリ cd または http://www.microsoft.com/kb/で(&N)。

Visual C と ClassWizard の互換性

最小限に抑えて移行のために、以下の手順を実行する勧めしますあなたのアプリケーションのリソースとコードを編集するには、Visual C と ClassWizard を使用できるように。

• メッセージ マップと ClassWizard を編集する任意のモジュールを次の 2 つのコメント行を .cpp ファイル、関数の実装の外部に追加します。:

  //{{AFX_MSG_MAP （lt; クラス名 >)//}}AFX_MSG_MAP
  

  lt; クラス名 > は、メッセージ マップを含むクラスの名前です。

  同様に、次の 2 つのコメント行に対応するクラス宣言の中の .h ファイルに追加します。:

  //{{AFX_MSG （lt; クラス名 >)//}}AFX_MSG
  

  これらの宣言の例については、AppWizard によって作成されたすべてのアプリケーションの同じのコメント行を見てください。これらのコメント行を参照してください意味について MFC: MFC ソース ファイルを使用してでVisual の C++ プログラマのガイド。

• Lt というメイクファイル プロジェクト必要があります、プロジェクト > .mak とリソース ファイル名前 <project> .rc、<project> があなたのプロジェクトの名前。両方のこれらのファイルは、プロジェクトのルート ディレクトリにあります。。MAK ファイル外部メイクファイルがあります。
  
  
• Visual C 内から ClassWizard を実行します。とき ClassWizard を発見します。CLW ファイルが存在しない、1 つを作成するかどうかはそれを頼みます。'はい' 応答します。。CLW ファイル ClassWizard を使用して、このような//{{AFX_MSG のコメント行を持つモジュールを識別するために、インデックス ファイルは本質的には。
  
  
• 仮想関数と ClassWizard を編集する任意のモジュールを次の 2 つのコメント行をクラス宣言内、.h ファイルに追加します。:

   //{{AFX_VIRTUAL （lt; クラス名 >)//}}AFX_VIRTUAL
  

完全移行

既存の C または MFC 1.0 アプリケーションから MFC 2.0 への完全移行 MFC 2.0 のすべての利点を提供します。ほとんどのアプリケーションでは、完全移行が困難ではないとも努力する価値があります。

ゼロから新しいアプリケーションを開発することと、アプリケーションから MFC 2.0 への完全移行を成功させる MFC 2.0 の本質的に同じ理解が必要です。完全な移行を開始する前に、MFC 2.0 クラス ライブラリ、Visual C、AppWizard と ClassWizard を理解する必要があります。どのようなアプリケーション コードの一部をすることができますを理解する必要があります同等または強化された機能は、MFC 2.0 クラスから派生することによって削除します。ライブラリ実装の詳細を使用して、ソース コード、小さくだけで、アプリケーションのこれらの部分より MFC フレームワークの残りの部分と統合します。

MFC 2.0 にアプリケーションを完全に移行することによって、MFC から比較的少なくの追加機能を得ることができる余分なコスト。たとえば、アプリケーション、分割ウィンドウのユーザー インターフェイスはありませんでしたが、1 つは、ユーザーに役に立つだろう場合は、[、既にコード MFC 2.0 のドキュメント/ビュー アーキテクチャに移植がこの機能をすばやく追加することができますになります。

MFC 2.0 への完全移行はカップル日の努力の大規模なアプリケーション必要がありますが、プロセス自体は非常に簡単です。次の手順をプロセスします。:

1. ドキュメント、ビュー、およびフレーム ウィンドウに既存のアプリケーション アーキテクチャをどのように要因分析します。

   これは、任意のコードの編集を開始する前に行います。多くのプログラマは、ビュー コードとドキュメント コードを合体する傾向があります。行うので必ずしも「悪い状態」はではないドキュメントとビュー機能の分離、MFC フレームワークに裏書きし、、特にサポート デザイン哲学であります。MFC 1.0 CDocumentおよびCViewクラスを持っていなかったが、それもドキュメント/ビューの分離を支持しました。これは、ライブラリのすべての将来のバージョン。

   CDocumentおよびCViewクラス、特に、MFC のチュートリアル サンプルを使用する MFC 2.0 サンプルを研究 走り書き。何、ドキュメントとビューは何をあなたのアプリケーションを分析します。アプリケーションが複数の種類のドキュメントまたはビューかどうかを確認します。

   アプリケーションのドキュメント/ビューの分離をオフに自分自身を貸していない場合でも、完全に MFC 2.0 に移行し、フレームワークを本質的に完全に利用することがあります。「ドキュメント/ビューの分離CDocument- およびCViewを実装することで偽造できる」-ドキュメントやビューのクラスその作業を他のクラスのほとんどを委任場合ありますがのクラスを派生します。または、ビュー クラス、 CFrameWnd- またはCMDIChildWndに頼ることがあります-アプリケーションのユーザー インターフェイスの大部分を実装するクラスを派生します。要約すると、ドキュメント、ビュー、およびフレーム ウィンドウ クラスを分離する方法としてほぼ完全な自由があります。

   あなたの分析も、アプリケーションが複数のビュー クラスと可能性がある複数のドキュメント クラスで必要かどうかを判断します。比較的単純なアプリケーションには、1 つ以上のビュー クラスも必要があります。ただし、複数のビューは、分割ウィンドウなど必ずしも複数CViewがあること指示しないでください-クラスを派生します。分割ウィンドウの各ペイン分割ウィンドウの他のペインと同じユーザー インターフェイスを提供する場合、たとえば、彼らは、同じビュー クラスを共有できます。その場合は、各ウィンドウは、同じビュー クラスの個別のオブジェクトだけです。アプリケーション別のウィンドウでの非常に異なるユーザー インターフェイスを提供する場合、おそらく複数のビュー クラスを設計する必要があります。

2. アプリケーションが必要になります AppWizard サポート フレームワーク機能を分析します。

   AppWizard は、AppWizard ダイアログ ボックスのオプションとして選択さまざまなフレームワークの機能をサポートする MFC 2.0 アプリケーション スケルトンを作成します。スケルトン アプリケーションを作成する AppWizard を実行する前に、まず AppWizard を提供するオプションを理解する必要があります。

   その後、AppWizard のオプションを選択する必要がありますの決定には少し時間を取る。これを数分で初めて AppWizard を実行しようとしないでください。たとえば、アプリケーションが既に OLE をサポートしていない場合は、これを考慮する必要がありますは主要な決定です。AppWizard の OLE オプションを開始するにはしていないことを選んだ場合、まだ MFC の OLE 機能を使用するアプリケーション コードを変更することができます。AppWizard、時間を節約を開始するには、OLE オプションが開始。

   あなたの分析では、アプリケーションが、シングル ドキュメント インターフェイス (SDI) またはマルチ ドキュメント インターフェイス (MDI) アプリケーションであるかどうかを判断します。この特定の決定は、これら 2 つの異なるユーザー インターフェイスの他の Windows アプリケーションに精通している場合に明らかなはずであります。それをすることができますの MDI ユーザー インターフェイスがエンド ・ ユーザーには通常より機能は AppWizard MDI アプリケーション既定開くよりも 1 つのドキュメント ファイルを同時に作成されます。幸いにも、MFC 2.0 のドキュメント/ビュー アーキテクチャでは、MDI のサポート追加あなたの部分のコーディングは必要ありません。

3. AppWizard を使用して、新しいアプリケーションを生成します。

   上記の分析を行うこと、今 AppWizard アプリケーションのスケルトン コードを作成するを実行する準備が整いました。

   ドキュメント、ビュー、およびフレーム ウィンドウへのアプリケーションの分離方法の分析を踏まえ、良いアイデアの対応するクラスとモジュールに名前が必要です。チュートリアルのサンプルの CScribDoc、CScribView、scribdoc.cpp と scribvw.cpp のやや一般的な名前を割り当てるを可能性があります。ビューの複数のクラスをアプリケーションが必要な場合は、ただし、おそらく最初の AppWizard で作成されたビュー クラス、CDataEntryView や CReportView などのより専門にされた名前をします。複数ドキュメント クラスとビュー クラスを作成するのには次の手順の関連情報を参照してください。

   どのような追加の AppWizard オプションが予想されることと、SDI または MDI などを OLE、今 AppWizard オプションを選択し、わずか数分で、スケルトン アプリケーションを作成することができますする必要があります。

4. 必要に応じて、2 番目のビュー、ドキュメント、およびフレーム ウィンドウ クラスのクローンを作成します。

   アプリケーションが複数のビュー、ドキュメント、またはフレーム ウィンドウ クラスが必要こと、上記の分析を判断した場合、[AppWizard を実行した後、これらのクラスのスケルトン コードが右を作成しても良い時間です。

   AppWizard で作成したものを複製して、追加の表示、ドキュメント、およびフレーム ウィンドウ クラスのスケルトン コードを作成できます。つまり、モジュールの新しい名前を 2 番目のドキュメントまたはクラスを割り当て、.cpp および .h ファイルをコピーします。クラス名を変更することによって、スケルトン コードを編集します。もう 1 つは ClassWizard の [クラスの追加機能を使用して、指定した名前を使用して指定したファイルに自動的に新しいクラスを作成することです。すでに (フリーハンド) チュートリアルを続いている場合、新しいクラスを作成するには、ClassWizard の能力とよくなります。

   いずれの場合で、 CWinAppの-派生クラスのInitInstance関数を間、複数のドキュメント、ビュー、およびフレーム ウィンドウ クラスにする任意団体のための追加のドキュメント テンプレート オブジェクトを登録する必要があります。

   これはまた、クイック ステップです。複数のドキュメント、ビュー、またはフレーム ウィンドウ クラスでアプリケーションを実装することにコミットしていない場合この手順を延期することができます。

5. AppWizard で作成したクラスに、MFC 1.0 コードの関連部分を移行します。

   このステップでは MFC 1.0 アプリケーションから MFC 2.0 への移行作業の大部分を表します。これを段階的に行う必要があります。比較的小さな塊にはアプリケーションの移行します。これを行うには、フレームワークが提供する機能、古い MFC 1.0 アプリケーション コードの一部を破棄することがについての詳細を学ぶ。

   コードのこれらのチャンクを移行するで」下の最小限の移行」を発表、点注意してください。これらのガイドラインの多くは完全な移行に適用されます。AppWizard は、コマンド ターゲット クラス (アプリケーション、ドキュメント、ビュー、およびフレーム ウィンドウ) に、//{{AFX_MSG と//{{AFX_MSG_MAP のコメントすでに追加になります。手動でこれらを最小限に抑えて移行アプローチと同様の下で追加の必要はありません。それは必要はありませんが、メッセージ処理関数のメッセージ マップに入れ子になった//{{AFX_MSG のコメントの間に移動することをお勧めします。これらのメッセージの処理 (afx_msg) 関数の宣言をヘッダー ファイル内の//{{AFX_MSG コメント間を移動します。そうすることによりプロジェクトの life cycle(s) の残りの部分で ClassWizard を使用になります。

   //{{AFX_MSG コメントに関するこれらの推奨事項、多分にも度が低い、ダイアログ ボックスに適用されます。特定のダイアログ クラスに多くの将来の変更を予測しないと、ダイアログ ClassWizard を認識するあなたの努力の価値はされません。それで結構です。もちろん、ClassWizard の [クラスの追加オプションを使用してすべての新しいダイアログ クラスを作成することお勧め。

   MFC 1.0 または Windows アプリケーションを移行すると、既存のファイル形式との互換性を維持したいと思うことがあります。(既定 MFC 2.0 ドキュメントのシリアル化機構をアプリケーションの適切なことがあります。)CFileの読み書きの呼び出し、またはドキュメント以外のファイルを実装するためにベースを直接行うには、 CDocument::OnOpenDocumentとOnSaveDocumentをオーバーライドします。MFC の一般的なサンプル DIBLOOKはこの手法の例を提供します。あなたの現在のアプリケーションがオブジェクトをシリアル化する場合は、[この問題はできません。

アルファベットの API の変更点

これらの変更の理由を理解するには、理由の変更」を「下ください。

変更の理由:

• 改善された機能。MFC 2.0 バージョンこの API の詳細や強化された機能は MFC 1.0 対応に提供します。
  
  
• STRICT準拠。MFC 2.0 API、厳格なWindows API に準拠に変更されました。
  
  
• Const 正確さ。堅牢なプログラムを促進するためには 'const' キーワードを正しく適用するには、MFC 2.0 API を修正しました。
  
  
• Win32 移植性。MFC 2.0 API が正しく簡単に MFC Win32 アプリケーションの移植を容易に Win32 API を反映するように変更されました。
  
  
• 減少のメモリ使用量。効率的なリンケージとが小さいアプリケーションのDGROUPの使用量を削減するメモリ利用技術を提供するために、MFC 2.0 API が変更されました。
  
  
• Win 3.1 の機能。MFC 2.0 API は正しく Windows 3.1 API の変更を反映するように変更されました。API は Windows 3.0 では、互換性のあるままですが、省略可能な Windows 3.1 のパラメーターのみが利用可能になりました。

コンパイラ エラー

コンパイラの標準的な型変換を満たす場合、MFC 2.0 api のほとんどの変更いくつかのコンパイラ エラー、または none のいずれかで生成されます。MFC 2.0 の下での既存の MFC 1.0 アプリケーションをコンパイルするとき、次のコンパイラ エラーを生成可能性があります。:

番号順テクニカル ノート|nbsp;カテゴリ別テクニカル ノート(&N)