Esta nota técnica principalmente proporciona directrices para migrar aplicaciones MFC 1.0 a las herramientas 2.0 de MFC. A continuación se presentan en la primera sección, más diferencias entre MFC 2.0, 2.5 y 3.0.
MFC 4.0/3.0 API cambia
No hay conocidos cambios a las APIs de MFC documentadas que causaría el código existente para exigir cambios. Por supuesto, hay muchas características adicionales que puede que desee aprovechar. Para obtener más información sobre estas funciones, consulte la Guía del programador de Visual C++.
API de MFC 2.5 cambia
MFC 2.5 añade dos características principales a la biblioteca de clases: soporte OLE 2.0, que sustituyó el OLE 1.0 apoyo y soporte ODBC que proporciona acceso de base de datos. Es la intención de esta nota técnica para cubrir los cambios de API que pueden afectar el código existente. Para obtener información acerca de estas nuevas características, no cubierto en esta nota técnica, consulte la Guía del programador de Visual C++.
CFrameWnd::RecalcLayout tiene un parámetro adicional, BOOL bNotify. Notificar cualquier servidores OLE o no especifica que se ha cambiado el diseño. Es cierto normalmente y por lo tanto, es el valor predeterminado. Esta función es virtual, así que si tu programa proporciona un reemplazo de esta función necesita añadir el parámetro adicional a su función como.
Hubo otros cambios realizados en funciones indocumentadas en las bibliotecas MFC 2.5 para apoyar OLE 2.0, así como ODBC. Si el programa utiliza APIs de MFC indocumentados, debe revisar todos esos usos para asegurarse de que siguen siendo válidos.
MFC migración 1.0 aplicaciones MFC 2.0
IMPORTANTE: Para comprender y evaluar los dos enfoques que se presentan a continuación, debe estar familiarizado con los conceptos de MFC 2.0, tales como la arquitectura de documento y la vista y las herramientas. Le sugerimos que trabaje por lo menos a través de la muestra de MFC Tutorial a mano alzada en tutoriales antes de comenzar cualquier migración de código existente.
Existen dos enfoques básicos a migrar las aplicaciones existentes de MFC versión 1, lanzados con Microsoft C7, a MFC versión 2.
Migración mínima
Utilizando el método de "Migración mínima", que sólo los cambios mínimos necesarios, por lo que:
Este es el enfoque más fácil, pero no aprovechar plenamente las características completas en la biblioteca MFC 2.0. Incluso si elige el método de "Migración completa", necesita comprender y ejercitar técnicas para migración mínima.
Migración completa
Si realiza una "migración completa", puede tomar ventaja de la biblioteca MFC 2.0. Utilizando el método de migración mínima, podrá editar su aplicación utilizando Visual C++ y ClassWizard. Mediante el método de migración completa, obtendrá el siguiente apoyo MFC 2.0:
El método de migración global completa es básicamente emular el desarrollo de una aplicación MFC 2.0 desde cero, comenzando con AppWizard. La diferencia con el desarrollo de una aplicación MFC 2.0 desde cero, por supuesto, es que será prestado tanto el código de MFC 1.0 que escribió como sentido.
Migración mínima
Las siguientes subsecciones presentan directrices detalladas para realizar una migración mínima.
Conforme al estricto de Windows 3.1 typedefs
El valor predeterminado se construye de la 2.0 de MFC biblioteca se adhieren a los typedefs Windows 3.1 estricta que se explican en el SDK de Windows 3.1. MFC 1.0 tenía estricto desactivado, pero ahora MFC 2.0 tiene estricto activado por defecto. Esto sigue el compromiso de MFC y realizar un seguimiento de la API de Windows estándar de la industria para fomentar prácticas de desarrollo que hacen desarrollar sólidas aplicaciones más fácil. Así como las estricta typedefs fueron útiles para los desarrolladores de las clases MFC 2.0 para producir software robusto, así será cierto para usted en el desarrollo de código de la aplicación.
Cuando se utiliza el tipo de estricta comprobación por primera vez, normalmente se producirán muchos errores de compilación. Modificar la aplicación MFC 1.0 para ajustarse a Windows 3.1 estricta typedefs muy bien puede representar la mayor parte de su esfuerzo de migración mínima.
Una vez que la aplicación cumpla con estricta, puede ser capaz de compilar un ejecutable sin cambios adicionales. Por ejemplo, las muestras de ABOUT2 y FILEVIEW MFC 1.0 compilan sin cambios adicionales. Ya estaban estricta conforme y hizo no utiliza ninguna cambiado APIs de MFC.
MFC 2.0 API cambia
Más allá de conforme al estricto, la mayor parte del esfuerzo de hacer una migración mínima es identificar y cambiar el código de aplicación se ajusten a los relativamente pocos cambios de MFC 2.0 API.
De más de 1800 MFC 1.0 APIs, sólo 20 de las API que fueron cambiado resultado errores en tiempo de compilación. Estos cambios requieren sólo triviales modificaciones en las aplicaciones MFC 1.0 existentes. Los cambios más extensos son la reestructuración arquitectónica de las clases OLE. Estos cambios están cubiertos en 18 de nota técnica.
Para anticipar que los cambios que necesita hacer, consulte la sección "Cambios de API alfabético" al final de esta nota técnica. Proporciona un resumen útil y breve que se modificaron MFC 2.0 API 1.0 de MFC.
Si no hacer todos los cambios necesarios para lidiar con el código 2.0 de MFC, obtendrá varios compilación y errores de enlace. Estos errores son casi siempre fáciles de diagnosticar. Para ayudar a su diagnóstico, ofrecemos algunas directrices en la sección "Errores de compilador" al final de esta nota técnica.
Se han eliminado las siguientes API de MFC en MFC 2.0. Recomendamos API alternativas cuando proceda. Esta lista no incluya cambios a indocumentados aplicación API.
CDC::GetDCOrg
GetDCOrg no está disponible en Win32. Para aplicaciones sólo para Windows 3.x, acaba de llamar a la API de Windows :: GetDCOrg directamente.
CRuntimeClass::m_pszClassName
Esta variable miembro es ahora un LPSTR en lugar de utilizar el modelo de memoria-dependiente (char **). Se denomina m_lpszClassName en MFC 2.0.
CMDIChildWnd::m_pMDIFrameWnd
En MFC 1.0, esta variable miembro señaló padre de MDIFrame de la clase. Esta variable de miembro ha sido sustituida por una función de miembro CMDIChildWnd::GetMDIFrame. Si está utilizando la interfaz de múltiples documentos (MDI) en MFC 2.0, la mayoría utiliza CMDIChildWnd::m_pMDIFrameWnd (o GetMDIFrame) ya no es necesaria ya que el apoyo MDI predeterminado controla todos los comandos de menú estándar de ventanas MDI.
CFrameWnd::GetChildFrame
Utilice en su lugar CMDIFrameWnd::MDIGetActive para marcos de MDI.
La siguiente API ha quedado en MFC 2.0 para soportar 1 compatibilidad pero está obsoleta. Se quitará en versiones futuras de MFC.
CMDIFrameWnd::CreateClient
Esta funcionalidad se ha reemplazado por el mecanismo de OnCreateClient más general que admite la creación de la vista y el soporte mejorado de MFC 2.0 MDI. El original CreateClient todavía puede utilizarse para aplicaciones MDI que administran la barra de menús de la propia ventana de marco MDI (mediante CMDIFrame::MDISetMenu). El apoyo de MFC 2.0 MDI cambiará automáticamente la barra de menús de la ventana de marco MDI al menú de la ventana de secundario MDI activo.
Otros cambios relacionados con la API
Dos clases MFC se han movido desde el afxwin.h en el archivo de encabezado afxext.h:
En los archivos .cpp que hacen referencia a estas clases agregar lo siguiente:
# include lt;afxext.h>
Han cambiado muchas APIs para que sean más estrictas sobre el uso del modificador 'const'. Estos cambios como resultado de un uso más consistente del nombre de tipo LPCSTR y el nuevo nombre de tipo LPCRECT. Tenga en cuenta que no hay ningún problema de tiempo de compilación con estos cambios, ya que cualquier tipo puede promoverse una versión const de ese tipo cuando se utiliza como argumento. Como el cambio de estricta , esto conduce a código más sólido cuando el código utiliza punteros de datos const.
Las ventana crear las funciones enumeradas a continuación ahora tienen un parámetro adicional, pero dado que el último parámetro tiene un valor predeterminado de NULL, vigente Código funcionará sin modificación. Estas funciones son
Las siguientes funciones virtuales en MFC 1.0 pero ahora son no virtual en MFC 2.0:
Si una clase derivada de la aplicación MFC 1.0 reemplaza cualquiera de estas funciones, es improbable que se llamará a la función en la clase derivada en MFC 2.0. Además, GetParentFrame fue trasladada desde CFrameWnd a CWnd para ser una API más generalmente útil.
Todos los miembros estáticos de las clases, así como funciones de operador global/amigo, ahora se adhieren a PASCAL convenciones de llamada. Todas las funciones globales son AFXAPI (PASCAL). Nuevamente, esto no es una cuestión de tiempo de compilación, pero conduce al código generado más pequeños y más rápido.
Muchas de las estructuras y clases sólo aplicación han renombrado a no usar el prefijo 'C'. Por ejemplo, CExceptionContext ha cambiado el nombre a AFX_EXCEPTION_CONTEXT. Estas clases no están documentadas y quedan detalles de implementación de la biblioteca de clases. Es improbable que han dependido de estos, y generalmente se recomienda que no confían en las APIs de indocumentados de la biblioteca de clases pues están sujetos a cambios en futuras versiones.
Cambios de comportamiento predeterminado MFC 2.0
Tratar con los cambios de la API de MFC es fácil con la ayuda de errores reportados por el compilador y el vinculador. No todos los cambios de la biblioteca son revelados en los archivos de encabezado de la biblioteca, sin embargo. Algunos cambios son revelados en el comportamiento en tiempo de ejecución de la aplicación. Estos cambios generalmente no son difíciles de tratar, como usted preverlas. La siguiente información se proporciona para ayudarle a anticipar esos cambios conductuales.
CDialog y CModalDialog se han fusionado en una sola clase. CModalDialog ahora se considera que una clase obsoleta. Sin embargo, para la compatibilidad de MFC 1.0, todas las referencias a CModalDialog siguen siendo válidas a través de una macro de migración en afxwin.h:
# define CModalDialog CDialog
Para muchas aplicaciones MFC 1.0, definir este # simple es suficiente. Sin embargo, hay casos donde definir este número no es suficiente.
Si implementa un cuadro de diálogo no modal y confiado en el comportamiento predeterminado de "hacer nada" para OnOK y OnCancel, entonces debe reemplazar estos y el comportamiento predeterminado, ya que ahora llaman EndDialog (para el procesamiento de diálogo modal).
CDialog::CreateIndirect todavía crea un cuadro de diálogo no modal. Para crear un cuadro de diálogo modal utilice CDialog:: InitModalIndirect en lugar de los eliminados CModalDialog::CreateIndirect API.
Ahora se pueden definir colores de fondo cuadro mensaje y el cuadro de diálogo a nivel mundial mediante la CWinApp::SetDialogBkColor API. El parámetro predeterminado establece el color gris claro (no COLOR_BTNFACE) para producir fondos gris. Se pueden especificar otros colores.
Si no se llama a SetDialogBkColor en tu CWinApp-derivados de la función InitInstance , fondo de ventana color (definido en el applet de Color del Panel de Control) se utiliza por defecto.
En MFC 1.0, si un archivo DLL contiene un objeto CWinApp , era necesario proporcionar una función DllMain que incluía una llamada a AfxWinTerm. MFC 2.0 proporciona esta función DllMain, así que cualquier código adicional incluido en la la función DllMain debe migrarse a función de miembro de CWinApp::ExitInstance de la DLL.
CMDIChildWnd::Create utiliza correctamente el parámetro dwStyle . Ahora debe especificar un estilo de ventana completa para la ventana secundaria MDI. Si se especifica dwStyle = 0, ahora obtendrá un error de ASERCIÓN en CMDIChildWnd::PreCreateWindow. Para evitar esto, se debe especificar el estilo WS_CHILD | WS_VISIBLE | WS_OVERLAPPEDWINDOW para ser compatible con MFC 1.0.
MFC 2.0 admite definir diferentes estilos de ventanas secundarias MDI, así que puede eliminar algunos de los controles de ventana de marco, si lo desea.
Clase CFrameWnd tiene un nuevo miembro de datos, BOOL CFrameWnd::m_bAutoMenuEnable. Se establece en TRUE de manera predeterminada. Esto hace que los elementos de menú que no tienen controladores de ON_UPDATE_COMMAND_UI o ON_COMMAND para desactivarse automáticamente. Se activará automáticamente los elementos de menú que tienen controladores de ON_COMMAND , pero no los controladores de ON_UPDATE_COMMAND_UI ,.
Esto facilita aplicar comandos opcionales en función de la selección actual. También, esto reduce considerablemente la necesidad de las aplicaciones escribir controladores de ON_UPDATE_COMMAND_UI para habilitar o deshabilitar elementos de menú. Por ejemplo, una aplicación generada AppWizard tendrá editar cortar/copiar/pegar desactivada hasta que el programador implementa controladores para ellos.
Sin embargo, si no se actualiza la aplicación MFC 1.0 para utilizar ON_COMMAND y ON_UPDATE_COMMAND_UI controladores, entonces debe claro m_bAutoMenuEnable explícitamente. Volver a lo contrario, los menús que deshabilita serán habilitar automáticamente.
Cambios de proyecto (compilación)
Puede seguir generar la aplicación MFC 1.0 usando un makefile estándar. Por lejos la forma más sencilla de migrar su proyecto es utilizar las instalaciones del proyecto de Visual C++ para mantener su depedencies y otras opciones de proyecto dentro del entorno de Visual C++.
Un error de enlace común es externos no resueltos a COMDLG32.DLL y SHELL32.DLL API. Asegúrese de vincular con COMDLG32.LIB y SHELL32.LIB.
Podrá mejorar la compilación veces colocando # incluyen lt;afxwin.h > en un encabezado precompilado. Por Convención, las aplicaciones MFC 2.0 especifican "stdafx.h" como el encabezado precompilado. A continuación, el módulo stdafx.cpp incluye stdafx.h. Esta técnica es ilustrada por el código creado por AppWizard y muchos de los ejemplos de MFC 2.0.
&Notanbsp; Es importante que usted defina ni anular cualquiera de las macros _AFX_NO_XXX en stdafx.h. Consulte el artículo de Knowledge Base "PRB: Problems Occur When Defining _AFX_NO_XXX." Puede encontrar artículos de Knowledge Base en el CD de MSDN Library o en http://www.microsoft.com/kb/.
Visual C++ y ClassWizard compatibilidad
Incluso para la migración de mínimo, le recomendamos que siga los pasos siguientes para que pueda utilizar Visual C++ y ClassWizard para editar sus recursos de la aplicación y el código.
//{{AFX_MSG_MAP (lt; nombre de clase >)
//}}AFX_MSG_MAP
lt; nombre de clase > es el nombre de la clase que contiene el mapa de mensajes.
Asimismo, agregue las siguientes líneas de dos comentario dentro de la correspondiente declaración de clase en el archivo .h:
//{{AFX_MSG (lt; nombre de clase >)
//}}AFX_MSG
Un ejemplo de estas declaraciones, mirar las mismas líneas de comentario en cualquier aplicación creada por AppWizard. Para obtener una explicación de lo que significan estas líneas de comentario, consulte MFC: utilizar los archivos de código fuente de MFC en la Guía del programador de Visual C++.
//{{AFX_VIRTUAL (lt; nombre de clase >)
//}}AFX_VIRTUAL
Migración completa
Una migración completa de la aplicación existente de c o MFC 1.0 a 2.0 MFC te ofrece todas las ventajas de MFC 2.0. Para la mayoría de las aplicaciones, una migración completa no es difícil y bien vale el esfuerzo.
Un éxito de la migración completa de una aplicación MFC 2.0 requiere esencialmente el mismo entendimiento de MFC 2.0 como el desarrollo de una nueva aplicación desde cero. Usted debe familiarizarse con la biblioteca de clases MFC 2.0, Visual C++, AppWizard y ClassWizard antes de comenzar la migración completa. Debe comprender qué partes de código de la aplicación pueden ser eliminado por derivan las clases MFC 2.0 funcionalidad equivalente o mayor. No sólo utilizando más la implementación de la biblioteca hará su código fuente más pequeña, pero hará que estas partes de la aplicación mejor integrado con el resto del marco MFC.
Migrando completamente la aplicación MFC 2.0, podrá derivar funciones adicionales de MFC en relativamente poco costo adicional. Por ejemplo, si su aplicación no tenía una interfaz de usuario de la ventana de separador, pero uno sería útil a los usuarios, a continuación, podrá agregar rápidamente esta característica, ya haber portado el código para la arquitectura documento/vista MFC 2.0.
Aunque una migración completa a MFC 2.0 puede requerir esfuerzo un par de días para aplicaciones de gran tamaño, el proceso en sí es bastante sencillo. Los pasos generales siguientes describen el proceso:
Hacer esto antes de empezar a editar cualquier código. Muchos programadores tienden a se entrelazan código de documento con el código de la vista. Aunque hacerlo no es necesariamente "malo", separación de funciones de documento y la vista es una filosofía de diseño que el marco MFC respalda y apoya especialmente bien. Aunque MFC 1.0 no tuvieron clases CDocument y CView , también apoya la separación de la vista del documento. También lo harán todas las versiones futuras de la biblioteca.
Estudiar las muestras de MFC 2.0 que utilizan las clases CDocument y CView , especialmente el ejemplo de Tutorial de MFC a mano alzada. A continuación, analizar su aplicación para determinar lo que es el documento y cuál es la vista. Determinar si la aplicación tiene varios tipos de documento o vistas.
Incluso si la aplicación no prestarse para borrar la vista del documento separación, todavía ser capaz plenamente migrar a MFC 2.0 y aprovechar esencialmente completo del marco. Usted puede "falsas" vista del documento separación de aplicación CDocument- y CView-derivado de las clases, pero su documento o vista clase podrá delegar la mayor parte de su trabajo a la otra clase. O la clase de vista podría depender de tu CFrameWnd- o CMDIChildWnd-derivado de la clase para implementar el grueso de la interfaz de usuario de la aplicación. En resumen, tienes casi completa libertad de cómo separar el documento, vista y clases de ventana de marco.
El análisis también debe determinar si la aplicación necesita varias clases de vista y posiblemente varias clases de documento. Aplicaciones incluso relativamente sencillas a veces necesitan más de una clase de vista. Sin embargo, no determinan necesariamente varias vistas, como en una ventana divisora, que tienen múltiples CView-clases derivadas. Por ejemplo, si cada panel en la ventana separador proporciona la misma interfaz de usuario como otros paneles en la ventana divisora, entonces pueden compartir la misma clase de vista. En ese caso, cada panel es simplemente un objeto distinto de la misma clase de vista. Probablemente deseará diseñar varias clases de vista, si la aplicación proporciona interfaces de usuario muy distintas en diferentes ventanas.
AppWizard creará un esqueleto aplicación MFC 2.0 que soporta varias características de marco que seleccione como opciones en los cuadros de diálogo AppWizard. Antes de ejecutar el Asistente para aplicaciones para crear la aplicación esqueleto, debe primero familiarizarse con las opciones que AppWizard proporciona.
Luego, tomar un poco de tiempo para decidir cuál de las opciones del Asistente para aplicaciones desea seleccionar. No intente hacer esto en pocos minutos la primera vez que ejecute AppWizard. Por ejemplo, si la aplicación ya no admite OLE, esto es una decisión importante que desee examinar. Si no elige opción de OLE de AppWizard para comenzar con, todavía podrá modificar el código de la aplicación para utilizar funciones de OLE de MFC. Pero comenzando con la opción de OLE en AppWizard para comenzar con la voluntad de ahorrar tiempo.
Su análisis deben determinar si la aplicación es una interfaz de único documento (SDI) o múltiples aplicaciones MDI (interfaz) de documento. Esta determinación particular debería ser obvia si está familiarizado con estas dos interfaces de usuario distinto en otras aplicaciones de Windows. AppWizard creará aplicaciones MDI predeterminada desde la interfaz de usuario MDI es generalmente más funcional a los usuarios finales les permite abrir más de archivo de documento uno cada vez. Afortunadamente, con la arquitectura documento/vista de MFC 2.0, apoyo MDI no requiere codificación adicional de tu parte.
Una vez hecho el análisis anterior, ya está preparado para ejecutar el Asistente para aplicaciones para crear el código esqueleto para su aplicación.
Tras haber analizado cómo la aplicación separa en documentos, vistas y ventanas de marco, debe tener una buena idea qué nombres para dar a sus clases correspondientes y módulos. Tal vez desee asignar nombres algo genéricos, como la muestra tutorial CScribDoc y CScribView y scribdoc.cpp y scribvw.cpp. Sin embargo, si la aplicación requiere varias clases de vista, probablemente querrá dar la primera clase de vista AppWizard creado un nombre más especializado, como CDataEntryView y CReportView. Vea el paso siguiente para obtener información adicional sobre la creación de varias clases de documento y la vista.
Tener previsto qué opciones AppWizard adicionales que desee, como SDI o MDI, y OLE, ahora podrá seleccionar las opciones de AppWizard y crear la aplicación esqueleto en pocos minutos.
Si el análisis anterior determina que la aplicación debe tener múltiples vista, documento o clases de ventana de marco, entonces es un buen momento para crear el código esqueleto para estas clases de derecho después de ejecutar el Asistente para aplicaciones.
Puede crear el código esqueleto para su vista adicional, documentos y clases de ventana de marco mediante la clonación de los creados por AppWizard. Es decir, copiar los archivos .cpp y .h, asignar un nuevo nombre de módulo para el segundo documento o clase. A continuación, editar el código esqueleto cambiando nombres de clase. Otra alternativa es utilizar la funcionalidad de Agregar clase de ClassWizard para crear una nueva clase automáticamente en los archivos que se especifica utilizando los nombres que especifique. Ya estará familiarizado con capacidad de ClassWizard crear nuevas clases si han seguido el tutorial de GARABATO.
En cualquier caso, en su CWinApp-derivados de la función InitInstance de la clase, se deben registrar objetos de plantilla de documento adicional para cualquier asociación que desee hacer entre varios documentos, ver y clases de ventana de marco.
Este es también un paso rápido. Puede aplazar este paso si no está comprometida con la aplicación de varios documentos, vistas o clases de ventana de marco en su aplicación.
Este paso representa la mayor parte del trabajo para migrar la aplicación MFC 1.0 a 2.0 de MFC. Debe hacerlo gradualmente. Migrar relativamente pequeñas porciones de su aplicación a la vez. Como hacerlo, aprenderá más detalles acerca de lo que el marco proporciona la funcionalidad le permitirá descartar algunos de su antiguo código de aplicación MFC 1.0.
Como migrar estos fragmentos de código, tenga en cuenta las directrices presentadas en virtud de "Migración mínima". Muchas de estas directrices se aplican a migración completa. AppWizard ya habrá agregado los comentarios //{{AFX_MSG y //{{AFX_MSG_MAP a sus clases de destino de comando (aplicación, documento, vista y ventana de marco). No es necesario para que estos agregue manualmente bajo el enfoque de migración mínima. Aunque no es necesario, se recomienda mover funciones de tratamiento de mensajes entre los comentarios //{{AFX_MSG anidados en los mapas de mensajes. También, mover las declaraciones de estas funciones de tratamiento de mensajes (afx_msg) entre los comentarios //{{AFX_MSG en los archivos de encabezado. Ello le permitirá utilizar ClassWizard el resto de life cycle(s) del proyecto.
Estas recomendaciones respecto a los comentarios //{{AFX_MSG también se aplican, quizás en menor grado, a los cuadros de diálogo. Si no anticipar muchos futuros cambios a una clase de diálogo dado, entonces no cabe su esfuerzo para hacer que ese diálogo ClassWizard consciente. Eso está muy bien. Por supuesto, le recomendamos que cree todas nuevas clases de diálogo utilizando la opción de Agregar clase de ClassWizard.
Como migrar una aplicación MFC 1.0 o Windows, puede que desee mantener la compatibilidad con formatos de archivo existentes. (El mecanismo de serialización predeterminado MFC 2.0 documento no puede ser apropiado para su aplicación.) Dirigir CFile escribir y leer las llamadas, o implementar un archivo no basado documento, desea reemplazar CDocument::OnOpenDocument y OnSaveDocument. El ejemplo General de MFC DIBLOOK proporciona un ejemplo de esta técnica. Si su aplicación actual ya serializa objetos, entonces esto no será un problema.
Alfabéticos API de cambios
Para comprender las razones de estos cambios, consulte "Razón para los cambios" a continuación.
| API / Variable | MFC 2.0 cambiar (razón de cambio) |
| CMetaFileDC::Close | Tipo de valor devuelto (2) |
| CWnd | Param predeterminado extra añadido, CWnd * const (1, 3) |
| CFrameWnd::Create | Param predeterminado extra añadido, CWnd * const (1, 3) |
| CMDIChildWnd::Create | Param predeterminado extra añadido, CWnd * const (1, 3) nbsp; dwStyle valor por defecto es ahora: WS_CHILD | WS_VISIBLE | WS_OVERLAPPEDWI&NDOW |
| CWnd::CreateEx | Param predeterminado extra añadido, CWnd * const (1, 3) |
| CBitmap::CreateBitmap | Tipos de parámetros (4) |
| CDC::EnumObjects | Prototipo de devolución de llamada (2) |
| CTime::Format | Función const (3) |
| CTimeSpan::Format | Función const (3) |
| CTime::FormatGmt | Función const (3) |
| CFile::GetStatus | Nonvirtual (5) |
| CDC::GrayString | Tipo de prototipo y parámetro de devolución de llamada (2) |
| CBitmapButton::LoadBitmaps | Parámetro predeterminado adicional (1) |
| CWnd::OnActivateApp | Tipo de parámetro (2) |
| CWnd::OnCompareItem | Parámetro adicional (6) |
| CWnd::OnDeleteItem | Parámetro adicional (6) |
| CWnd::OnDrawItem | Parámetro adicional (6) |
| CWnd::OnDropFiles | Tipo de parámetro (2) |
| CWnd::OnGetMinMaxInfo | Tipo de parámetro (6) |
| CWnd::OnMeasureItem | Parámetro adicional (6) |
| CWnd::OnMenuChar | Tipo de valor devuelto (2) |
| CWnd::OnNcCalcSize | Parámetro adicional (6) |
| CWnd::OnPaintClipboard | Tipo de parámetro (2) |
| CWnd::OnParentNotify | Tipo de parámetro (2) |
| CWnd::OnSizeClipboard | Tipo de parámetro (2) |
| CWnd::OnSysCommand | Tipo de parámetro (2) |
| CWnd::OnWinIniChange | Tipo de parámetro (2) |
| CDC::PlayMetaFile | Tipo de parámetro (2) |
| CEdit::SetSel | Parámetro predeterminado adicional (6) |
| CEdit::SetTabStops | Tipo de parámetro (5) |
| CWnd::SetTimer | Tipo de prototipo y parámetro de devolución de llamada (2) |
| CRuntimeClass::m_pszClassName | Renombrado como m_lpszClassName (5) |
| API obsoleto o eliminado | MFC 2.0 cambiar (razón de cambio) |
| CBitmapButton | Ctor eliminado con 3 params - utilizar LoadBitmaps (1) |
| CMDIFrameWnd:: CreateClient | Utilice OnCreateClient (1) |
| GetChildFrame | Utilice MDIGetActive (1) |
| GetDCOrg | Usar la API de Windows directamente para 3.x (4) |
| m_pMDIFrameWnd | La palabra GetParentFrame O GetMDIFrame (1) |
Razones de los cambios:
Errores del compilador
Más cambios en la API 2.0 de MFC generará uno de los pocos errores del compilador, o ninguno en absoluto si el compilador ajustan a las conversiones de tipo estándar. Los siguientes errores de compilador pueden generarse al compilar las aplicaciones MFC 1.0 existentes bajo 2.0 de MFC:
| Número | Mensaje de Error de compilador |
| Error del compilador C2039 | 'Identificador': no es un miembro de la "clase-clave." |
| Este error se produce cuando una función miembro o miembro de datos se ha quitado de una clase, por ejemplo de CFrameWnd m_pMDIFrameWnd. | |
| Error del compilador C2501 | 'Identificador': faltan los especificadores de /Decl. |
| Este error se produce cuando se utiliza un nombre de clase desconocida. Esto suele ser el caso cuando la clase ya no existe o se ha movido a un archivo de encabezado diferentes. Por ejemplo si obtiene este error para CMetaFile y CBitmapButton entonces usted debe agregar # include "afxext.h" a los archivos de código fuente utilizando las clases. | |
| Error del compilador C2248 | 'Miembro' no puede tener acceso a miembros de 'especificador' declarado en la clase 'clase'. |
| Este error se produce si el acceso de un miembro ha cambiado de MFC 1.0 a 2. Por ejemplo, una API de indocumentados se ha movido de público acceso de miembros protegidos . Esto debe ocurrir sólo en el código que utiliza las APIs de indocumentados y no admitidas, que debe ser modificadas para utilizar la funcionalidad adecuada de MFC 2.0. | |
| Error del compilador C2642 | Elenco de puntero a miembro debe ser del puntero relacionado a miembros. |
| Este error se produce cuando el prototipo de función de controlador de mensaje difiere de la de afxwin.h. Por ejemplo, una línea que contiene la macro ON_WM_ACTIVATEAPP emitirá este error si los parámetros y el tipo de valor devuelto de su controlador de mensajes de OnActivateApp coincide con la declaración de MFC 1.0. | |
| Error del compilador C2660 | 'Función': función no tiene parámetros de 'número'. |
| El número de parámetros ha cambiado de MFC de 1.0 a 2.0 de MFC. Por ejemplo, llamar al constructor de CBitmapButton con tres parámetros provoca este error ya que este constructor particular ha sido eliminado y reemplazado por la función de miembro de LoadBitmaps. | |
| Error del compilador C2664 | 'Función': no se puede convertir el parámetro 'número' de 'tipo1' a 'tipo2'. |
| Ha cambiado el tipo de un parámetro, y conversiones estándar no satisfacen el compilador. CDC::EnumObjects es un ejemplo de ello. En este caso, ha cambiado el prototipo de la función de devolución de llamada. |
&Notas técnicas por número |nbsp; Notas técnicas por categoría