&Notenbsp ; Cette Note technique a été écrit pour Windows 3.1. Windows NT implémente la plupart de ces fonctionnalités. Lorsque vous exécutez votre application sous Windows 3.1 (avec les DLL Win32s), ces techniques peuvent aider au débogage. Windows 95 a aussi implémente et étend les fonctionnalités de robustesse, mises en place au cours de Windows 3.1. Exécute la version de débogage de Windows 95 est la meilleure façon d'assurer votre application s'exécute proprement.
Windows 3.1 est une amélioration majeure de Windows 3.0 dans le domaine du développement d'applications robustes. Windows 3.1 comprend un certain nombre de nouvelles fonctionnalités qui améliorent la fiabilité d'une application Windows. Cette note technique décrit l'utilisation de ces fonctionnalités au sein de la bibliothèque MFC.
Ces fonctionnalités incluent le noyau debug, vérification de type STRICT , diagnostic et gestion de la mémoire et la WINDOWSX.Améliorations H.
Noyau de débogage de Windows 3.1
&Notenbsp ; Cette section s'applique uniquement à Microsoft Visual C++ version 1.5.
Tester votre application MFC avec les exécutables système de débogage est probablement la meilleure chose que vous pouvez faire pour vous assurer que vos applications sont robustes et fiables. Les versions de débogage des exécutables du système effectuer toutes sortes d'erreur utile pour vous, vous informant de tous les problèmes qui se posent avec les messages de sortie de débogage.
La meilleure façon d'utiliser le système de débogage est avec deux machines : une machine de test et de débogage qui a le système de débogage installé et une machine pour le développement. Une machine, votre machine d'essai, doit toujours s'exécuter avec le noyau de débogage. L'autre ordinateur, votre ordinateur de développement, doit s'exécuter avec le noyau non-debug. La sortie de débogage de noyau peut être envoyée à la machine principale via une ligne modem null. Si vous avez seulement une seule machine, puis vous devez être sûr exécuter le noyau de débogage (il y a une dégradation des performances légèrement). La sortie de débogage de noyau peut être acheminée vers DBWIN, un outil inclus dans le Microsoft Visual C++ version 1.5. En outre, la fenêtre Visual C++ sortie recevra sortie lors de l'exécution sous le débogueur.
Une astuce utile pour le débogage de la machine simple est de placer des copies des fichiers binaires système et debug et symboles dans un répertoire distinct et d'avoir des fichiers batch qui copie les fichiers appropriés dans votre répertoire système Windows. De cette façon, vous pouvez quitter Windows et changer rapidement de va-et-vient entre debug et non-debug. Le programme d'installation de Visual C++ version 1.5 cela mettra en place, puis vous pouvez basculer entre debug et non-debug version de Windows avec l'I1n.CHAUVE-souris et N2D.CHAUVE-souris des fichiers batch.
Si vous n'êtes pas en cours d'exécution avec un débogueur ou d'un terminal de débogage, vous devez exécuter l'application DBWIN afin que vous pouvez voir les messages d'erreur et d'avertissement produites par le système de débogage. Cette application est incluse avec Visual C++ version 1.5.
Voici quelques erreurs de programmation communs qui apparaissent fréquemment dans les applications Windows expédiées. Nombre de ces problèmes peuvent causer système aléatoire UAEs et autres problèmes sous Windows 3.0. Les fichiers binaires système de débogage vous aidera à repérer les problèmes, tels que:
Diagnostics MFC
En outre, de navires avec un ensemble de caractéristiques de robustesse qui sont compilés et liés uniquement dans la version Debug de la bibliothèque Microsoft Foundation Classes (ces variantes de bibliothèque se terminant par un a '). Utilisation de ces fonctionnalités dans les applications que vous écrivez et dans les classes de que conception permettra d'améliorer grandement le runtime et l'interception des erreurs de temps compilation de votre application. Ces fonctions sont décrites ci-dessous, mais tous sont documentés dans le Manuel de Référence de bibliothèque de classe.
Chaque classe dérivée de CObject dans MFC implémente une fonction membre Dump , qui vous permet de visualiser l'état d'un objet dans un format ASCII. Cette fonction peut être appelée à partir du débogueur ou placée à l'intérieur # ifdef _DEBUG /#endif portions de votre code. Une fonction d'assistance AfxDump est incluse dans la bibliothèque de débogage juste à cette fin. Elle est appelée avec un paramètre unique, un CObject *. Vous pouvez appeler cette fonction dans le débogueur pour imprimer l'argument. Vous devez fournir un membre Dump pour les classes que vous implémentez. Comme avec AssertValid, vous devez tout d'abord explicitement appeler votre classe de base Dump de fonction membre. La sortie de Dump est acheminée vers le standard MFC CDumpContext, afxDump, qui, par défaut, va à la fenêtre sortie du débogueur ou à votre terminal de débogage. Vous pouvez également utiliser le programme DBWIN pour afficher la sortie de afxDump. Le fichier source MFC\SRC\DUMPINIT.RPC comprend des informations sur la façon de router afxDump vers une autre destination.
TRACE, une macro qui se comporte beaucoup comme printf, seulement les routes sortie à l'emplacement afxDump . Vous devez utiliser les instructions TRACE pour indiquer des endroits difficiles ou exceptionnelles dans votre code. Comme avec d'autres caractéristiques de robustesse, TRACE n'est valable que dans la bibliothèque de débogage et n'a aucun effet dans la build de la vente au détail. La bibliothèque MFC inclut un certain nombre de construit dans des instructions de traçage pour suivre le flux de messages. Consultez Technical Note 7 pour plus d'informations sur les traces de debug.
ASSERT est une vérification de l'exécution pour la validité d'une déclaration. Vous devez utiliser ASSERTs libéralement tout au long de votre programme. N'importe quel endroit vous avez un commentaire à l'effet:
/ / lpStr doit être NULL à ce stade
vous devez remplacer que par un assert run-time:
Assert(lpStr == null)
Le compilateur ne peut pas comprendre le commentaire, mais il est possible d'évaluer l'expression dans la macro de l'assertion. Instructions ASSERT n'ont aucun effet dans les builds imperfection. Si vous avez besoin de l'information de ASSERT dans la build de la vente au détail, puis utilisez la macro VERIFY.
MFC inclut également un allocateur de mémoire de diagnostic approfondie. Vous utilisez l'allocateur de mémoire de diagnostic pour vérifier que vous libérer toutes les ressources de la mémoire au cours de certaines fonctions du programme. L'allocateur de diagnostic va suivre le fichier source et la ligne numéro d'une allocation, donc si vous utilisez le CMemoryState::DumpAllObjectsSince API, vous pouvez localiser des allocations qui restent.
Par défaut, MFC se débarrasse de tous les objets ne pas libérés par votre programme (s'il en est) avant que votre programme. Vous pouvez afficher cette sortie en exécutant votre application sous le débogueur.
Vérification de Type STRICT de Windows 3.1
Vérification de type STRICT est une option disponible avec WINDOWS.Fichier d'en-tête de H. MFC utilise ces types STRICT par défaut et vous devez les utiliser si vous construisez une application MFC. MFC ne supporte création d'une application sans les définitions STRICT.
Liaison de type sécurisé et stricte
En C++ vous n'êtes autorisé à avoir plusieurs fonctions avec le même nom, tant que ces fonctions ont des listes de paramètres formels différents. Afin d'avoir des symboles de lien unique, le compilateur C++ sera « ornent » ces noms à l'aide d'un algorithme qui encode les informations sur une fonction telle que le nom, le nombre et le type de paramètres formels, appeler convention, etc.
Ce nouveau nom est utilisé comme le symbole du lien externe pour la fonction. Ceci est connu comme la liaison de type sécurisé et est un grand avantage du C++. La décoration de ce nom ne s'applique pas à des fonctions au sein d'un bloc d'extern « C », et c'est pourquoi toutes les API de WINDOWS.H sont dans un tel bloc.
Type STRICT contrôle dans WINDOWS.H améliore la sécurité de type pour les programmes de Windows à l'aide de types distincts de représenter tous les HANDLES différents dans Windows. Ainsi, par exemple, STRICT vous empêche de passer par erreur une HPEN à une routine attend un HBITMAP.
Comme les API Windows sont tous dans des blocs de {} extern « C », elles ne sont pas décorées de la façon décrite ci-dessus. STRICT modifie les types des divers typedefs de Windows pour les rendre uniques (spécifiquement utilise les types pointeur différents pour représenter les gérers, qui ne peuvent pas être librement converties sans un cast explicite).
Comme vous pouvez le voir, si vous avez de vérification de type STRICT activée dans un seul fichier, mais pas dans l'autre, le compilateur C++ va générer des symboles différents lien externe pour une seule fonction. Ceci entraînera des erreurs de lien-temps. Par conséquent, il est recommandé d'utiliser le type STRICT vérifiant uniquement pour les modules C (ceux qui se terminent par.C). en outre, de STRICT est une compilation option seulement, donc une fois que vous compilez avec succès votre code, complètement comprendre les avantages du STRICT.
Si vous sont mélange STRICT et non-codeSTRICT , vous devez être conscient des incohérences de liens. En général, tous les programmes MFC et C++ tous devraient être fait avec le STRICT. Si vous avez hérité code C, puis en utilisant ne pas STRICT n'est acceptable.
Windows 3.1 WINDOWSX.Fichier d'en-tête de h
Nouveau avec Windows 3.1 et Win32 est la WINDOWSX.Fichier d'en-tête h qui prend en charge diverses extensions pour le style de codage c pour les développeurs Windows à l'aide de c. Ces macros API, craquelins de message et le contrôle API sont définis dans le fichier WINDOWSX.H.
Cette syntaxe est principalement conçue pour les programmeurs C. MFC prend en charge l'utilisation de WINDOWSX.H, donc si vous avez un code existant qui s'appuie sur ces tensions, utilisez ce code non modifiée dans MFC. Vous trouverez, cependant, que le MFC a des idiomes comparables pour toutes les fonctionnalités de WINDOWSX.H et utilise le C++ language pour accomplir ces tâches avec plus de sécurité sémantique et architecture.
Pour utiliser WINDOWSX.H, veillez à # inclure avant que vous avez inclus AFXWIN.H (ou STDAFX.H si vous utilisez la structure AppWizard).
La seule réserve est qu'il y a deux WINDOWSX.H API qui entrent en collision avec les MFC C++ API. Les deux API SubclassWindow et CopyRgn ne sont pas disponibles pour une utilisation dans les MFC. Vous aurez besoin de recoder ces d'utiliser soit l'API MFC (et classes) ou d'appeler l'API Windows directement. Vous pouvez également code votre propre macro tant qu'elle a un nom différent.
&Notes techniques par le numéro |nbsp ; Notes techniques par catégorie