TN019: L'aggiornamento di applicazioni MFC esistenti a MFC 3.0

Questa nota tecnica principalmente fornisce le linee guida per la migrazione di applicazioni MFC 1.0 agli strumenti 2.0 MFC. Ulteriori differenze tra MFC 2.0, 2.5 e 3.0 sono presentate nella prima sezione, di sotto.

MFC 4.0/3.0 API cambia

Non ci sono cambiamenti noti alle API MFC documentata che causerebbero codice esistente richiedere modifiche. Ci sono, naturalmente, molte caratteristiche addizionali di che volete approfittare. Per ulteriori informazioni su queste funzionalità, vedere il manuale del programmatore di Visual C++.

MFC 2.5 API cambia

MFC 2.5 aggiunto due caratteristiche principali per la libreria di classi: supporto OLE 2.0, che ha sostituito il OLE 1.0 sostegno e supporto ODBC, che fornisce l'accesso ai database. Esso è l'intenzione di questa nota tecnica per coprire le modifiche di API che possono influire sul codice esistente. Per informazioni su queste nuove funzionalità, non trattate in questa nota tecnica, vedere il manuale del programmatore di Visual C++.

RecalcLayout ha un parametro aggiuntivo, BOOL bNotify. Questo specifica di notificare qualsiasi server OLE o meno che essi layout è cambiato. È normalmente vero e pertanto che è l'impostazione predefinita. Questa funzione è virtuale, quindi se il vostro programma fornisce un override di questa funzione è necessario aggiungere il parametro supplementare alla vostra funzione pure.

C'erano altre modifiche apportate a funzioni non documentate nelle librerie MFC 2.5 per supportare OLE 2.0, nonché ODBC. Se il programma utilizza le API MFC privi di documenti, è necessario rivedere tutte le tali usi per assicurarsi che essi sono ancora valide.

Migrazione MFC 1.0 applicazioni MFC 2.0

IMPORTANTE: Per comprendere e valutare i due approcci presentati di seguito, è necessario essere familiarità con i concetti di MFC 2.0, come l'architettura del documento e visualizzazione e gli strumenti. Suggeriamo che almeno lavorare attraverso l'esempio MFC Tutorial SCARABOCCHIARE nel tutorial prima di iniziare qualsiasi migrazione del codice esistente.

Ci sono due approcci di base per eseguire la migrazione applicazioni esistenti da MFC versione 1, pubblicate con Microsoft C7, a MFC versione 2.

Migrazione minimal

Utilizzando il metodo "Minimal Migration", si fanno solo le modifiche minime necessarie, affinché:

Questo è l'approccio più semplice, ma non prende la funzionalità ricche di nella libreria MFC 2.0. Anche se hai scelto il metodo di "Migrazione completa", sarà necessario capire ed esercitare le tecniche per la migrazione minimal.

Migrazione completa

Se si esegue una migrazione"completa", voi potrete godere appieno della libreria MFC 2.0. Utilizzando il metodo di migrazione minimal, sarete in grado di modificare l'applicazione utilizzando Visual C++ e ClassWizard. Utilizzando il metodo di migrazione completa, ottenere il supporto di MFC 2.0 seguente:

Il metodo di migrazione globale completa è fondamentalmente per emulare lo sviluppo di applicazioni MFC 2.0 da zero, iniziano con la creazione guidata applicazione. La differenza con lo sviluppo di applicazioni MFC 2.0 da zero, naturalmente, è che sarà in prestito come gran parte del codice MFC 1.0 che ha scritto come un senso di.

Migrazione minimal

Le seguenti sottosezioni presentano linee guida dettagliate per l'esecuzione di una migrazione minimal.

Conforme al Windows 3.1 STRICT typedef

Il valore predefinito si basa 2.0 MFC libreria rispettare i typedef Windows 3.1 STRICT che sono spiegati nel SDK di Windows 3.1. MFC 1.0 aveva STRICT spento, ma ora MFC 2.0 ha STRICT attivata per impostazione predefinita. Questo segue l'impegno di MFC per tenere traccia delle API di Windows standard dell'industria e per promuovere pratiche di sviluppo che rendono lo sviluppo di applicazioni robuste e più facile. Proprio come i typedef STRICT sono stati utili per gli sviluppatori delle classi MFC 2.0 per produrre software robusto, così che sarà vero per te lo sviluppo di codice dell'applicazione.

Quando si utilizza il controllo per la prima volta dei tipi STRICT , molti errori di compilazione si tradurrà in genere. Modificando l'applicazione MFC 1.0 siano conformi al Windows 3.1 STRICT TypeDef può benissimo rappresentano la maggior parte del vostro sforzo minimo di migrazione.

Una volta che l'applicazione sia conforme STRICT, sarete in grado di compilare un eseguibile con senza ulteriori modifiche. Ad esempio, i campioni di ABOUT2 e FILEVISUALIZZA MFC 1.0 compilare con senza ulteriori modifiche. Essi erano già STRICT conforme e ha fatto non utilizzato qualsiasi cambiato MFC API.

MFC 2.0 API cambia

Di là di conforme a STRICT, la maggior parte dello sforzo di fare una migrazione minima è per identificare e cambiare il codice dell'applicazione di conformarsi alle API 2.0 MFC relativamente poche modifiche.

Fuori di oltre 1800 MFC 1.0 API, solo 20 delle API che sono stati cambiati risultato Errori in fase di compilazione. Questi cambiamenti richiedono solo banale modifiche alle applicazioni MFC 1.0 esistenti. Le modifiche più estese sono la ristrutturazione architettonica delle classi OLE. Questi cambiamenti sono coperte in tecnica nota 18.

Anticipare che cambiamenti voi avrete bisogno di fare, vedere la sezione "Modifiche API alfabetico" alla fine di questa nota tecnica. Esso fornisce un riepilogo utile, breve, di cui MFC 1.0 API sono state modificate in MFC 2.0.

Se non si fanno tutte le modifiche necessarie per affrontare il codice MFC 2.0, si otterrà vari compilazione e gli errori di collegamento. Questi errori sono quasi sempre facili da diagnosticare. Per facilitare la tua diagnosi, forniamo alcune linee guida nella sezione "Errori del compilatore" alla fine di questa nota tecnica.

Le seguenti API MFC sono stati rimossi in MFC 2.0. Si consiglia di APIs alternativo all'occorrenza. Questo elenco non comprende le modifiche all'implementazione non documentati API.

CDC::GetDCOrg

GetDCOrg non è disponibile in Win32. Per applicazioni sola Windows 3. x, basta chiamare l'API Windows :: GetDCOrg direttamente.

CRuntimeClass::m_pszClassName

Questa variabile membro è ora un LPSTR anziché il modello di memoria-dipendente (char *). Esso è denominato m_lpszClassName in MFC 2.0.

CMDIChildWnd::m_pMDIFrameWnd

In MFC 1.0, questa variabile membro ha sottolineato padre MDIFrame della classe. Questa variabile membro è stata sostituita con una funzione membro CMDIChildWnd::GetMDIFrame. Se si utilizza multiple document interface (MDI) in MFC 2.0, utilizza la maggior parte dei CMDIChildWnd::m_pMDIFrameWnd (o GetMDIFrame) non è più necessarie poiché il supporto MDI predefinita gestisce tutti i comandi di menu standard finestre MDI.

CFrameWnd::GetChildFrame

Utilizzare invece la CMDIFrameWnd::MDIGetActive per i frame MDI.

Le seguenti API è stata lasciata in MFC 2.0 per supportare 1 compatibilità ma è obsoleto. Esso verrà rimosso dal future versioni di MFC.

CMDIFrameWnd::CreateClient

Questa funzionalità è stata sostituita dal più generale OnCreateClient meccanismo che supporta la creazione di vista e il migliorato supporto MDI MFC 2.0. L' originale CreateClient ancora può essere utilizzato per le applicazioni MDI che gestiscono la barra dei menu della propria finestra cornice MDI (tramite CMDIFrame::MDISetMenu). Il supporto MDI MFC 2.0 passa automaticamente barra dei menu della finestra MDI telaio al menu per la finestra figlio MDI attivo.

Altre modifiche relative API

Due classi MFC sono state spostate dagli a AFXWIN. h il file di intestazione AFXEXT:

Nel vostro file cpp che fanno riferimento a queste classi di aggiungere il seguente:

# include lt;afxext.h>

Molte API sono state modificate in modo che siano più severe riguardanti l'utilizzo del modificatore 'const'. Queste modifiche si tradurrà in un uso più coerenza del nome del tipo LPCSTR e il nuovo nome del tipo LPCRECT. Si noti, non non c'è alcun problema di tempo di compilazione con questi cambiamenti, poiché qualsiasi tipo può essere promosso a una versione const di quel tipo quando viene utilizzato come argomento. Come il cambiamento STRICT , questo porta a codice più efficiente quando il codice utilizza puntatori dati const.

Le funzioni di creazione finestra elencate di seguito ora hanno un parametro aggiuntivo, ma poiché l'ultimo parametro ha un valore predefinito è NULL, il codice esistente funzionerà senza alcuna modifica. Queste funzioni sono

Le seguenti funzioni erano virtuale in MFC 1.0, ma ora sono non virtuale in MFC 2.0:

Se una classe derivata dell'applicazione MFC 1.0 l'override di una di queste funzioni, è improbabile che sarà chiamata la funzione della classe derivata in MFC 2.0. Inoltre, GetParentFrame è stato spostato da CFrameWnd a CWnd di essere un'API più generalmente utile.

Tutti i membri statici di classi, come pure le funzioni globali operatore/amico, ora rispettare le convenzioni di chiamata PASCAL . Tutte le funzioni globali sono AFXAPI (PASCAL). Ancora una volta, questo non è un problema di tempo di compilazione, ma conduce al codice generato più piccolo e più veloce.

Molte delle classi di implementazione e strutture sono stati rinominati a non utilizzare il prefisso "C". Ad esempio, CExceptionContext è stata rinominata in AFX_EXCEPTION_CONTEXT. Queste classi non sono documentate e rimangono i dettagli di implementazione della libreria di classi. È improbabile che vi hanno fatto affidamento su questi, e generalmente è raccomandato che non fare affidamento sulle API privi di documenti della biblioteca classe dal momento che sono soggette a modifiche nelle versioni future.

MFC 2.0 cambia comportamento predefinito

Trattare con MFC API modifiche è facile con l'aiuto di errori segnalati dal compilatore e del linker. Non tutte le modifiche di biblioteca sono rivelate nei file di intestazione biblioteca, tuttavia. Alcuni cambiamenti sono rivelati nel comportamento della fase di esecuzione dell'applicazione. Questi cambiamenti sono generalmente non difficili da affrontare, fintanto che voi anticiparle. Le seguenti informazioni vengono fornite per aiutarti a prevedere tali cambiamenti comportamentali.

CDialog e CModalDialog sono state fuse in una classe singola. CModalDialog ora è considerata una classe obsoleta. Tuttavia, per compatibilità con MFC 1.0, tutti i riferimenti a CModalDialog sono ancora validi attraverso una macro di migrazione in a AFXWIN. h:

# define CModalDialog CDialog

Per molte applicazioni MFC 1.0, questo semplice # define è sufficiente. Tuttavia, ci sono casi dove si definiscono questo # non è sufficiente.

Se implementata una finestra di dialogo non modale e invocata "fare niente" comportamento predefinito per OnOK e OnCancel, quindi eseguire l'override questi ed il comportamento predefinito, dal momento che ora chiamano EndDialog (per l'elaborazione di finestre di dialogo modali).

CDialog::CreateIndirect ancora crea una finestra di dialogo non modale. Per creare una finestra di dialogo modale utilizzare CDialog:: InitModalIndirect anziché il rimosso CModalDialog::CreateIndirect API.

Finestra di dialogo casella e messaggio casella colori di sfondo possono ora essere globalmente impostati utilizzando CWinApp::SetDialogBkColor API. Il parametro predefinito imposta il colore grigio chiaro (non COLOR_BTNFACE) per produrre sfondo grigio. È possibile specificare altri colori.

Se SetDialogBkColor non viene chiamato nel vostro CWinApp-derivati funzione InitInstance , il valore predefinito sfondo della finestra viene utilizzato il colore (impostato nell'applet colore del pannello di controllo).

In MFC 1.0, se una DLL contiene un oggetto CWinApp , era necessario fornire una DllMain che comprendeva una chiamata a AfxWinTerm. MFC 2.0 fornisce questo DllMain, così alcun codice aggiuntivo incluso nel vostro DllMain dovrebbe essere migrato alla funzione di membro della DLL CWinApp::ExitInstance.

CMDIChildWnd::Create ora correttamente utilizza il parametro dwStyle . È ora necessario specificare uno stile finestra completa per la finestra figlia MDI. Se si specifica dwStyle = 0, ora si otterrà un errore ASSERT in CMDIChildWnd::PreCreateWindow. Per evitare questo, è necessario specificare lo stile WS_CHILD | WS_VISIBLE | WS_OVERLAPPEDWINDOW per essere compatibile con MFC 1.0.

MFC 2.0 supporta stili diversi di impostazione per finestre figlio MDI, quindi rimuovere alcuni dei controlli finestra cornice, se lo si desidera.

Classe CFrameWnd ha un nuovo membro dati, BOOL CFrameWnd::m_bAutoMenuEnable. Esso è impostato su TRUE per impostazione predefinita. Questo fa sì che le voci di menu che non dispongono di gestori ON_UPDATE_COMMAND_UI o ON_COMMAND va automaticamente disabilitato. Voci di menu che hanno i gestori ON_COMMAND , ma senza gestori ON_UPDATE_COMMAND_UI , verranno attivate automaticamente.

Ciò rende più semplice implementare i comandi opzionali basati sulla selezione corrente. Inoltre, questo riduce notevolmente la necessità per le applicazioni per scrivere gestori ON_UPDATE_COMMAND_UI per abilitare/disabilitare delle voci di menu. Per esempio, un'applicazione generata da creazione guidata applicazione avrà Edit taglia/copia/incolla disattivato fino a quando il programmatore implementa i gestori per loro.

Tuttavia, se l'applicazione MFC 1.0 non è aggiornato per utilizzare ON_COMMAND e gestori ON_UPDATE_COMMAND_UI , quindi deve deselezionare m_bAutoMenuEnable in modo esplicito. In caso contrario, menù che si disattiva verrà riattivato automaticamente.

Modifiche di progetto (Build)

Si può continuare a costruire l'applicazione MFC 1.0 utilizzando un makefile standard. Di gran lunga il modo più semplice per eseguire la migrazione del progetto è quello di utilizzare l'impianto di progetto di Visual C++ per mantenere la vostra depedencies e altre opzioni di progetto all'interno dell'ambiente di Visual C++.

Un errore comune di collegamento è esterni non risolti a COMDLG32.DLL e SHELL32.DLL API. Assicurarsi di collegamento con COMDLG32.LIB e SHELL32.LIB.

Si può essere in grado di migliorare la compilazione volte inserendo # includono lt;afxwin.h > in un'intestazione precompilata. Per convenzione, le applicazioni MFC 2.0 specificano "stdafx" come l'intestazione precompilata. Poi il modulo stdafx. cpp include stdafx. Questa tecnica è illustrata il codice creato da AppWizard e da molti dei campioni MFC 2.0.

&Notanbsp;  È importante che non definire né annullare la macro AFX_NO_XXX di stdafx. Vedere l'articolo della Knowledge Base "PRB: problemi si verificano quando si definisce AFX_NO_XXX." Si possono trovare articoli della Knowledge Base su CD di MSDN Library o http://www.microsoft.com/kb/.

Visual C++ e compatibilità ClassWizard

Anche per le migrazioni minimal, noi consigliamo di seguire la procedura seguente modo che è possibile utilizzare Visual C++ e ClassWizard per modificare le risorse dell'applicazione e il codice.

Migrazione completa

Una migrazione completa dell'applicazione c o MFC 1.0 esistente a MFC 2.0 vi offrirà tutti i vantaggi di MFC 2.0. Per la maggior parte delle applicazioni, una migrazione completa non è difficile ed è valsa la pena.

Una migrazione completa riuscita di un'applicazione MFC 2.0 richiede essenzialmente la stessa comprensione del MFC 2.0 come lo sviluppo di una nuova applicazione da zero. Dovrebbe acquisire familiarità con la libreria di classi MFC 2.0, Visual C++, AppWizard e ClassWizard prima di iniziare la migrazione completa. Si dovrebbe capire che cosa le porzioni di codice dell'applicazione possono essere rimosso mediante derivazione equivalente o migliorate funzionalità dalle classi MFC 2.0. Non solo utilizzando più dell'implementazione della libreria farà codice sorgente più piccoli, ma farà queste parti dell'applicazione meglio integrata con il resto del quadro MFC.

Migrando completamente l'applicazione MFC 2.0, sarà in grado di derivare le funzionalità aggiuntive da MFC a relativamente poco alcun costo aggiuntivo. Ad esempio, se l'applicazione non aveva un'interfaccia utente di splitter finestra, ma uno sarebbe utile agli utenti, poi si sarà in grado di aggiungere rapidamente questa caratteristica, avendo già fatto il porting del codice per architettura documento/visualizzazione di MFC 2.0.

Anche se una migrazione completa a MFC 2.0 può essere richiesto lo sforzo un paio di giorni per applicazioni di grandi dimensioni, il processo stesso è abbastanza semplice. La procedura generale seguente descrive il processo di:

  1. Analizzare come fattori di architettura applicazione esistente nel documento, visualizzazioni e finestre con frame.

    Fare questo, prima di iniziare qualsiasi codice di editing. Molti programmatori tendono a si intrecciano il codice con il codice di visualizzazione del documento. Anche se fare così non è necessariamente un "male", separazione delle funzionalità di visualizzazione e documento è una filosofia di progettazione che il framework MFC approva e sostiene particolarmente bene. Anche se non avevano le classi CDocument e CView , MFC 1.0 ha approvato anche separazione documento/vista. Così sarà tutte le versioni future della Biblioteca.

    Studiare gli esempi di MFC 2.0 che utilizzano le classi CDocument e CView , in particolare l'esempio Tutorial MFC SCARABOCCHIARE. Poi analizzare l'applicazione per determinare che cosa è il documento e che cosa è la vista. Determinare se l'applicazione dispone di molteplici tipi di documento o viste.

    Anche se l'applicazione non si presta a una chiara separazione documento/vista, sarete ancora in grado di completamente la migrazione a MFC 2.0 e sfruttare essenzialmente completa il quadro. Si può "falso" documento/vista separazione implementando CDocument- e CView-classi, ma il documento o vista classe può delegare la maggior parte del suo lavoro alla classe di altre derivate. O classe di visualizzazione potrebbe contare sul vostro CFrameWnd- o CMDIChildWnd-derivati classe per implementare la maggior parte dell'interfaccia utente dell'applicazione. In sintesi, si hanno quasi completa libertà su come separare il tuo documento, visualizzazione e classi di finestre cornice.

    L'analisi dovrebbe anche determinare se l'applicazione ha bisogno di più classi di visualizzazione e possibilmente più classi di documento. A volte, anche relativamente semplici applicazioni bisogno più di una classe di visualizzazione. Tuttavia, viste multiple, come in una finestra con separatore, non necessariamente dettano che avete più CView-classi derivate. Ad esempio, se ciascun riquadro nella finestra sdoppiatore fornisce la stessa interfaccia utente come altri riquadri nella finestra splitter, quindi essi possono condividere la stessa classe di visualizzazione. In tal caso, ciascun riquadro è semplicemente un oggetto distinto della stessa classe di visualizzazione. Probabilmente vorrete a progettare più classi di vista, se l'applicazione fornisce interfacce utente molto distinto in varie finestre.

  2. Analizzare quali caratteristiche supportate da AppWizard quadro avrà bisogno di applicazione.

    Creazione guidata applicazione creerà uno scheletro applicazione MFC 2.0 che supporta varie funzionalità del framework che selezioni come opzioni nelle finestre di dialogo Creazione guidata applicazione. Prima di eseguire la creazione guidata applicazione per creare un'applicazione ossatura, deve prima diventare familiare con le opzioni di che creazione guidata applicazione fornisce.

    Poi, prendere un po' di tempo per decidere quale delle opzioni di creazione guidata applicazione ti consigliamo di selezionare. Non tentare di farlo in pochi minuti la prima volta che si esegue la creazione guidata applicazione. Ad esempio, se l'applicazione non supporta già OLE, questa è una decisione importante che si vorrà prendere in considerazione. Se non hai scelto di opzione OLE di creazione guidata applicazione per iniziare con, sarete ancora in grado di modificare il codice dell'applicazione per utilizzare le funzionalità OLE di MFC. Ma partenza con l'opzione OLE in creazione guidata applicazione per iniziare con la volontà di risparmiare tempo.

    L'analisi dovrebbe determinare se l'applicazione è un'interfaccia a documento singolo (SDI) o applicazione multiple document interface (MDI). Questa determinazione particolare dovrebbe essere ovvia se hai familiarità con questi due interfacce utente distinto in altre applicazioni di Windows. Creazione guidata applicazione creerà applicazioni MDI per impostazione predefinita poiché l'interfaccia utente MDI è solitamente più funzionale agli utenti finali per esso permette loro di aprire più di un unico documento/file alla volta. Per fortuna, con l'architettura del documento/vista MFC 2.0, supporto MDI non richiede alcun codice aggiuntivo da parte dell'utente.

  3. Generare una nuova applicazione utilizzando la creazione guidata applicazione.

    Aver fatto l'analisi di cui sopra, è ora pronti per eseguire la creazione guidata applicazione per creare il codice per la vostra applicazione.

    Dopo aver analizzato come applicazione separa in documento, visualizzazioni e finestre con frame, si dovrebbero avere una buona idea quali nomi per dare a loro corrispondenti classi e moduli. Si desidera assegnare nomi un po' generici, ad esempio dell'esempio tutorial CScribDoc e CScribView e scribdoc.cpp e scribvw.cpp. Tuttavia, se l'applicazione richiede più classi di vista, probabilmente vorrete dare la prima classe di vista creazione guidata applicazione creata un nome più specializzato, come ad esempio CDataEntryView e CReportView. Vedere il passaggio successivo per ulteriori informazioni sulla creazione di più classi di documento e visualizzazione.

    Dopo aver anticipato quali opzioni di creazione guidata applicazione aggiuntive che desiderate, come SDI o MDI, e OLE, si dovrebbe ora essere in grado di selezionare le opzioni di creazione guidata applicazione e creare l'applicazione ossatura in pochi minuti.

  4. Facoltativamente, clonare seconda visualizzazione, documento e classi di finestre cornice.

    Se l'analisi precedente determina che l'applicazione dovrebbe avere più vista, documento o classi di finestre cornice, allora è un buon momento per creare il codice per queste classi giusto dopo l'esecuzione della creazione guidata applicazione.

    È possibile creare il codice per la vostra ulteriore vista, documento e classi di finestre cornice clonando quelli creati da creazione guidata applicazione. Cioè, copiare i file con estensione cpp e h, l'assegnazione di un nuovo nome del modulo per il documento o la classe seconda. Quindi modificare il codice modificando i nomi delle classi. Un'altra alternativa è utilizzare funzionalità Aggiungi classe di ClassWizard per creare una nuova classe automaticamente nei file che è possibile specificare utilizzando i nomi che si specifica. Si sarà già familiarità con la capacità di ClassWizard di creare nuove classi se avete seguito il tutorial SCRIBBLE.

    In entrambi i casi nel vostro CWinApp-derivati funzione InitInstance della classe, è necessario registrare oggetti del modello di documento aggiuntivo per tutte le associazioni che si desiderano rendere tra di voi più documenti, vista e classi di finestre cornice.

    Questo è anche un passo veloce. Si può rinviare questo passaggio se non si è impegnata ad attuare più documenti, viste o classi di finestre cornice nell'applicazione.

  5. Migrare le parti pertinenti del codice MFC 1.0 nelle classi create da AppWizard.

    Questo passaggio rappresenta il grosso del lavoro nella migrazione applicazione MFC 1.0 a 2.0 MFC. Si dovrebbe fare in modo incrementale. La migrazione relativamente piccole porzioni dell'applicazione in un momento. Come si fa questo, you'll learn più particolari circa le funzionalità il quadro prevede che verranno permetterà di scartare alcuni del vecchio codice dell'applicazione MFC 1.0.

    Come si esegue la migrazione di questi pezzi di codice, tenere a mente gli orientamenti presentati sotto "Minimal migrazione". Molti di tali orientamenti applicare alla migrazione completa. AppWizard si sono aggiunti già i commenti //{{AFX_MSG e //{{AFX_MSG_MAP per le classi di destinazione comando (applicazione, documento, vista e finestra cornice). Non è necessario per voi queste aggiungere manualmente come sotto l'approccio di migrazione minimal. Sebbene non sia obbligatorio, è consigliabile spostare le funzioni di gestione dei messaggi tra i commenti //{{AFX_MSG annidati nelle mappe messaggio. Inoltre, spostare le dichiarazioni di queste funzioni di gestione dei messaggi (afx_msg) tra i commenti //{{AFX_MSG nel vostro file di intestazione. In questo modo vi permetterà di utilizzare ClassWizard per tutto il resto della life cycle(s) del progetto.

    Queste raccomandazioni per quanto riguarda i commenti //{{AFX_MSG applicano anche, forse, in misura minore, alle finestre di dialogo. Se non si prevede molti cambiamenti futuri a una classe di finestre di dialogo dato, quindi potrebbe non essere vale la pena il vostro sforzo per rendere quel ClassWizard consapevole della finestra di dialogo. Va bene. Noi consigliamo, naturalmente, di creare tutte le nuove classi di dialogo utilizzando l'opzione Aggiungi classe di ClassWizard.

    Come si esegue la migrazione di un'applicazione MFC 1.0 o Windows, si desidera mantenere la compatibilità con i formati di file esistenti. (Il meccanismo di serializzazione predefinito MFC 2.0 documento potrebbe non essere appropriato per la vostra applicazione.) Dirigere CFile scrivere e leggere le chiamate o per implementare un non di file basato su documenti, si desidera eseguire l'override di CDocument:: OnOpenDocument e OnSaveDocument. Il campione generale MFC DIBLOOK viene fornito un esempio di questa tecnica. Se l'applicazione corrente già serializza oggetti, quindi questo non sarà un problema.

Alfabetica API modifiche

Per comprendere le ragioni di queste modifiche, consultare "Motivo per modifiche" di sotto.

API / variabile MFC 2.0 cambiare (ragione per il cambiamento)
CMetaFileDC::Close Tipo restituito (2)
Viene Param predefinito supplementare aggiunto, CWnd * const (1, 3)
CFrameWnd::Create Param predefinito supplementare aggiunto, CWnd * const (1, 3)
CMDIChildWnd::Create Param predefinito supplementare aggiunto, CWnd * const (1, 3) nbsp; dwStyle predefinito è ora: WS_CHILD | WS_VISIBLE | WS_OVERLAPPEDWI&NDOW
CWnd::CreateEx Param predefinito supplementare aggiunto, CWnd * const (1, 3)
CBitmap::CreateBitmap Tipi di parametro (4)
CDC::EnumObjects Prototipo di richiamata (2)
CTime::Format Funzione const (3)
CTimeSpan::Format Funzione const (3)
CTime::FormatGmt Funzione const (3)
CFile::GetStatus Nonvirtual (5)
CDC::GrayString Tipo parametro e prototipo richiamata (2)
CBitmapButton::LoadBitmaps Parametro predefinito supplementare (1)
CWnd::OnActivateApp Tipo parametro (2)
CWnd::OnCompareItem Parametro supplementare (6)
CWnd::OnDeleteItem Parametro supplementare (6)
CWnd::OnDrawItem Parametro supplementare (6)
CWnd::OnDropFiles Tipo parametro (2)
CWnd::OnGetMinMaxInfo Tipo di parametro (6)
CWnd::OnMeasureItem Parametro supplementare (6)
CWnd::OnMenuChar Tipo restituito (2)
CWnd::OnNcCalcSize Parametro supplementare (6)
CWnd::OnPaintClipboard Tipo parametro (2)
CWnd::OnParentNotify Tipo parametro (2)
CWnd::OnSizeClipboard Tipo parametro (2)
CWnd::OnSysCommand Tipo parametro (2)
CWnd::OnWinIniChange Tipo parametro (2)
CDC::PlayMetaFile Tipo parametro (2)
CEdit::SetSel Parametro predefinito supplementare (6)
CEdit::SetTabStops Tipo di parametro (5)
CWnd::SetTimer Tipo parametro e prototipo richiamata (2)
CRuntimeClass::m_pszClassName Rinominata m_lpszClassName (5)

API cancellati o obsoleti MFC 2.0 cambiare (ragione per il cambiamento)
CBitmapButton Ctor rimosso con 3 params - utilizzare LoadBitmaps (1)
CMDIFrameWnd:: CreateClient Utilizzare OnCreateClient (1)
GetChildFrame Utilizzare MDIGetActive (1)
GetDCOrg Utilizzare le API di Windows direttamente per 3. x (4)
m_pMDIFrameWnd Ora chiamare GetParentFrame O GetMDIFrame (1)

Ragioni per le modifiche:

Errori del compilatore

Maggior parte delle modifiche alle API 2.0 MFC genererà uno dei pochi errori del compilatore o none a tutti se le conversioni di tipo standard conformi al compilatore. Gli errori del compilatore seguenti possono essere generati durante la compilazione di applicazioni MFC 1.0 esistenti sotto MFC 2.0:

Numero Messaggio di errore del compilatore
Errore del compilatore C2039 'Identificatore': non è un membro della classe 'chiave'.
Questo errore è causato quando una funzione membro o membro dati è stato rimosso da una classe, ad esempio CFrameWnddel m_pMDIFrameWnd.
Errore del compilatore C2501 'Identificatore': mancano gli specificatori di decl.
Questo errore è causato quando si utilizza un nome di classe sconosciuto. Questo è solitamente il caso quando la classe non esiste o è stata spostata in un file di intestazione differenti. Per esempio, se viene visualizzato questo errore per CMetaFile e CBitmapButton , allora si deve aggiungere # include "AFXEXT" ai file di origine mediante tali classi.
Errore del compilatore C2248 'Membro' non può accedere al membro 'identificatore' dichiarato nella classe 'classe'.
Questo errore si verifica se l'accesso di un membro ha cambiato da MFC 1.0 a 2. Ad esempio, un'API privi di documenti è stata spostata dal pubblico per l'accesso ai membri protetti . Questo deve verificarsi solo nel codice che utilizza le API non documentate e non supportate, che dovrebbero essere modificate per utilizzare la funzionalità di MFC 2.0 appropriata.
Errore del compilatore C2642 Cast a un puntatore al membro deve essere da puntatore correlati al membro.
Questo errore si verifica quando il prototipo di funzione del gestore di messaggio è diverso da quello di a AFXWIN. h. Ad esempio, una riga che contiene la macro ON_WM_ACTIVATEAPP genererà questo errore se i parametri e il tipo restituito del gestore del messaggio OnActivateApp corrisponde alla dichiarazione di MFC 1.0.
Errore del compilatore C2660 'Funzione': funzione non accetta parametri 'numero'.
Il numero di parametri è cambiato da MFC 1.0 a 2.0 MFC. Ad esempio, la chiamata al costruttore CBitmapButton con tre parametri genera questo errore poiché questo costruttore particolare è stato rimosso e sostituito dalla funzione membro LoadBitmaps.
Errore del compilatore C2664 'Funzione': Impossibile convertire il parametro 'numero' da 'tipo1' a 'tipo2'.
Il tipo di un parametro è cambiato e le conversioni standard non soddisfano il compilatore. CDC::EnumObjects è un esempio di questo. In questo caso, il prototipo della funzione di callback è cambiato.

&Note tecniche per numero |nbsp; Note tecniche per la categoria

Index