Hinweis&Nbsp; Diese technischen Hinweis wurde für Windows 3.1 geschrieben. Windows NT implementiert die meisten dieser Funktionen. Wenn Ihre Anwendung unter Windows 3.1 (mit Win32s DLLs) ausgeführt, können diese Techniken bei der Fehlersuche helfen. Auch Windows 95 implementiert und erweitert die Robustheit-Features in Windows 3.1 eingeführt. Die Debug-Version von Windows 95 ausgeführt wird, dass der beste Weg, Ihre Bewerbung zu versichern sauber ausgeführt wird.
Windows 3.1 ist eine große Verbesserung gegenüber Windows 3.0 im Bereich der Entwicklung von robusten Anwendungen. Windows 3.1 enthält eine Reihe von neuen Features, die die Zuverlässigkeit von einer Windows-Anwendung zu verbessern. Diese technische Hinweis beschreibt die Verwendung dieser Features in der MFC-Bibliothek.
Zu diesen Features gehören die Debug-Kernel, strenge Typüberprüfung, Diagnose und Speicherverwaltung und der WINDOWSX.H-Erweiterungen.
Windows 3.1-Debug-Kernel
Hinweis&Nbsp; Dieser Abschnitt gilt nur für Microsoft Visual C++, Version 1.5.
Testen der MFC-Anwendungs mit der ausführbaren Dateien der Debug-System ist wahrscheinlich das beste, was, das Sie tun können, um sicherzustellen, dass Ihre Anwendungen robust und zuverlässig sind. Die Debuggen Versionen von ausführbaren Dateien System führen Sie allerlei nützliche Fehlerprüfung für Sie, informieren Sie über auftretende Probleme mit Debug Ausgabemeldungen.
Am besten verwenden Sie das Debug-System ist mit zwei Maschinen: eine Maschine zum Testen und Debuggen, die hat das Debug-System installiert und eine Maschine für Entwicklung. Eine Maschine, dem Testcomputer, sollte immer mit dem Debug-Kernel ausgeführt. Die andere Maschine, Ihre Entwicklung, sollte mit dem nicht-Debug-Kernel ausgeführt. Die Ausgabe aus dem Debug-Kernel kann über ein null-Modem-Linie auf dem primären Computer gesendet werden. Wenn Sie nur einen einzelnen Computer haben, dann sollte unbedingt der Debug-Kernel laufen (es gibt einen leichten Leistungsabfall). Die Ausgabe aus dem Debug-Kernel kann an DBWIN, ein Tool im Lieferumfang von Microsoft Visual C++, Version 1.5 weitergeleitet werden. Darüber hinaus wird im Ausgabefenster von Visual C++ Ausgabe erhalten, wenn unter dem Debugger ausgeführt.
Ein nützlicher Trick für einzelne Computer Debuggen ist an Kopien der System- und Debug-Binärdateien und Symbole in einem separaten Verzeichnis speichern und Batch-Dateien haben, die die entsprechenden Dateien auf Ihrem Windows System-Verzeichnis kopieren. Auf diese Weise können Sie Windows beenden und schalten schnell hin und her zwischen Debug- und nicht-Debugversion. Das Programm Visual C++ Version 1.5 Installation verlegen dieses rauf, dann Sie können wechseln zwischen Debug- und nicht-Debug-Version von Windows mit der D2N.BAT und N2D.BAT Batch-Dateien.
Wenn Sie mit einem Debugger oder ein Debug-Terminal nicht ausgeführt wird, führen Sie die Anwendung DBWIN, so können Sie die Fehler- und Warnmeldungen, die von der Debug-System produziert. Diese Anwendung ist im Lieferumfang von Visual C++ Version 1.5.
Im folgenden werden einige häufige Fehler in der Programmierung, die häufig in mitgelieferten Windows-Anwendungen angezeigt werden. Viele dieser Probleme können dazu führen, dass zufällige System UAEs und anderen Problemen unter Windows 3.0. Die Debugbinärdateien System hilft Ihnen, Probleme, wie z. B. aufzuspüren:
MFC-Diagnose
Darüber hinaus der Microsoft Foundation Classes Schiff mit einer Robustheit-Features, die kompiliert und nur in Debugbuilds der Bibliothek verknüpft sind (diese Bibliothek-Varianten mit der Endung ein hatte '). Diese Funktionen in den Anwendungen, die Sie schreiben und in die Klassen, die Sie entwerfen werden erheblich verbessern, die Common Language Runtime und kompilieren Zeit Fehlerbehandlung der Anwendung verwenden. Diese Funktionen sind unten aufgeführt, aber alle sind dokumentiert in der Class Library Reference manual.
Jedes von CObject in MFC abgeleitete Klasse implementiert eine Memberfunktion Dump , die Ihnen ermöglicht, den Zustand eines Objekts in einem ASCII-Format anzuzeigen. Diese Funktion kann von der Debugger aufgerufen oder in # ifdef _DEBUG /#endif Teile des Codes platziert werden. Eine Hilfsfunktion AfxDump ist nur für diesen Zweck in der Debugbibliothek enthalten. Es wird mit einem einzelnen Parameter, eine CObject * genannt. Sie können diese Funktion vom Debugger zum Ausdrucken des Arguments aufrufen. Sie sollten ein Dump Mitglied für Klassen bereitstellen, die Sie implementieren. Mit AssertValid, sollten Sie zunächst explizit Ihre Basisklasse Dump -Memberfunktion aufrufen. Die Ausgabe von Dump wird an die standard MFC CDumpContext, AfxDump, geleitet, die standardmäßig Ausgabefenster des Debuggers oder Ihre Debug terminal geht. Das Programm DBWIN können Sie auch die Ausgabe von AfxDumpanzuzeigen. Die Quelldatei MFC\SRC\DUMPINIT.CPP enthält Informationen zum AfxDump an ein anderes Ziel weiterleiten.
TRACE, ein Makro, das viel verhält sich wie Printf, nur Routen Ausgabe Standort AfxDump . TRACE -Anweisungen sollten Sie schwierige oder außergewöhnliche Orte im Code anzugeben. Als mit anderem Robustheit TRACE ist nur in der Debugbibliothek sinnvoll, und hat keine Auswirkungen in der Verkaufsversion. Die MFC-Bibliothek enthält eine Reihe von TRACE -Anweisungen für den Nachrichtenfluss nachverfolgen erbaut. Weitere Informationen zur Debug-Ablaufverfolgung finden Sie in technischer Hinweis 7.
ASSERT ist eine Laufzeitüberprüfung für die Gültigkeit einer Anweisung. ASSERTs sollten Sie großzügig im gesamten Programm verwenden. Jedem Ort haben Sie einen Kommentar ab:
/ / LpStr sollte an diesem Punkt NULL
sie sollten ersetzen, die mit einer laufzeit assert:
Assert(lpStr == null)
Der Compiler kann nicht verstehen, den Kommentar, aber es kann den Ausdruck in der Behauptung Makro auswerten. ASSERT -Anweisungen wirkungslos im Einzelhandel baut. Verwenden Sie die Informationen in der Verkaufsversion von ASSERT , dann das VERIFY -Makro.
MFC enthält auch eine umfangreiche Diagnose-Speicherreservierungsfunktion. Sie verwenden die Diagnose-Speicherreservierungsfunktion um zu überprüfen, ob Sie alle Speicherressourcen, während bestimmte Programmfunktionen freizugeben. Die diagnostische Zuordnung verfolgt die Quelldatei und Zeile Anzahl einer Zuweisung, also wenn Sie die CMemoryState::DumpAllObjectsSince API verwenden, können Sie alle Zuordnungen finden, die bleiben.
Standardmäßig wird MFC dump alle Objekte nicht befreit von Ihrem Programm (falls vorhanden) bevor das Programm beendet wird. Sie können diese Ausgabe anzeigen, indem Sie die Anwendung unter dem Debugger ausführen.
Windows 3.1 strikte Typüberprüfung
Strenge Typüberprüfung ist eine Option verfügbar, mit der WINDOWS.H-Headerdatei. MFC verwendet diese strengen Typen standardmäßig, und wenn Sie eine MFC-Anwendung erstellen, müssen Sie sie verwenden. MFC unterstützt nicht mehr die Erstellung einer Anwendung ohne den STRICT -Definitionen.
Typsichere Bindung und strenge
In C++ dürfen Sie viele Funktionen mit dem gleichen Namen haben, solange diese Funktionen unterschiedliche formalen Parameterlisten aufweisen. Um einzigartige Verbindung Symbole haben, wird der C++-Compiler "schmücken" diese Namen mit einem Algorithmus, der Informationen zu einer Funktion wie z. B. Name, Anzahl und Art der formalen Parameter, Aufrufkonvention, usw. codiert.
Diese neu generierte Name wird als externer Link Symbol für die Funktion verwendet. Dies ist bekannt als typsichere Bindung und ist ein großer Vorteil von C++. Diese Namensergänzung gilt nicht für Funktionen in einen Extern "C"-Block, und das ist, warum alle APIs in WINDOWS.H sind in einem solchen block.
Strenge Typüberprüfung in WINDOWS.H erhöht die Typsicherheit für Windows-Programme mithilfe von verschiedene Typen der verschiedenen HANDLES in Windows darstellen. So zum Beispiel verhindert STRICT ein HPEN irrtümlich an eine Routine erwartet ein HBITMAP übergeben.
Da die Windows-APIs in Extern "C" {} Blöcke sind, sind sie nicht in die oben beschriebene Art eingerichtet. STRICT ändern sich die Typen für die verschiedenen Windows-Typdefinitionen zu machen sie einzigartig (speziell verwendet verschiedene Zeigertypen zu behandelns, darstellen, die nicht frei ohne eine explizite Umwandlung konvertiert werden kann).
Wie Sie sehen können, haben Sie strenge Typüberprüfung aktiviert in einer Datei, aber nicht in einem anderen, generiert der C++-Compiler verschiedener externer Link Symbole für eine einzelne Funktion. Dadurch werden Link-Time-Fehler. Daher wird empfohlen, Sie strenge Typüberprüfung nur für Module der C (diejenigen, die am Ende verwenden in.C). Darüber hinaus STRICT ist eine Kompilierung nur option, also sobald Sie erfolgreich Ihren Code kompilieren, die Vorteile der STRICT vollständig realisiert werden.
Wenn Sie strenge mischen sind und nicht-STRICT -Code, Sie müssen der Verknüpfung Inkonsistenzen bewusst sein. Im Allgemeinen sollten alle MFC-Programmierung und alle C++ mit STRICTerfolgen. Wenn Sie ältere C-Code haben, ist dann nicht mit strengen akzeptabel.
Windows 3.1 WINDOWSX.H-Headerdatei
Neu mit Windows 3.1 und Win32 ist die WINDOWSX.H-Headerdatei, die verschiedene Erweiterungen zu den C-Code-Stil für Windows-Programmierer, die mit C. unterstützt Diese Makro APIs, Nachricht Cracker und Kontrolle APIs werden in der Datei WINDOWSX definiert.H.
Diese Syntax dient in erster Linie für C-Programmierer. MFC unterstützt die Verwendung von WINDOWSX.H, also wenn Sie vorhandenen Code haben, die auf diese Spannungen, verwenden diesen Code unverändert in MFC. Sie finden jedoch, dass MFC verfügt über vergleichbare Idiome für alle Funktionen von WINDOWSX.H, und verwendet die C++ Sprache diese Aufgaben mit mehr semantische und architektonischen Sicherheit.
WINDOWSX verwenden.H, achten Sie darauf, # es eingeschlossen werden, bevor Sie AFXWIN aufgenommen haben.H (oder STDAFX.H, wenn Sie die Struktur der Anwendungs-Assistent verwenden).
Der einzige Nachteil ist, dass es zwei WINDOWSX.H APIs, die kollidieren mit den MFC C++-APIs. Die zwei APIs SubclassWindow und CopyRgn sind nicht verfügbar für die Verwendung innerhalb von MFC. Sie benötigen recode können entweder nutzen die MFC-API (und Klassen) oder der Windows-API direkt aufrufen. Sie können auch eigene Makro code, solange es einen anderen Namen hat.
Technische Hinweise von &Nummer |nbsp; Technische Hinweise nach Kategorie