TN019: Aktualisieren vorhandener MFC-Anwendungen auf MFC 3.0

Diese technische Hinweis enthält in erster Linie Richtlinien zur Migration von MFC 1.0-Anwendungen auf die MFC-2.0-Tools. Weitere Unterschiede zwischen MFC 2.0, 2.5 und 3.0 sind im ersten Abschnitt, unten dargestellt.

MFC 4.0/3.0 API ändert

Es gibt keine bekannten Änderungen an den dokumentierte MFC-APIs, die vorhandenen Code Änderungen erfordern würde. Natürlich gibt es viele zusätzliche Funktionen, denen Sie möglicherweise nutzen möchten. Weitere Informationen zu diesen Features finden Sie unter Visual C++ Programmer's Guide.

MFC 2.5 API ändert

MFC 2.5 zwei Hauptfeatures der Klassenbibliothek hinzugefügt: OLE 2.0-Unterstützung, die OLE-1.0-Unterstützung und ODBC-Unterstützung bietet Zugriff auf die Datenbank ersetzt. Es ist die Absicht dieser Technote zur Deckung der API-Änderungen, die den vorhandenen Code auswirken kann. Informationen über diese neuen Features nicht erfasst in dieser Technote finden Sie unter Visual C++ Programmer's Guide.

CFrameWnd::RecalcLayout verfügt über einen zusätzlichen Parameter, BOOL bNotify. Dies gibt an, ob alle OLE-Server benachrichtigt, dass sie Layout geändert hat. Es ist normalerweise wahr und daher das ist die Standardeinstellung. Diese Funktion ist gedacht, so stellt das Programm eine Überschreibung dieser Funktion müssen Sie Ihre Funktion als auch den zusätzlichen Parameter hinzu.

Es gab andere Änderungen an undokumentierte Funktionen in den Bibliotheken MFC 2.5 OLE 2.0 sowie ODBC Unterstützung. Wenn Ihr Programm nicht dokumentierte MFC-APIs verwendet, sollten Sie überprüfen alle solche verwendet, um sicherzustellen, dass sie noch gültig sind.

Migrieren von MFC 1.0 Anwendungen mit MFC 2.0

WICHTIG: Um verstehen und bewerten die beiden Ansätze dargestellt, müssen Sie mit MFC 2.0 Konzepte, wie das Dokument und Ansicht Architektur und den Tools vertraut sein. Wir schlagen vor, Sie arbeiten zumindest durch die MFC-Tutorial-Probe Skizze in Tutorials vor Beginn jeder Migration von vorhandenem Code.

Es gibt zwei grundlegende Ansätze zur Migration von vorhandenen Anwendungen von MFC, Version 1, mit Microsoft C7, MFC Version 2 veröffentlicht.

Minimale Migration

Mit der "Minimal Migration"-Methode, Sie machen nur minimalen Änderungen erforderlich, damit:

• Die vorhandene MFC 1.0-Anwendung kompiliert und verknüpft erfolgreich mit der MFC 2.0 Bibliotheken.
  
  
• Ihre Ressourcen können erfolgreich mithilfe von Visual C++ bearbeitet werden.
  
  
• Ihre Meldungshandlerfunktionen und Dialogfelddaten werden von Klassen-Assistenten erkannt.

Dies ist der einfachste Ansatz, aber es dauert nicht vollen Nutzen aus der umfangreichen Features in der MFC 2.0-Bibliothek. Auch wenn Sie die Methode "Vollständige Migration" gewählt haben, müssen Sie verstehen und üben Techniken für minimale migration.

Vollständige Migration

Wenn Sie eine "vollständige Migration" ausführen, können Sie voll von der MFC 2.0-Bibliothek nutzen. Die minimale Migrationsmethode verwenden, werden Sie in der Lage, die Anwendung mit Visual C++ und Klassen-Assistenten bearbeiten. Die vollständige Migration-Methode verwenden, erhalten Sie die folgende MFC-2.0-Unterstützung:

• Datei Menü und Dialogfeld Benutzer Standardschnittstellen. Sie Funktionen wie z. B. standard-Datei öffnen und Speichern Dialoge, Dateimanager, Drag-and-Drop, kürzlich verwendete Datei Menüoberfläche, usw.
  
  
• Drucken. Sie liefern den Code anzeigen; die Bibliothek übernimmt immer den Drucker DC, Aufstellen von den Abbruch im Dialogfeld Ausführen die Druckschleife, und so weiter.
  
  
• Druckvorschau. In der Regel müssen Sie keine zusätzliche Codierung zu Print Preview-Funktionalität in Ihrer Anwendung zu tun.
  
  
• Symbolleisten und Statusleisten. Jetzt sind sie einfach zu Ihrer Anwendung mithilfe von Visual C++ und MFC 2.0 hinzufügen.
  
  
• Splitterfenster. Wenn Sie Ihre Anzeige-Code Ansicht Klassen strukturieren, dann werden können sie im Teilfenster sehr wenig zusätzliche Kosten darstellen Sie.
  
  
• OLE2-Unterstützung. Durch die Verwendung von "Dokument-/Ansichtarchitektur" kann Ihre Anwendung wahrscheinlich OLE ohne eine erhebliche Menge an Arbeit aktiviert werden.

Die insgesamt vollständige Migration-Methode ist im Grunde zu emulieren, entwickeln einer MFC 2.0-Anwendung von Grund auf, beginnend mit der Anwendungs-Assistent. Der Unterschied zum Entwickeln einer MFC 2.0-Anwendung von Grund auf, ist natürlich, dass Sie so viel von der MFC 1.0-Code, die Sie schrieb leihen werden, wie sinnvoll ist.

Minimale Migration

In den folgenden Unterabschnitten präsentieren detaillierte Leitlinien für die Durchführung einer Migration minimalen.

Konform mit Windows 3.1 strenge Typdefinitionen

Standardmäßig erstellt der MFC 2.0 Bibliothek unterliegt die Windows 3.1 STRICT Typdefinitionen, die in der Windows 3.1 SDK erläutert werden. MFC 1.0 STRICT deaktiviert hatte, aber jetzt MFC 2.0 hat strenge standardmäßig aktiviert. Dies folgt MFC Engagement das Industrie-standard-Windows-API nachverfolgt und Entwicklungsverfahren zu fördern, die Entwicklung stabile Anwendungen einfacher zu machen. Genauso wie die STRICT -Typdefinitionen hilfreich sein, die Entwickler der MFC 2.0 Klassen robuste Software zu produzieren, also werden, die bei der Entwicklung Ihrer Anwendung Codes für Sie wahr.

Wenn Sie strenge Typüberprüfung, die zum ersten Mal verwenden, werden in der Regel viele Kompilierungsfehler ergeben. Ändern die MFC 1.0-Anwendung Windows 3.1 STRICT Typdefinitionen entsprechend kann den Großteil Ihrer minimalen Migrationsaufwand sehr gut darstellen.

Wenn Ihre Anwendung strengeinhält, möglicherweise Sie kompilieren Sie eine ausführbare Datei ohne weitere Änderungen. Beispielsweise kompilieren ABOUT2 und FILEVIEW MFC 1.0 Proben ohne weitere Änderungen. Sie waren schon streng konform und haben nicht verwendet jeder geändert MFC-APIs.

MFC 2.0 API ändert

Jenseits, STRICTentsprechen, ist die meisten der Bemühungen der dabei einer minimalen Migration zu identifizieren und ändern Ihr Anwendungscode, um die relativ wenigen MFC 2.0 API-Änderungen zu entsprechen.

Von mehr als 1800 MFC 1.0 APIs geändert der APIs, die waren nur 20 Kompilierzeitfehler führen. Diese Veränderungen erfordern nur triviale Änderungen an vorhandenen MFC 1.0-Anwendungen. Die umfangreichsten Änderungen sind die architektonischen Umstrukturierung der OLE-Klassen. Diese Änderungen sind im technischen Hinweis 18 abgedeckt.

Zu erwarten, welche Änderungen Sie müssen zu machen, finden im Abschnitt "Alphabetische API Changes" am Ende dieser Technote. Es bietet eine nützliche, kurze Zusammenfassung der die MFC 1.0 APIs in MFC 2.0 geändert wurden.

Wenn Sie nicht alle Änderungen mit MFC 2.0 Code notwendig machen, erhalten Sie verschiedene Kompilierung und Verknüpfung Fehler. Diese Störungen sind fast immer einfach zu diagnostizieren. Um Ihre Diagnose zu unterstützen, bieten wir einige Richtlinien im Abschnitt "Compiler-Fehler" am Ende dieser technote.

Die folgenden MFC-APIs wurden in MFC 2.0 entfernt. Gegebenenfalls sollten alternative APIs. Diese Liste enthält keine Änderungen an undokumentierte Umsetzung APIs.

CDC::GetDCOrg

GetDCOrg ist nicht verfügbar in Win32. Für Windows 3.x nur Anwendungen, rufen Sie die Windows-API :: GetDCOrg direkt.

CRuntimeClass::m_pszClassName

Diese Membervariable ist jetzt ein LPSTR anstatt der Speicher modellabhängige (Char **). Es ist M_lpszClassName in MFC 2.0 benannt.

CMDIChildWnd::m_pMDIFrameWnd

In MFC 1.0 wies diese Membervariable auf die Klasse MDIFrame Eltern. Diese Member-Variable wurde mit CMDIChildWnd::GetMDIFrameeine Member-Funktion ersetzt. Wenn Sie mehrfache Dokumentschnittstelle (MDI) in MFC 2.0 verwenden, sind die meisten Verwendungen CMDIChildWnd::m_pMDIFrameWnd (oder GetMDIFrame) nicht mehr notwendig, da die Standard MDI-Unterstützung alle die Standardbefehle im Menü MDI-Fenster behandelt.

CFrameWnd::GetChildFrame

Verwenden Sie stattdessen CMDIFrameWnd::MDIGetActive für MDI-Bilder.

Die folgende API hinterließ in MFC 2.0 1 Kompatibilität unterstützen aber ist veraltet. Es wird von künftigen Versionen von MFC entfernt werden.

CMDIFrameWnd::CreateClient

Diese Funktionalität wurde durch die allgemeinere OnCreateClient Mechanismus ersetzt, die Ansichtserstellung und die verbesserte 2.0 MFC-MDI-Unterstützung unterstützt. Die ursprüngliche CreateClient kann noch für MDI-Anwendungen verwendet werden, die ihre eigenen MDI-Rahmenfenster Menüleiste verwalten (mit CMDIFrame::MDISetMenu). Die MFC 2.0 MDI-Unterstützung schaltet automatisch das MDI-Rahmenfenster Menüleiste auf das Menü für das momentan aktive untergeordnete MDI-Fenster.

Andere API-Änderungen in der

Zwei MFC-Klassen wurden von der afxwin.h in der Header-Datei afxext.h verschoben:

• CBitmapButton
  
  
• CMetaFileDC

Fügen Sie in Ihre .cpp-Dateien, die diese Klassen verweisen folgende:

# include lt;afxext.h>

Viele APIs wurden verändert, so dass sie über die Verwendung des Modifizierers 'const' strenger sind. Diese Änderungen führen eine konsistentere Verwendung von den LPCSTR Typnamen und den neuen LPCRECT-Typnamen. Beachten Sie, gibt es kein kompilieren Zeit Problem mit diesen Änderungen, da jede Art gefördert werden kann, zu einer const Version dieses Typs als Argument verwendet. Wie die STRICT zu ändern führt dies zu stabileren Code wenn Ihr Code const Zeiger Daten verwendet.

Die Fenster Erstellen folgenden Funktionen jetzt haben einen zusätzlichen Parameter, aber seit der letzte Parameter einen Standardwert von NULL hat, vorhandener Code funktioniert unverändert. Diese Funktionen sind

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

Die folgenden Funktionen wurden in MFC 1.0 virtuelle aber sind jetzt nicht virtuelle MFC 2.0:

• CFile::GetStatus
  
  
• CFrameWnd::GetParentFrame

Wenn eine abgeleitete Klasse von der MFC 1.0-Anwendung diese Funktionen außer Kraft setzt, ist es unwahrscheinlich, dass die Funktion in der abgeleiteten Klasse, in MFC 2.0 aufgerufen wird. Darüber hinaus GetParentFrame von CFrameWnd CWnd zog nach zu einem generell nützliche API.

Alle statischen Member der Klassen, sowie globale Operator/Friend-Funktionen, halten sich nun an PASCAL Aufrufkonventionen. Alle globale Funktionen sind AFXAPI (PASCAL). Wieder, dies ist kein Problem Mal kompilieren, sondern führt zu schneller und kleiner generierten code.

Viele der Implementierung nur Klassen und Strukturen wurden umbenannt, nicht das 'C'-Präfix verwenden. Zum Beispiel wurde CExceptionContext in AFX_EXCEPTION_CONTEXTumbenannt. Diese Klassen sind nicht dokumentiert und bleiben Implementierungsdetails der Klassenbibliothek. Es ist unwahrscheinlich, dass Sie sich auf diesen verlassen haben, und es im Allgemeinen empfohlen wird, dass Sie nicht auf undokumentierte APIs in der Klassenbibliothek verlassen, da sie in zukünftigen Versionen geändert werden.

MFC 2.0 ändert das standardmäßige Verhalten

Umgang mit Änderungen in der MFC-API ist einfach mit Hilfe der Fehler gemeldet von Compiler und Linker. Nicht alle Bibliotheksänderungen werden jedoch in den Bibliothek-Headerdateien, aufgedeckt. Einige Änderungen sind in Laufzeitverhalten Ihrer Anwendung ergeben. Diese Änderungen sind in der Regel nicht schwer zu behandeln, solange Sie sie erwarten. Die folgenden Informationen helfen Ihnen solche Verhaltensänderungen erwarten.

CDialog und CModalDialog haben in einer einzelnen Klasse zusammengeführt wurden. CModalDialog gilt jetzt als eine veraltete Klasse. Allerdings gelten für MFC 1.0 Kompatibilität, alle Verweise auf CModalDialog noch durch ein Makro Migration in afxwin.h:

# define CModalDialog CDialog

Für viele MFC 1.0-Anwendungen, diese einfach # define ist ausreichend. Es gibt jedoch Fälle, wo diese # definieren reicht nicht aus.

Wenn Sie ein nicht-modales Dialogfeld implementiert und stützte sich auf das Standardverhalten von "nichts tun" für OnOK und OnCancel, dann müssen Sie diese und das Standardverhalten, da sie jetzt rufen Sie EndDialog (für ein modales Dialogfeld Verarbeitung).

CDialog::CreateIndirect wird noch ein nicht-modales Dialogfeld erstellt. Erstellen ein modales Dialogfeld verwenden CDialog::InitModalIndirect anstelle der entfernten CModalDialog::CreateIndirect API.

Dialogfeld Feld und Nachricht Feld Hintergrundfarben können jetzt mit der CWinApp::SetDialogBkColor API Global festgelegt werden. Die Standard-Parameters wird die Farbe hellgrau (nicht COLOR_BTNFACE) grau Hintergrund produzieren. Sie können andere Farben angeben.

Wenn SetDialogBkColor nicht, in Ihrem CWinApp aufgerufen wird-abgeleitete Funktion InitInstance , Standard Fenster-Hintergrund Farbe (festgelegt in der Color Control Panel Applet) dient.

In MFC 1.0 Wenn eine DLL ein CWinApp -Objekt enthalten, war es notwendig eine DllMain bereitstellen, die einen Aufruf von AfxWinTermenthalten. MFC 2.0 bietet diese DllMain, also keine zusätzlichen Code enthalten, der Ihre DllMain migriert werden sollte, um die DLL CWinApp::ExitInstance Member-Funktion.

CMDIChildWnd::Create wird jetzt korrekt den DwStyle -Parameter verwendet. Sie müssen nun eine komplette Fensterstil für das untergeordnete MDI-Fenster festlegen. Wenn Sie DwStyle angeben = 0, Sie erhalten nun einen ASSERT -Fehler in CMDIChildWnd::PreCreateWindow. Um dies zu vermeiden, sollten Sie den Style WS_CHILD | WS_VISIBLE | WS_OVERLAPPEDWINDOW abwärtskompatibel mit MFC 1.0.

MFC 2.0 unterstützt Einstellung verschiedene Stile für untergeordnete MDI-Fenster, damit Sie einige der Steuerelemente Frame-Fenster, entfernen können, falls gewünscht.

Klasse CFrameWnd hat ein neues Datenelement, BOOL CFrameWnd::m_bAutoMenuEnable. Es ist festgelegt auf TRUE standardmäßig. Dies bewirkt, dass Menüelemente, die das nicht haben ON_UPDATE_COMMAND_UI oder ON_COMMAND Handler automatisch deaktiviert werden. Menüelemente, die Handler ON_COMMAND , aber keine ON_UPDATE_COMMAND_UI -Handler werden automatisch aktiviert.

Dies erleichtert das optionale Befehle, basierend auf der aktuellen Auswahl zu implementieren. Auch, dies reduziert die Notwendigkeit für Anwendungen, ON_UPDATE_COMMAND_UI -Handler für Aktivieren/Deaktivieren von Menüelementen zu schreiben. Zum Beispiel haben eine Anwendungs-Assistenten generierte Anwendung bearbeiten Ausschneiden/Kopieren/Einfügen deaktiviert, bis der Programmierer Handler für sie implementiert.

Jedoch, wenn die MFC 1.0-Anwendung mithilfe von ON_COMMAND und ON_UPDATE_COMMAND_UI -Handler nicht aktualisiert wird, muss es M_bAutoMenuEnable explizit deaktivieren. Ansonsten, Menüs, die Sie deaktivieren automatisch aktiviert werden.

Projektänderungen (Build)

Sie können weiterhin die MFC 1.0-Anwendung mithilfe einer standard-Makefiles erstellen. Bei weitem ist die einfachste Möglichkeit, Ihr Projekt zu migrieren, die Visual C++-Projekt-Anlage verwenden, um Ihre Depedencies und andere Projektoptionen in der Visual C++-Umgebung pflegen.

Ein häufiger Fehler der Verbindung ist nicht aufgelöste externe Verweise auf die Datei COMDLG32.DLL und SHELL32.DLL APIs. Achten Sie darauf, Verknüpfung mit Datei COMDLG32.LIB und SHELL32.LIB.

Sie können möglicherweise zur Verbesserung der Build Mal durch Platzieren # gehören lt;afxwin.h > in einen vorkompilierten Header. Gemäß der Konvention angeben MFC 2.0-Anwendungen "stdafx.h" als den vorkompilierten Header. Dann Modul stdafx.cpp stdafx.h enthält. Diese Technik wird durch den Code erstellt der Anwendungs-Assistent, und viele der MFC 2.0 Beispiele illustriert.

Hinweis&Nbsp;  Es ist wichtig, dass Sie weder definieren noch der _AFX_NO_XXX-Makros in stdafx.h undefinieren. Finden Sie im Knowledge Base-Artikel "PRB: Probleme auftreten, wenn _AFX_NO_XXX definieren." Knowledge Base-Artikel finden auf der MSDN Library-CD oder unter http://www.microsoft.com/kb/ Sie.

Visual C++ und ClassWizard Kompatibilität

Auch für minimale Migration, empfehlen wir, dass Sie die folgenden Schritte so, dass Sie Visual C++ und Klassen-Assistenten verwenden können, um Ihre Anwendungsressourcen und Code zu bearbeiten.

• Fügen Sie für ein beliebiges Modul dessen Meldungszuordnung, die mit Klassen-Assistenten bearbeiten möchten die folgenden zwei Kommentarzeilen in der CPP-Datei außerhalb von jeder Funktion-Implementierungen:

  //{{AFX_MSG_MAP (Lt; Klassenname >)
  //}}AFX_MSG_MAP
  

  Lt; Klassenname > ist der Name der Klasse, die die Meldungszuordnung enthält.

  Ebenso fügen Sie die folgenden zwei Kommentarzeilen innerhalb der Deklaration der entsprechenden Klasse in der .h-Datei:

  //{{AFX_MSG (Lt; Klassenname >)
  //}}AFX_MSG
  

  Betrachten Sie ein Beispiel für diese Erklärungen die gleichen Kommentarzeilen in einer beliebigen Anwendung erstellt von AppWizard. Eine Erläuterung dessen, was diese Kommentarzeilen sehen MFC: Verwenden der MFC-Quelldateien im Visual C++ Programmer's Guide.

• Das Projekt muss eine Makefile-Datei mit dem Namen Lt; Projekt > .mak und eine Ressourcendatei mit dem Namen <project> RC, wobei <project> der Name des Projekts ist. Beide Dateien müssen in das Projekt Stammverzeichnis befinden. Die.MAK-Datei ist möglicherweise ein externes makefile.
  
  
• ClassWizard aus innerhalb von Visual C++ ausführen. Wenn ClassWizard entdeckt, ein.CLW-Datei ist nicht vorhanden, es fragt Sie, ob Sie erstellen möchten. "Ja" Antworten. Die.CLW-Datei ist im Wesentlichen eine Indexdatei, die Klassen-Assistent wird verwendet, um Module zu identifizieren, die haben solche Kommentarzeilen //{{AFX_MSG.
  
  
• Fügen Sie für jedes Modul mit deren virtuellen Funktionen, die Sie mit ClassWizard bearbeiten möchten die folgenden zwei Kommentarzeilen innerhalb der Klassendeklaration in der .h-Datei:

   //{{AFX_VIRTUAL (Lt; Klassenname >)
  //}}AFX_VIRTUAL
  

Vollständige Migration

Eine vollständige Migration der vorhandenen c oder MFC 1.0 Anwendung MFC 2.0 bietet Ihnen alle Vorteile der MFC 2.0. Für die meisten Anwendungen eine vollständige Migration ist nicht schwer und lohnt sich der Aufwand.

Eine erfolgreiche vollständige Migration einer Anwendung MFC 2.0 erfordert im Wesentlichen das gleiche Verständnis der MFC 2.0 als eine neue Anwendung von Grund auf neu zu entwickeln. Sie sollten sich vertraut machen mit der MFC 2.0-Klassenbibliothek, Visual C++ AppWizard und ClassWizard, bevor Sie die vollständige Migration beginnen. Sie sollten verstehen, welche Teile des Codes Anwendung können sein entfernt durch gleichwertige oder verbesserte Funktionalität von 2.0 MFC-Klassen ableiten. Nicht nur wird mit mehr der Bibliothek Umsetzung Ihren Source-Code kleiner, aber es wird machen diese Teile der Anwendung besser mit dem Rest des MFC-Frameworks integriert.

Durch voll Ihre Anwendung MFC 2.0 migrieren, werden Sie relativ wenig zusätzliche Funktionen von MFC ableiten können zusätzliche Kosten. Beispielsweise wenn Ihrer Anwendung eine Splitter-Fenster-Benutzeroberfläche nicht haben, aber man sinnvoll, die Benutzer wäre, können dann schnell dieses Feature hinzufügen Sie den Code des MFC 2.0 Dokument-/Ansichtarchitektur haben bereits portiert.

Obwohl eine vollständige Migration zu MFC 2.0 ein paar Tage Aufwand für große Anwendungen erfordern kann, ist der Prozess selbst relativ einfach. Die folgenden allgemeinen Schritte beschreiben den Prozess:

1. Alysieren Sie an, wie Ihre vorhandenen Anwendungsarchitektur in Dokument, Ansichten und Rahmenfenster Faktoren.

   Tun Sie dies, bevor Sie Code bearbeiten zu starten. Viele Programmierer neigen dazu, ineinander dokumentieren von Code mit Code anzeigen. Obwohl dies nicht unbedingt "schlecht" ist, ist die Trennung von Dokument und Ansicht Funktionalität ein Design-Philosophie, die vom MFC-Framework befürwortet und unterstützt besonders gut. Obwohl MFC 1.0 CDocument und CView -Klasse nicht hatte, billigte es auch Dokument-/Ansichtarchitektur Trennung. So werden Sie alle zukünftige Versionen der Bibliothek.

   Studie der MFC 2.0-Beispiele, die die Klassen CDocument und CView , besonders die MFC-Tutorial-Beispiel verwenden Skizze. Dann Alysieren Sie Ihrer Anwendung zu bestimmen, was das Dokument ist und was die Ansicht ist an. Bestimmen Sie, ob Ihre Anwendung mehrere Dokumenttypen oder Ansichten.

   Auch wenn Ihre Anwendung nicht selbst löschen Sie Dokument-/Ansichtarchitektur Trennung verleihen, werden Sie noch in der Lage, vollständig auf MFC 2.0 migrieren und im wesentlichen vollständige Nutzen des Rahmens. Sie können "fake" Dokument-/Ansichtarchitektur Trennung durch die Implementierung von CDocument- und CView-abgeleitete Klassen, aber Ihr Dokument oder Ansicht, die Klasse die meisten seiner Arbeit auf die andere Klasse delegieren kann. Oder der Ansichtsklasse möglicherweise verlassen sich auf Ihre CFrameWnd- oder CMDIChildWnd-abgeleitete Klasse den Großteil der Benutzeroberfläche Ihrer Anwendung zu implementieren. Zusammenfassend haben Sie fast völlige Freiheit, wie Sie Ihre Dokument-, Ansichts- und Rahmenfensterklassen zu trennen.

   Ihre Analyse sollte auch bestimmen, ob Ihre Anwendung mehrere Ansichtsklassen und möglicherweise mehrere Dokumentenklassen benötigt. Auch relativ einfache Anwendungen brauchen manchmal mehr als eine View-Klasse. Mehrere Ansichten, z. B. in einem unterteilten Fenster, nicht jedoch notwendigerweise diktieren, haben Sie mehrere CView-abgeleiteten Klassen. Beispielsweise stellt jeder Bereich des Splitterfensters dieselbe Benutzeroberfläche wie andere Bereiche im Splitterfenster, können dann sie teilen die gleiche Ansichtsklasse. In diesem Fall ist jeder Bereich einfach eine unterschiedliche Objekt derselben Ansicht Klasse. Sie werden wahrscheinlich wollen entwerfen mehrere Ansichtsklassen, wenn Ihre Anwendung in verschiedenen Fenstern sehr unterschiedliche Benutzeroberflächen bereitstellt.

2. Alysieren Sie welche AppWizard-unterstützten Framework-Features die Anwendung benötigen an.

   Anwendungs-Assistent wird ein Skelett 2.0 MFC-Anwendung erstellen, die verschiedenen Framework-Features unterstützt, die Sie als Optionen in AppWizard Dialogen auswählen. Vor dem Ausführen der Anwendungs-Assistent zum Erstellen einer Skelett Anwendungs sollten Sie zunächst mit den Optionen vertraut, die der Anwendungs-Assistent bietet.

   Nehmen Sie ein wenig Zeit zu entscheiden, welche der Anwendungs-Assistent Optionen, die Sie auswählen möchten. Versuchen Sie nicht, dies in wenigen Minuten zum ersten Mal tun, wenn Sie der Anwendungs-Assistent ausführen. Beispielsweise wenn die Anwendung nicht bereits OLE unterstützt, ist dies eine wichtige Entscheidung, die Sie betrachten wollen. Wenn Sie nicht ausgewählt haben, der AppWizard OLE Option, um mit zu beginnen, werden Sie noch in der Lage, Ihr Anwendungscode mithilfe von MFC OLE-Funktionen ändern. Aber beginnend mit der OLE-Option im Anwendungs-Assistenten beginnen mit sparen Sie Zeit.

   Ihre Analyse sollten ermitteln, ob Ihre Anwendung eine einfache Dokumentschnittstelle (SDI) oder Anwendung multiple Document Interface (MDI) ist. Diese besondere Bestimmung sollte offensichtlich, wenn Sie mit diesen zwei verschiedene Benutzeroberflächen in anderen Windowsanwendungen vertraut sind. AppWizard erstellt MDI-Anwendungen standardmäßig da die MDI-Benutzeroberfläche ermöglicht es ihnen in der Regel funktioneller für Endbenutzer ist öffnen mehr als ein Dokument/Datei zu einem Zeitpunkt. Glücklicherweise erfordert MFC 2.0 Dokument/Ansicht-Architektur unterstützt MDI keine zusätzliche Codierung ihrerseits.

3. Generieren Sie eine neue Anwendung mit Anwendungs-Assistenten.

   Die vorstehende Analyse getan zu haben, können Sie jetzt AppWizard der Gerüstcode für Ihre Anwendung erstellen ausführen.

   Er analysiert, wie Ihre Anwendung in Dokument, Ansichten und Rahmenfenster trennt, sollten Sie eine gute Idee welche Namen um ihre entsprechenden Klassen und Modulen zu haben. Vielleicht möchten etwas generische Namen, wie z. B. die Lernprogrammbeispiel CScribDoc und CScribView, und scribdoc.cpp und scribvw.cpp zuweisen. Jedoch, wenn Ihre mehrere Ansichtsklassen Anwendung, wahrscheinlich sollten Sie der ersten Ansichtsklasse der der Anwendungs-Assistent erstellt einen speziellen Namen, wie CDataEntryView und CReportView geben. Den nächsten Schritt für weitere Informationen zum Erstellen mehrerer Dokument- und View-Klassen finden Sie.

   Welche Zusatzoptionen AppWizard erwartet haben soll, wie z. B. SDI- oder MDI, und OLE, nun sollten Sie in der Lage, wählen die Optionen des Anwendungs-Assistenten und erstellen Sie in wenigen Minuten die Skelettanwendung.

4. Optional zweite Ansicht, Dokument und Rahmenfensterklassen zu klonen.

   Die obige Analyse fest, dass Ihre Anwendung mehrere Ansicht, Dokument oder Rahmenfensterklassen haben sollten, dann ist es ein guter Zeitpunkt, um den Skelett Code für diese Klassen richtig zu erstellen, nach dem Ausführen der Anwendungs-Assistent.

   Sie können der Gerüstcode für zusätzliche Ansicht, Dokument und Rahmenfensterklassen Klonen erstellt von AppWizard diejenigen erstellen. Das heißt, kopieren Sie die cpp- und .h-Dateien, den Modulnamen einer neuen für das zweite Dokument oder Klasse zuweisen. Bearbeiten Sie dann den Skelett Code durch Klassennamen ändern. Eine weitere Alternative ist es, den Klassenassistenten hinzufügen Klasse Funktionalität verwenden, um eine neue Klasse automatisch in den Dateien erstellen, die Sie angeben, mit den Namen, den, die Sie angeben. Sie werden bereits vertraut mit den Klassenassistenten Fähigkeit, neue Klassen erstellen, wenn Sie die SCRIBBLE-Anleitung befolgt haben.

   In jedem Fall in Ihrem CWinApp-abgeleitete Klasse muss die Funktion InitInstance , zusätzliches Dokument Vorlagenobjekte für alle Verbände, die Sie zwischen Ihnen mehrere Dokument-, Ansichts- und Rahmenfensterklassen machen möchten müssen Sie sich registrieren.

   Dies ist auch eine schnelle Schritt. Sie können diesen Schritt aufschieben, wenn Sie nicht zur Umsetzung mehrerer Dokumente, Ansichten und Rahmenfensterklassen in Ihrer Anwendung verpflichtet.

5. Übergehen Sie die Klassen, die von der Anwendungs-Assistent erstellt die relevanten Teile des Codes MFC 1.0.

   Dieser Schritt stellt den Großteil der Arbeit in die MFC 1.0-Anwendung MFC 2.0 migrieren. Sie sollten dies schrittweise tun. Relativ kleine Stücke der Anwendung gleichzeitig zu migrieren. Wie Sie dies tun, erfahren Sie mehr über welche Funktionen, die das Framework bietet, Ihnen einige der alten MFC 1.0-Anwendungscode verwerfen erlaubt.

   Wie Sie diese Stücke von Code migrieren, halten Sie im Verstand der Richtlinien unter "Minimaler Migration" dargestellt. Viele von diesen Leitlinien gelten für vollständige Migration. AppWizard wird bereits die //{{AFX_MSG und //{{AFX_MSG_MAP Kommentare zu Ihrem Befehl Zielklassen (Anwendung, Dokument-, Ansichts- und Rahmenfenster) hinzugefügt haben. Es ist nicht notwendig für Sie diese manuell wie unter der minimalen Migrationsansatz hinzufügen. Obwohl es nicht erforderlich ist, empfehlen wir, dass Sie zwischen die //{{AFX_MSG Kommentare geschachtelt in der Meldungszuordnungen Message-Handling Funktionen verschieben. Auch, verschieben Sie die Erklärungen dieser Handhabung von Nachrichten (Afx_msg) Funktionen zwischen den //{{AFX_MSG Kommentaren in Headerdateien. Dabei können Sie verwenden Sie Klassen-Assistent im weiteren Verlauf des Projekts life cycle(s).

   Diese Empfehlungen in Bezug auf //{{AFX_MSG Kommentare gelten auch, vielleicht in geringerem Maße, um Dialoge. Wenn Sie viele zukünftige Änderungen an einer bestimmten Dialogfeldklasse nicht erwarten, könnte es nicht Wert Ihre Bemühungen, diesen Dialog ClassWizard-bewusst zu machen sein. Das ist in Ordnung. Wir empfehlen allerdings, dass Sie alle neuen Dialogfeldklassen mithilfe des Klassen-Assistenten Klasse hinzufügen Option erstellen.

   Wie Sie eine MFC 1.0 oder Windows-Anwendung migrieren, können Sie Kompatibilität mit vorhandenen Dateiformaten zu gewährleisten. (Der Serialisierungsmechanismus Standard MFC 2.0-Dokument möglicherweise nicht für Ihre Anwendung geeignet.) Um CFile schreiben und lesen Anrufe, oder eine nicht-Datei implementiert basierte Dokument direkt zu tun, werden Sie CDocument::OnOpenDocument und OnSaveDocumentüberschreiben möchten. Im allgemeinen MFC-Beispiel DIBLOOK-Anwendung enthält ein Beispiel für diese Technik. Wenn die aktuelle Anwendung bereits Objekte serialisiert, wird dann dies kein Problem sein.

Alphabetische API-Änderungen

Um die Gründe für diese Änderungen zu verstehen, lesen Sie bitte "Grund für Änderungen" unter.

Gründe für Änderungen:

• Verbesserte Funktionalität. Die MFC 2.0 Version dieser API bietet gegenüber Gegenstück MFC 1.0 mehr oder verbesserte Funktionen.
  
  
• STRICT -Konformität. Die MFC-2.0-API wurde geändert, um die STRICT -Windows-API entsprechen.
  
  
• Const Richtigkeit. Die MFC-2.0-API wurde behoben, das 'const' Schlüsselwort zu robustere Programmen erleichtern ordnungsgemäß anzuwenden.
  
  
• Win32-Portabilität. Die MFC-2.0-API wurde geändert, auf der Win32-API ermöglicht einfache Portierung von MFC-Anwendungen auf Win32.
  
  
• Reduzierter Speicherverbrauch. Die MFC-2.0-API wurde geändert, um mehr effektive Verknüpfung und Speicher-Auslastung Techniken, die kleinere Anwendungen und reduzierte DGROUP Verwendung führt.
  
  
• Win 3.1 Funktionalität. Die MFC-2.0-API wurde geändert eine Windows 3.1 API-Änderung korrekt widerspiegeln. Die API weiterhin mit Windows 3.0 kompatibel, aber optionale Windows 3.1 nur Parameter stehen jetzt zur Verfügung.

Compiler-Fehler

Die meisten Änderungen an den MFC-2.0-APIs generiert eine der wenigen Compiler-Fehler oder keine überhaupt Wenn standard Typkonvertierungen den Compiler erfüllen. Die folgenden Compilerfehler können generiert werden, wenn vorhandene MFC 1.0-Anwendungen unter MFC 2.0 kompilieren:

Technische Hinweise von &Nummer |nbsp; Technische Hinweise nach Kategorie