Cette note technique principalement fournit des lignes directrices pour la migration des applications MFC 1.0 aux outils 2.0 de MFC. Autres différences entre MFC 2.0, 2.5 et 3.0 sont présentés dans la première section, ci-dessous.
Changements d'API MFC 4.0/3.0
Il n'y a aucun changements connus pour les API MFC documentée que causerait le code existant exiger des changements. Il y a, bien sûr, vous pouvez profiter de nombreuses fonctionnalités. Pour plus d'informations sur ces fonctionnalités, consultez le Guide du programmeur Visual C++.
MFC 2,5 API change
MFC 2,5 a ajouté deux caractéristiques principales de la bibliothèque de classes : charge OLE 2.0, qui a remplacé le soutien OLE 1.0 et le support ODBC qui fournit l'accès de la base de données. C'est l'intention de cette technote pour couvrir les modifications de l'API qui peuvent affecter votre code existant. Pour plus d'informations sur ces nouvelles fonctionnalités, ne pas couverte dans cette technote, consultez Guide du programmeur Visual C++.
CFrameWnd::RecalcLayout a un paramètre supplémentaire, BOOL bNotify. Ce paramètre spécifie d'aviser tous les serveurs OLE ou non qu'ils mise en page a changé. Il est normalement vrai et qui est donc la valeur par défaut. Cette fonction est virtuelle, donc si votre programme fournit une substitution de cette fonction, vous devrez ajouter le paramètre supplémentaire à votre fonction, ainsi.
Il y a des autres modifications apportées à des fonctions non documentées dans les bibliothèques MFC 2,5 à l'appui de OLE 2.0 ainsi que ODBC. Si votre programme utilise les API non documentée de MFC, vous devriez examiner toutes ces utilisations pour s'assurer qu'ils sont toujours valables.
Migration MFC 1.0 Applications MFC 2.0
IMPORTANT : Pour comprendre et évaluer les deux approches présentées ci-dessous, vous devez être familier avec les concepts de MFC 2.0, tels que l'architecture de Document et d'affichage et les outils. Nous suggérons que vous travaillez au moins à travers l'exemple MFC tutoriel SCRIBBLE dans tutoriels avant de commencer toute migration de code existant.
Il existe deux approches de base pour la migration des applications existantes de MFC version 1, publiées avec Microsoft C7, aux MFC version 2.
Migration minimale
À l'aide de la méthode de la « Migration minimale », vous faire uniquement les modifications minimales requises, afin que:
C'est l'approche la plus facile, mais il ne tient pas pleinement parti des fonctionnalités riches dans la bibliothèque MFC 2.0. Même si vous avez choisi la méthode de la « Migration complète », vous devrez comprendre et exercer des techniques de migration minimale.
Migration complète
Si vous effectuez une « Migration complète », vous pouvez profiter pleinement de la bibliothèque MFC 2.0. À l'aide de la méthode de migration minimale, vous pourrez modifier votre application à l'aide de Visual C++ et ClassWizard. En utilisant la méthode de migration complète, vous obtenez le soutien MFC 2.0:
La méthode de migration globale complète est fondamentalement pour émuler le développement d'une application MFC 2.0 de zéro, à partir de AppWizard. La différence de développement d'une application MFC 2.0 de zéro, bien sûr, est que vous fera emprunter autant du code MFC 1.0 que vous avez écrit comme logique.
Migration minimale
Les sous-sections suivantes présentent des lignes directrices détaillées pour effectuer une migration minimale.
Conforme à Windows 3.1 stricte typedefs
La valeur par défaut s'inspire du MFC 2.0 Bibliothèque adhérer les typedefs de Windows 3.1 STRICT qui sont expliquées dans le SDK de Windows 3.1. MFC 1.0 avait STRICT est désactivé, mais maintenant MFC 2.0 a STRICT activée par défaut. Cette conclusion découle d'engagement de MFC pour suivre l'API Windows standard de l'industrie et de favoriser des pratiques de développement qui rendent le développement plus faciles des applications robustes. Tout comme les typedefs de stricts ont été utiles aux développeurs des classes MFC 2.0 afin de produire des logiciels robustes, ce qui sera vrai pour vous dans le développement de votre code d'application.
Lorsque vous utilisez le type STRICT vérifiant pour la première fois, beaucoup d'erreurs de compilation entraînera généralement. Modifier votre application MFC 1.0 pour se conformer à Windows 3.1 STRICT typedefs peut très bien représenter l'essentiel de vos efforts de migration minimale.
Une fois que votre demande est conforme aux stricts, vous peut-être capable de compiler un exécutable avec aucun autre changement. Par exemple, les échantillons ABOUT2 et FILEVIEW MFC 1.0 compiler avec aucune des modifications supplémentaires. Ils étaient déjà STRICT conforme et a n'utilisé pas changés MFC API.
MFC 2.0 API change
Au-delà se pliant aux stricts, la plus grande partie de l'effort de faire une migration minimale est d'identifier et de changer le code de votre application de se conformer aux changements MFC 2.0 API relativement peu.
De plus de 1800 MFC 1.0 API, seuls 20 des API qui ont été changé suite à des erreurs de compilation. Ces changements exigent seulement négligeables modifications aux applications existantes de MFC 1.0. Les changements plus importants sont la restructuration architecturale des classes OLE. Ces changements sont couvertes de Technical Note 18.
Pour prévoir que les changements que vous devrez faire, consultez la section « Modifications de l'alphabétique API » à la fin de cette technote. Il fournit un résumé utile, bref qui MFC 1.0 API ont été modifiés dans MFC 2.0.
Si vous ne faites pas toutes les modifications nécessaires pour traiter avec le code MFC 2.0, vous obtiendrez diverses de compilation et d'erreurs de liaison. Ces erreurs sont presque toujours faciles à diagnostiquer. Pour faciliter votre diagnostic, nous fournissons des lignes directrices dans la section « Erreurs du compilateur » à la fin de cette technote.
Les API de MFC suivantes ont été supprimées dans MFC 2.0. Nous vous recommandons d'API alternatif le cas échéant. Cette liste n'inclut pas les modifications apportées à la mise en œuvre sans papiers API.
CDC::GetDCOrg
GetDCOrg n'est pas disponible dans Win32. Pour les applications uniquement Windows 3.x, appelez simplement l'API Windows :: GetDCOrg directement.
CRuntimeClass::m_pszClassName
Cette variable membre est maintenant un LPSTR plutôt que le modèle de mémoire-dépendante (char **). Il est nommé m_lpszClassName dans MFC 2.0.
CMDIChildWnd::m_pMDIFrameWnd
Dans MFC 1.0, cette variable membre a souligné parent de la classe MDIFrame. Cette variable membre a été remplacée par une fonction de membre CMDIChildWnd::GetMDIFrame. Si vous utilisez multiple document interface (MDI) de MFC 2.0, la plupart utilise CMDIChildWnd::m_pMDIFrameWnd (ou GetMDIFrame) n'est plus nécessaires puisque la charge MDI par défaut gère toutes les commandes de menu MDI Windows standards.
CFrameWnd::GetChildFrame
Utilisez plutôt des CMDIFrameWnd::MDIGetActive pour les cadres MDI.
L'API suivante a été laissé dans MFC 2.0 pour soutenir 1 compatibilité mais est obsolète. Il sera enlevé des futures versions de MFC.
CMDIFrameWnd::CreateClient
Cette fonctionnalité a été remplacée par le mécanisme de OnCreateClient plus général qui prend en charge la création de la vue et la prise en charge MFC 2.0 MDI améliorée. L' original CreateClient peut encore être utilisé pour les applications MDI qui gèrent la barre de menu de la fenêtre de la trame de leurs propres MDI (en utilisant CMDIFrame::MDISetMenu). L'aide de MFC MDI de 2.0 fera passer automatiquement de la barre de menus de la fenêtre frame MDI au menu de la fenêtre d'enfant MDI actif.
Autres changements liés à l'API
Deux classes MFC ont été déplacés de la afxwin.h vers le fichier d'en-tête afxext.h:
Ajoutez vos fichiers .cpp qui font référence à ces classes suivantes:
# include lt;afxext.h>
Plusieurs API ont été modifiées afin qu'elles sont plus strictes sur l'utilisation du modificateur « const ». Ces changements résultent en une utilisation plus cohérente du nom du type LPCSTR et le nouveau nom de type LPCRECT. À noter, il n'y a aucune question de temps de compilation avec ces changements, puisque n'importe quel type peut être promu à une version const de ce type lorsqu'il est utilisé comme un argument. Comme le changement STRICT , cela nous amène à code plus robuste lorsque votre code utilise des pointeurs de données const.
Les fonctions de création de fenêtre ci-dessous maintenant ont un paramètre supplémentaire, mais étant donné que le dernier paramètre a une valeur par défaut NULL, le code existant fonctionnera sans modification. Ces fonctions sont
Les fonctions suivantes ont été virtuelles dans MFC 1.0 mais sont maintenant non virtuelles dans MFC 2.0:
Si une classe dérivée de votre application MFC 1.0 substitue ou l'autre de ces fonctions, il est peu probable que la fonction dans votre classe dérivée sera appelée dans MFC 2.0. En outre, GetParentFrame fut transférée de CFrameWnd de CWnd à être une API plus généralement utile.
Tous les membres statiques de classes, ainsi que des fonctions global operator/ami, adhèrent maintenant PASCAL conventions d'appel. Toutes les fonctions globales sont AFXAPI (PASCAL). Encore une fois, ce n'est pas une question de temps de compilation mais permet une plus rapide et plus petite généré le code.
Beaucoup de la mise en œuvre uniquement des classes et des structures ont été renommés de ne pas utiliser le préfixe « C ». Par exemple, CExceptionContext a été renommé en AFX_EXCEPTION_CONTEXT. Ces classes ne sont pas documentés et restent les détails d'implémentation de la bibliothèque de classes. Il est peu probable que vous avez s'est appuyé sur ces, et il est généralement recommandé que vous ne comptez pas sur une API non documentée de la bibliothèque de classe car ils sont susceptibles d'être modifiées dans les versions futures.
Changements de comportement par défaut MFC 2.0
Face aux changements de l'API MFC est facile avec l'aide des erreurs signalées par le compilateur et l'éditeur de liens. Pas tous les changements de la bibliothèque sont révèlent dans les fichiers d'en-tête, cependant. Certains changements sont révèlent dans le comportement d'exécution de votre application. Ces changements ne sont généralement pas difficiles à traiter, aussi longtemps que vous anticipez les. L'information suivante est fournie pour vous aider à anticiper ces changements de comportement.
CDialog et CModalDialog ont été fusionnées en une seule classe. CModalDialog est maintenant considéré comme une classe obsolète. Cependant, pour assurer la compatibilité MFC 1.0, toutes les références à CModalDialog sont encore valides grâce à une macro migration dans afxwin.h:
# define CModalDialog CDialog
Pour de nombreuses applications MFC 1.0, cette simple # define est suffisante. Cependant, il y a des cas où cette # define n'est pas suffisant.
Si vous mis en place une boîte de dialogue non modale et s'est fondé sur le comportement par défaut de « ne rien faire » pour OnOK et OnCancel, alors vous devez substituer ces et le comportement par défaut, car ils appellent maintenant EndDialog (pour le traitement de la boîte de dialogue modale).
CDialog::CreateIndirect crée toujours une boîte de dialogue non modale. Pour créer une boîte de dialogue modale utilisez CDialog::InitModalIndirect au lieu des enlevé CModalDialog::CreateIndirect API.
Boîte de dialogue boîte et message boîte couleurs d'arrière-plan peuvent maintenant être globalement définies à l'aide le CWinApp::SetDialogBkColor API. Le paramètre par défaut définit la couleur gris clair (pas COLOR_BTNFACE) pour produire des horizons gris. Vous pouvez spécifier d'autres couleurs.
Si SetDialogBkColor n'est pas appelée dans votre CWinApp-dérivée fonction InitInstance , fenêtre fond couleur (définie dans l'applet couleur de panneau de contrôle) est utilisé par défaut.
Dans MFC 1.0, si une DLL contenait un objet CWinApp , il était nécessaire de fournir une fonction DllMain qui comprenait un appel à AfxWinTerm. MFC 2.0 fournit cette fonction DllMain, par conséquent, tout code supplémentaire inclus dans le votre DllMain doit être migré vers fonction de la DLL CWinApp::ExitInstance membre.
CMDIChildWnd::Create utilise désormais correctement le paramètre dwStyle . Vous devez maintenant spécifier un style de fenêtre complète pour la fenêtre enfant MDI. Si vous spécifiez dwStyle = 0, vous aurez maintenant un échec ASSERT dans CMDIChildWnd::PreCreateWindow. Pour éviter cela, vous devez spécifier le style WS_CHILD | WS_VISIBLE | WS_OVERLAPPEDWINDOW d'être rétrocompatible avec MFC 1.0.
MFC 2.0 prend en charge les différents styles de création de fenêtres enfants MDI, donc vous pouvez supprimer certains les contrôles de la fenêtre frame, si désiré.
Classe CFrameWnd a un nouveau membre de données, BOOL CFrameWnd::m_bAutoMenuEnable. Elle est définie sur TRUE par défaut. Cela provoque des éléments de menu qui n'ont pas des gestionnaires ON_UPDATE_COMMAND_UI ou ON_COMMAND d'être automatiquement désactivée. Les éléments de menu qui ont des gestionnaires ON_COMMAND , mais aucun gestionnaires ON_UPDATE_COMMAND_UI , seront automatiquement activés.
Cela le rend facile à mettre en œuvre des commandes facultatives, fondées sur la sélection actuelle. Aussi, cela réduit considérablement la nécessité pour les applications d'écrire des gestionnaires ON_UPDATE_COMMAND_UI pour activer ou désactiver des éléments de menu. Par exemple, une application générée par AppWizard aura éditer couper/copier/coller désactivé jusqu'à ce que le programmeur implémente les gestionnaires d'événements pour eux.
Toutefois, si votre application MFC 1.0 n'est pas mis à jour pour utiliser ON_COMMAND et ON_UPDATE_COMMAND_UI gestionnaires, alors il doit clairement m_bAutoMenuEnable explicitement. Sinon, les menus que vous désactivez seront réactivées automatiquement.
Modifications des projets (Build)
Vous pouvez continuer à construire votre application MFC 1.0 à l'aide d'un makefile standard. De loin le moyen le plus simple de migrer votre projet est d'utiliser les installations du projet Visual C++ afin de maintenir votre depedencies et autres options de projet dans l'environnement de Visual C++.
Une erreur de lien commun est externes non résolus à COMDLG32.DLL et SHELL32.DLL API. N'oubliez pas de lien avec COMDLG32.LIB et SHELL32.OI !.
Vous pourrez améliorer build fois en plaçant # incluent lt;afxwin.h > dans un fichier d'en-tête précompilé. Par convention, les applications MFC 2.0 spécifient « stdafx.h » comme l'en-tête précompilé. Puis le module stdafx.cpp comprend stdafx.h. Cette technique est illustrée par le code créé par AppWizard et de nombreux échantillons MFC 2.0.
&Notenbsp ; Il est important que vous décrivez ni supprimer des macros _AFX_NO_XXX contenues dans le fichier stdafx.h. Voir l'article de la Base de connaissances « PRB : Problems Occur When Defining _AFX_NO_XXX. » Vous pouvez trouver des articles de la Base de connaissances sur le CD-ROM de MSDN Library ou à http://www.microsoft.com/kb/.
Visual C++ et ClassWizard compatibilité
Même pour les migrations minime, nous recommandons que vous suivez les étapes ci-dessous afin que vous pouvez utiliser Visual C++ et ClassWizard pour modifier votre code et les ressources d'application.
//{{AFX_MSG_MAP (lt ; nom de la classe >)
//}}AFX_MSG_MAP
lt ; nom de la classe > est le nom de votre classe contenant la carte message.
De même, ajoutez les lignes suivantes de deux commentaires à l'intérieur de la déclaration de la classe correspondante dans votre fichier .h:
//{{AFX_MSG (lt ; nom de la classe >)
//}}AFX_MSG
Pour obtenir un exemple de ces déclarations, regarder les mêmes lignes de commentaire dans toute application créée par AppWizard. Pour une explication de ce que signifient ces lignes de commentaire, voir MFC : en utilisant les fichiers Source MFC dans le Guide du programmeur Visual C++.
//{{AFX_VIRTUAL (lt ; nom de la classe >)
//}}AFX_VIRTUAL
Migration complète
Une migration complète de votre application existante de c ou MFC 1.0 2.0 MFC vous offre tous les avantages du MFC 2.0. Pour la plupart des applications, une migration complète n'est pas difficile et vaut bien l'effort.
Une migration réussie et complète d'une application MFC 2.0 requiert essentiellement la même compréhension du MFC 2.0 comme l'élaboration d'une nouvelle demande de partir de zéro. Vous devez se familiariser avec la bibliothèque de classes MFC 2.0, Visual C++ AppWizard et ClassWizard avant de commencer la migration complète. Vous devez comprendre ce que certaines parties de votre code d'application peuvent être enlevé en dérivant des fonctionnalités équivalentes ou améliorée les classes MFC 2.0. Non seulement à l'aide de l'implémentation de la bibliothèque rendra votre code source plus petits, mais il fera ces parties de votre application mieux intégré avec le reste du cadre MFC.
Par entièrement migrer votre application MFC 2.0, vous serez capable de dériver des fonctionnalités supplémentaires de MFC à relativement peu frais supplémentaires. Par exemple, si votre application n'avait pas une interface utilisateur de fenêtre fractionnée, mais l'un serait utile à vos utilisateurs, puis vous pourrez rapidement ajouter cette fonctionnalité, ayant déjà porté votre code à l'architecture document/vue MFC 2.0.
Bien qu'une migration complète vers MFC 2.0 peut exiger quelques efforts de jours pour les grandes applications, le processus lui-même est assez simple. Les étapes générales suivantes décrivent le processus de:
Faites-le avant de commencer n'importe quel code d'édition. De nombreux programmeurs ont tendance à s'entrelacent code du document à afficher le code. Bien que cela n'est donc pas forcément "mauvais", la séparation des fonctionnalités de document et d'affichage est une philosophie de conception que le cadre MFC approuve et appuie particulièrement bien. Même si le MFC 1.0 n'a pas de classes CDocument et CView , il a également approuvé séparation document/vue. Ainsi que toutes les futures versions de la bibliothèque.
Étudier les exemples MFC 2.0 qui utilisent les classes CDocument et CView , notamment l'exemple de didacticiel MFC SCRIBBLE. Ensuite analyser votre application pour déterminer quel est le document et ce qui est le point de vue. Déterminer si votre application possède plusieurs types de documents ou de vues.
Même si votre application ne prête pas à effacer la séparation document/vue, vous serez toujours capables de migrer vers MFC 2.0 entièrement et de profiter essentiellement complète du cadre. Vous pouvez « fake » document/vue de séparation en implémentant CDocument- et CView-dérivées des classes, mais votre document ou avis classe peut déléguer la plupart de ses travaux à l'autre classe. Ou, votre classe d'affichage peut-être s'appuyer sur votre classe CFrameWnd- ou CMDIChildWnd-dérivée de la classe pour mettre en œuvre la majeure partie de l'interface utilisateur de votre application. En résumé, vous avez une liberté presque totale sur la manière de séparer votre document, vue et classes de fenêtre frame.
Votre analyse doit également déterminer si votre application a besoin des classes d'affichage multiple et éventuellement plusieurs classes de documents. Même relativement simples applications ont parfois besoin de plus d'une classe d'affichage. Cependant, plusieurs points de vue, comme dans une fenêtre fractionnée, n'exigent nécessairement que vous avez plusieurs CView-classes dérivées. Par exemple, si chaque volet de la fenêtre fractionnée fournit la même interface utilisateur comme les autres volets de la fenêtre fractionnée, ils peuvent partager la même classe d'affichage. Dans ce cas, chaque volet est tout simplement un objet distinct de la même classe d'affichage. Vous aurez probablement envie de concevoir des classes d'affichage multiples, si votre application fournit des interfaces utilisateur très distincts dans des fenêtres différentes.
AppWizard permettra de créer un squelette d'application MFC 2.0 qui prend en charge diverses fonctionnalités de cadre que vous sélectionnez des options dans les boîtes de dialogue de AppWizard. Avant d'exécuter AppWizard pour créer votre application squelette, vous devez familiariser tout d'abord avec les options Qu'appwizard fournit.
Ensuite, prendre un peu de temps pour décider laquelle des options de AppWizard, vous devrez sélectionner. Ne tenter de le faire en quelques minutes la première fois que vous exécutez AppWizard. Par exemple, si votre application ne supporte pas déjà OLE, c'est une décision majeure que vous aurez envie de prendre en considération. Si vous avez n'a pas choisi l'option de OLE de AppWizard pour commencer avec, vous pourrez toujours modifier le code de votre application pour utiliser les fonctionnalités OLE MFC. Mais départ avec l'option OLE AppWizard pour commencer avec la volonté de gagner du temps vous.
Votre analyse doit déterminer si votre application est une interface monodocument (SDI) ou application d'interface (multidocument MDI) document multiples. Cette décision devrait être évidente si vous êtes familiarisé avec ces deux interfaces utilisateur distincts dans d'autres applications Windows. AppWizard créera applications MDI par défaut depuis l'interface utilisateur MDI est habituellement plus fonctionnel pour les utilisateurs car il permet de les ouvrir plus d'un document/fichier à la fois. Heureusement, avec l'architecture document/vue MFC 2.0, soutien MDI ne nécessite aucun codage supplémentaire de votre part.
Après avoir fait l'analyse qui précède, vous êtes maintenant prêt à exécuter AppWizard pour créer le code squelette pour votre application.
Après avoir analysé comment votre application sépare en documents, vues et fenêtres frames, vous devriez avoir une bonne idée Quels noms donner à leurs classes correspondantes et les modules. Vous pouvez assigner un nom assez générique, comme l'exemple de didacticiel CScribDoc et CScribView et scribdoc.cpp et scribvw.cpp. Toutefois, si votre application requiert plusieurs classes d'affichage, vous probablement voudrez donner la première classe vue AppWizard créée un nom plus spécialisé, tels que CDataEntryView et CReportView. Voir l'étape suivante pour plus d'informations sur la création de plusieurs classes de document et d'affichage.
Après avoir prévu les options supplémentaires de AppWizard vous voulez, comme SDI ou MDI, et OLE, vous devriez maintenant être capable de sélectionner les options de AppWizard et créer l'application squelette en quelques minutes.
Si votre analyse ci-dessus détermine que votre application doit avoir plusieurs avis, document ou classes de fenêtre frame, il est un bon moment pour créer le squelette code pour ces classes juste après l'exécution de AppWizard.
Vous pouvez créer le code squelette pour votre affichage supplémentaire, document et les classes de fenêtre frame en clonant ceux créés par AppWizard. Copiez les fichiers .cpp et .h, attribuer un nouveau nom de module pour le document ou la classe de seconde. Puis modifiez le code squelette en changeant les noms de classe. Une autre solution consiste à utiliser la fonctionnalité ajouter une classe de l'Assistant de classe pour créer une nouvelle classe automatiquement dans les fichiers que vous spécifiez à l'aide de noms que vous spécifiez. Vous serez déjà familier avec la capacité du ClassWizard pour créer de nouvelles catégories si vous avez suivi le tutoriel de dessin à main levée.
Dans les deux cas, dans votre CWinApp-dérivée la fonction InitInstance de la classe, vous devez enregistrer les objets de modèle de document supplémentaire pour toutes les associations que vous voulez faire entre vous multiples de document, de visualiser et de classes de fenêtre frame.
Il s'agit aussi d'un pas rapide. Vous pouvez reporter cette étape si vous n'êtes pas engagé à mettre en œuvre plusieurs des documents, des vues ou des classes de fenêtre frame dans votre application.
Cette étape représente la majeure partie de l'ouvrage dans la migration de votre application MFC 1.0 à 2.0 MFC. Vous devez faire cela progressivement. Migration relativement petits morceaux de votre application à la fois. Comme vous le faites, vous allez apprendre plus de détails sur ce que le cadre prévoit que des fonctionnalités vous permettra de jeter certains de votre code d'application MFC 1.0 ancienne.
Que vous migrez ces morceaux de code, gardez à l'esprit les lignes directrices présentées dans le cadre de « Migration minimale ». Beaucoup de ces lignes directrices s'appliquent à la migration complète. AppWizard sera ont déjà ajouté les commentaires //{{AFX_MSG et //{{AFX_MSG_MAP pour les classes de cible de votre commande (application, document, vue et fenêtre frame). Il n'est pas nécessaire pour vous ajouter manuellement ces comme dans le cadre de l'approche de migration minimale. Bien qu'il n'est pas obligatoire, nous recommandons que vous déplacez des fonctions de gestion de message entre les commentaires de //{{AFX_MSG imbriquées dans les cartes de message. Aussi, déplacer les déclarations de ces fonctions (afx_msg) de traitement de message entre les commentaires //{{AFX_MSG dans vos fichiers d'en-tête. Ce faisant vous permettra d'utiliser ClassWizard dans le reste de life cycle(s) votre projet.
Ces recommandations concernant les commentaires //{{AFX_MSG sont également applicables, peut-être à un moindre degré, aux boîtes de dialogue. Si vous n'anticipez les changements à venir nombreux à une classe donnée de dialogue, puis il ne pourrait pas vaut votre effort pour rendre cette boîte de dialogue ClassWizard-conscient. C'est bien. Bien sûr, nous recommandons que vous créez toutes les classes de boîte de dialogue nouvelle aide de l'option Ajouter une classe de ClassWizard.
Que vous migrez une application MFC 1.0 ou Windows, vous pouvez conserver la compatibilité avec les formats de fichiers existants. (Le mécanisme de sérialisation par défaut MFC 2.0 document peut-être pas approprié pour votre application.) Ordonner CFile écrire et lire des appels, ou pour mettre en œuvre un fichier non base de document, vous souhaiterez substituer à CDocument::OnOpenDocument et OnSaveDocument. L'exemple MFC général DIBLOOK fournit un exemple de cette technique. Si votre application actuelle déjà sérialise des objets, alors ce ne sera pas un problème.
Modifications de l'API alphabétiques
Pour comprendre les raisons de ces modifications, veuillez consulter « Raison de changements » ci-dessous.
| API / Variable | MFC 2.0 changer (motif de changement) |
| CMetaFileDC::Close | Type de retour (2) |
| CWnd::Create | Param par défaut supplémentaire ajouté, CWnd * const (1, 3) |
| CFrameWnd::Create | Param par défaut supplémentaire ajouté, CWnd * const (1, 3) |
| CMDIChildWnd::Create | Param par défaut supplémentaire ajouté, CWnd * const (1, 3) nbsp ; dwStyle par défaut est maintenant : WS_CHILD | WS_VISIBLE | WS_OVERLAPPEDWI&NDOW |
| CWnd::CreateEx | Param par défaut supplémentaire ajouté, CWnd * const (1, 3) |
| CBitmap::CreateBitmap | Types de paramètres (4) |
| CDC::EnumObjects | Prototype de rappel (2) |
| CTime::Format | Fonction const (3) |
| CTimeSpan::Format | Fonction const (3) |
| CTime::FormatGmt | Fonction const (3) |
| CFile::GetStatus | Nonvirtual (5) |
| CDC::GrayString | Type de prototype et le paramètre de rappel (2) |
| CBitmapButton::LoadBitmaps | Paramètre par défaut supplémentaires (1) |
| CWnd::OnActivateApp | Type de paramètre (2) |
| CWnd::OnCompareItem | Paramètre supplémentaire (6) |
| CWnd::OnDeleteItem | Paramètre supplémentaire (6) |
| CWnd::OnDrawItem | Paramètre supplémentaire (6) |
| CWnd::OnDropFiles | Type de paramètre (2) |
| CWnd::OnGetMinMaxInfo | Type de paramètre (6) |
| CWnd::OnMeasureItem | Paramètre supplémentaire (6) |
| CWnd::OnMenuChar | Type de retour (2) |
| CWnd::OnNcCalcSize | Paramètre supplémentaire (6) |
| CWnd::OnPaintClipboard | Type de paramètre (2) |
| CWnd::OnParentNotify | Type de paramètre (2) |
| CWnd::OnSizeClipboard | Type de paramètre (2) |
| CWnd::OnSysCommand | Type de paramètre (2) |
| CWnd::OnWinIniChange | Type de paramètre (2) |
| CDC::PlayMetaFile | Type de paramètre (2) |
| CEdit::SetSel | Paramètre par défaut supplémentaires (6) |
| CEdit::SetTabStops | Type de paramètre (5) |
| CWnd::SetTimer | Type de prototype et le paramètre de rappel (2) |
| CRuntimeClass::m_pszClassName | Rebaptisée m_lpszClassName (5) |
| API supprimée ou obsolète | MFC 2.0 changer (motif de changement) |
| CBitmapButton | Ctor enlevé avec 3 params - utiliser le LoadBitmaps (1) |
| CMDIFrameWnd:: CreateClient | Utilisation OnCreateClient (1) |
| GetChildFrame | Utilisez MDIGetActive (1) |
| GetDCOrg | Utiliser les API Windows directement pour 3.x (4) |
| m_pMDIFrameWnd | Maintenant appeler GetParentFrame ou GetMDIFrame (1) |
Raisons pour les changements:
Erreurs du compilateur
La plupart des changements aux MFC 2.0 API générera un des quelques erreurs de compilateur ou aucun tout si les conversions de type standard satisfont le compilateur. Les erreurs de compilateur suivantes peuvent être générées lors de la compilation des applications MFC 1.0 existantes sous MFC 2.0:
| Nombre | Message d'erreur du compilateur |
| Erreur du compilateur C2039 | « Identificateur »: n'est pas un membre de la « classe-clé. » |
| Cette erreur est dû à une fonction membre ou membre de données a été supprimée d'une classe, par exemple de CFrameWnd m_pMDIFrameWnd. | |
| Erreur du compilateur C2501 | « Identificateur »: manquantes à spécificateurs de decl. |
| Cette erreur est provoquée lorsque vous utilisez un nom de classe inconnue. C'est généralement le cas lorsque la classe n'existe ou a été déplacée vers un fichier d'en-tête différent. Pour exemple, si vous obtenez cette erreur pour CMetaFile et CBitmapButton puis vous devez ajouter # include "afxext.h" pour les fichiers source à l'aide de ces classes. | |
| Erreur du compilateur C2248 | « Membre » ne peut pas accéder au membre « spécificateur » déclarée dans la classe « classe ». |
| Cette erreur se produit si l'accès d'un membre a changé de MFC 1.0 à 2. Par exemple, une API non documentée a été déplacée du public à l'accès des membres protégés . Cela ne devrait avoir lieu dans le code qui utilise l'API non documenté et non pris en charge, qui doit être modifié pour utiliser la fonctionnalité MFC 2.0 appropriée. | |
| Erreur du compilateur C2642 | Cast de pointeur vers membre doit être membre de pointeur connexe. |
| Cette erreur se produit lorsque le prototype de fonction du gestionnaire d'événements message diffère de celle dans afxwin.h. Par exemple, une ligne contenant la macro ON_WM_ACTIVATEAPP va émettre cette erreur si les paramètres et le type de retour de votre gestionnaire de messages de OnActivateApp correspond à la déclaration de MFC 1.0. | |
| Erreur du compilateur C2660 | « Fonction »: fonction ne prend pas de paramètres de « nombre ». |
| Le nombre de paramètres a changé de MFC 1.0 2.0 MFC. Par exemple, l'appel du constructeur de CBitmapButton avec trois paramètres provoque cette erreur car ce constructeur particulier a été supprimé et remplacé par la fonction membre LoadBitmaps. | |
| Erreur du compilateur C2664 | « Fonction »: Impossible de convertir le paramètre 'nombre' entre « type1 » et « type2 ». |
| Le type d'un paramètre a changé, et les conversions standards ne satisfont pas le compilateur. CDC::EnumObjects est un exemple de cela. Dans ce cas, le prototype de la fonction de rappel a changé. |
&Notes techniques par le numéro |nbsp ; Notes techniques par catégorie