Ta Uwaga techniczna przede wszystkim zawiera wytyczne dotyczące migracji aplikacji MFC 1.0 narzędzia MFC 2.0. Dodatkowe różnice między MFC 2.0, 2.5 i 3.0 są prezentowane w pierwszej sekcji poniżej.
Zmienia MFC 4.0/3.0 API
Istnieją żadnych znanych zmian udokumentowanych interfejsów API MFC, które mogłyby spowodować istniejącego kodu wymaga zmiany. Oczywiście istnieje wiele dodatkowych funkcji można wykorzystać. Aby uzyskać więcej informacji dotyczących tych funkcji zobacz Visual C++ Programmer's Guide.
Zmienia MFC 2.5 API
Do biblioteki klas MFC 2.5 dodaje dwa główne cechy: OLE 2.0 wsparcia, które otrzymuje wsparcie OLE 1.0 i wsparcie ODBC, który zapewnia dostęp do bazy danych. To jest zamiar ten technote na pokrycie zmian interfejsu API, które mogą mieć wpływ na istniejący kod. Aby uzyskać informacje dotyczące tych nowych funkcji, nie objęte tym technote zobacz Visual C++ Programmer's Guide.
CFrameWnd::RecalcLayout ma dodatkowy parametr, BOOL bNotify. Określa, czy ich nie zgłaszać wszelkie serwery OLE że układ został zmieniony. Zwykle dotyczy to i dlatego jest domyślnie. Ta funkcja jest wirtualna, więc jeśli Twój program dostarcza przesłonięcie tej funkcji trzeba będzie dodać dodatkowy parametr do funkcji jak również.
Istniały inne zmiany nieudokumentowane funkcji biblioteki MFC 2.5 do obsługi OLE 2.0, a także ODBC. Jeśli Twój program używa nieudokumentowane API MFC, powinna dokonać przeglądu wszystkich takich zastosowań, aby upewnić się, że są one nadal ważne.
Migrowanie MFC 1.0 aplikacji MFC 2.0
Ważne: Do zrozumienia i oceny dwóch podejść przedstawionych poniżej, użytkownik musi być zaznajomiony z koncepcji MFC 2.0, takich jak architektura dokumentu i widoku i narzędzi. Sugerujemy, co najmniej pracy poprzez przykładowy samouczek MFC BAZGROŁY w samouczki przed rozpoczęciem każdej migracji istniejącego kodu.
Istnieją dwa podstawowe podejścia do migracji istniejących aplikacji z MFC wersja 1, wydany z C7 firmy Microsoft, aby MFC w wersji 2.
Minimalne migracji
Za pomocą metody "Minimalne migracji", dokonać tylko zmiany minimalnej wymaganej, tak aby:
Jest to najłatwiejsza metoda, ale nie ma pełne korzystanie z bogatych funkcji biblioteki MFC 2.0. Nawet wtedy, gdy wybrano metodę "Pełnej migracji", należy zrozumieć i wykonywania techniki minimalne migracji.
Pełnej migracji
Jeśli wykonasz "Pełnej migracji", można wykonać pełne wykorzystanie biblioteki MFC 2.0. Za pomocą metody minimalny migracji będzie za możliwość edycji aplikacji przy użyciu języka Visual C++ i ClassWizard. Za pomocą metody pełnej migracji, można uzyskać obsługę MFC 2.0:
Metoda ogólnie pełnej migracji jest zasadniczo do emulowania tworzenia aplikacji MFC 2.0 od podstaw, począwszy od AppWizard. Różnica rozwoju aplikacji MFC 2.0 od podstaw, jest oczywiście, że będzie pożyczać tyle Kodeksu MFC 1.0, który napisał w sens.
Minimalne migracji
Poniższe podpunkty przedstawić szczegółowe wytyczne dotyczące minimalnej migracji.
Zgodnych z systemu Windows 3.1 ŚCISŁE definicje TypeDef
Domyślnie tworzy 2.0 MFC biblioteki przylegają do Windows 3.1 ŚCISŁE definicje TypeDef, które są wyjaśnione w Windows 3.1 SDK. MFC 1.0 zawierał ŚCISŁE wyłączony, ale teraz MFC 2.0 istnieje ŚCISŁE domyślnie włączona. Wynika to zobowiązanie MFC firmy śledzenie przemysłu Standardowy Windows API oraz wspierania rozwoju praktyk, które rozwijanie niezawodnych aplikacji łatwiejsze. Podobnie, jak ŚCISŁE definicje TypeDef były przydatne deweloperom klas MFC 2.0 produkować oprogramowanie, tak że będą spełnione przy opracowywaniu kodu aplikacji.
Korzystając z typu ŚCISŁE sprawdzanie po raz pierwszy, zazwyczaj rezultatem będzie wiele błędów kompilacji. Modyfikowanie aplikacji MFC 1.0 są zgodne z systemu Windows 3.1 ŚCISŁE definicje TypeDef może bardzo dobrze stanowi zasadniczą część nakładu minimalne migracji.
Gdy aplikacja jest zgodny z STRICT, można skompilować plik wykonywalny z żadnych dalszych zmian. Na przykład ABOUT2 i FILEVIEW MFC 1.0 próbki skompilować bez żadnych dodatkowych zmian. Zostały one już ŚCISŁE zgodny z i czy nie używane wszelkich zmieniane API MFC.
Zmienia MFC 2.0 interfejsu API
Poza odpowiadające STRICT, większość wysiłków takie minimalne migracji jest określenie i zmiany kodu aplikacji są zgodne z stosunkowo niewiele zmian MFC 2.0 interfejsu API.
Z ponad 1800 MFC interfejsów API 1.0 zaledwie 20 interfejsów API, które zostały zmienione powodują błędy w czasie kompilowania. Zmiany te wymagają jedynie trywialny modyfikacji istniejących aplikacji MFC 1.0. Najbardziej rozległe zmiany są, architektoniczne restrukturyzacji klasy OLE. Zmiany te są objęte technicznych przypis 18.
Do przewidywania, które zmiany potrzebne dokonania, zobacz sekcję "Alfabetyczna API Changes" na końcu tego technote. Zapewnia ona użyteczna, krótkie podsumowanie, którego MFC 1.0 API zostały zmodyfikowane w MFC 2.0.
Jeśli nie wszystkie zmiany konieczne radzić sobie z kodu MFC 2.0, otrzymasz różnych kompilacji i łączenia błędy. Te błędy są prawie zawsze ułatwia diagnozowanie. Do pomocy z diagnostyki, oferujemy kilka wskazówek w sekcji „Błędy kompilatora"na końcu tego technote.
Następujące API MFC zostały usunięte z MFC 2.0. Firma Microsoft zaleca alternatywne interfejsy API, w przypadku gdy jest to właściwe. Lista ta nie obejmuje zmian nieudokumentowane wdrożenie API.
CDC::GetDCOrg
GetDCOrg nie jest dostępny w Win32. Dla aplikacji tylko od systemu Windows 3.x, po prostu wywołanie interfejsu API systemu Windows :: GetDCOrg bezpośrednio.
CRuntimeClass::m_pszClassName
Ta zmienna Państwa jest teraz LPSTR , zamiast zależne modelu pamięci char ***. Został nazwany m_lpszClassName 2.0 MFC.
CMDIChildWnd::m_pMDIFrameWnd
W MFC 1.0 zmienna ta Członkowskie wskazywanego klasy MDIFrame nadrzędnej. Ta zmienna Państwa została zastąpiona funkcją Państwa CMDIChildWnd::GetMDIFrame. Jeśli używasz wielu interfejsu dokumentu (MDI) 2.0 MFC, większość zastosowań CMDIChildWnd::m_pMDIFrameWnd (lub GetMDIFrame) już są konieczne, ponieważ obsługa MDI domyślny obsługuje wszystkie standardowe polecenia menu MDI Windows.
CFrameWnd::GetChildFrame
Zamiast tego użyj CMDIFrameWnd::MDIGetActive MDI ramek.
Następujący interfejs API pozostawiono w MFC 2.0 do wspierania zgodności 1, ale jest przestarzała. Zostanie ono usunięte z przyszłych wersji MFC.
CMDIFrameWnd::CreateClient
Ta funkcja został zastąpiony bardziej ogólny mechanizm OnCreateClient , który obsługuje tworzenie widoku i ulepszoną obsługę MFC 2.0 MDI. Oryginalna CreateClient mogą nadal używane dla aplikacji MDI, które zarządzają pasek menu własne MDI okno ramek (przy użyciu CMDIFrame::MDISetMenu). Obsługa MFC 2.0 MDI zostanie automatycznie przełączona pasek menu okna MDI ramki do menu dla aktualnie aktywne okno potomne MDI.
Inne zmiany dotyczące interfejsu API
Dwóch klas MFC zostały przeniesione z afxwin.h do pliku nagłówkowego afxext.h:
W plikach .cpp, które odwołują się do tych klas należy dodać następujący:
# include lt;afxext.h>
Wiele interfejsów API zostały zmienione tak, że są one bardziej rygorystyczne o używaniu modyfikator "stała". Zmiany te skutkują bardziej spójne stosowanie nazwy typu LPCSTR i nową nazwę typu LPCRECT. Uwaga: istnieje żadna kwestia czasu kompilacji z tych zmian, ponieważ dowolnego typu można promować stała wersji tego rodzaju używanego jako argumentu. Jak zmiana STRICT prowadzi to do bardziej niezawodny kod po kodzie używa stała wskaźników danych.
Funkcji Utwórz okno wymienionych poniżej teraz ma dodatkowy parametr, ale ponieważ ostatni parametr ma domyślną wartość NULL, istniejącego kodu będzie działać bez żadnych modyfikacji. Te funkcje są
Następujące funkcje zostały wirtualnych w MFC 1.0, ale są obecnie niewirtualna MFC 2.0:
Jeśli pochodna klasy Aplikacja MFC 1.0 zastępuje jedną z tych funkcji, jest mało prawdopodobne, że funkcji w klasie pochodnej zostanie wywołana w MFC 2.0. Ponadto GetParentFrame została przeniesiona z CFrameWnd do CWnd do bardziej ogólnie użyteczne API.
Wszystkie elementy statyczne klasy, jak również funkcje globalne operatora/przyjaciel, teraz przestrzegać PASCAL Konwencje wywoływania połączeń. Wszystkie funkcje globalne są AFXAPI (PASCAL). Ponownie to nie jest kwestią czasu kompilacji, ale prowadzi do szybszego i mniejszych wygenerowany kod.
Wiele klas tylko do wykonania i struktur zostały przemianowane na nie używać prefiksu 'C'. Na przykład CExceptionContext została zmieniona na AFX_EXCEPTION_CONTEXT. Klasy te nie są udokumentowane i pozostają szczegóły implementacyjne biblioteki klas. Jest mało prawdopodobne, że było polegać na nich, i ogólnie zalecane jest, że użytkownik nie polegać na nieudokumentowane API biblioteki klas ponieważ są one mogą zostać zmienione w przyszłych wersjach.
Zmienia domyślne zachowanie MFC 2.0
Zajmowanie się zmiany MFC API jest proste dzięki pomocy błędy raportowane przez kompilator i linker. Nie wszystkie zmiany biblioteki są wykrywane w pliki nagłówkowe biblioteki, jednak. Niektóre zmiany są wykrywane w zachowanie uruchomieniową aplikacji. Zmiany te są ogólnie nie trudne do rozwiązania, tak długo, jak długo przewidujesz je. Następujące informacje są przekazywane pomóc przewidzieć takie zmiany funkcjonalne.
CDialog i CModalDialog zostały scalone w jedną klasę. CModalDialog jest teraz uważana za przestarzałe klasy. Jednakże dla MFC 1.0 zgodności, wszystkie odniesienia do CModalDialog są nadal ważne przez makro migracji w afxwin.h:
# define CModalDialog CDialog
W wielu aplikacjach MFC 1.0, to proste # define jest wystarczająca. Jednakże istnieją przypadki, gdzie to # define nie jest wystarczające,.
Jeśli wprowadzone niemodalny okno dialogowe i opierała się na domyślne zachowanie "do nothing" OnOK i OnCancel, następnie należy zastąpić te i zachowanie domyślne, ponieważ obecnie wywołują EndDialog (dla przetwarzania modalnym).
CDialog::CreateIndirect tworzy nadal niemodalny okna dialogowego. Aby utworzyć modalnym należy CDialog::InitModalIndirect zamiast usuniętego CModalDialog::CreateIndirect API.
Okno dialogowe pole i wiadomości pole tła kolorów można teraz globalnie ustawić przy użyciu CWinApp::SetDialogBkColor interfejsu API. Domyślny parametr ustawia kolor jasnoszare (nie COLOR_BTNFACE) produkować szare tła. Można określić inne kolory.
Jeśli SetDialogBkColor nie jest wywoływana w Twojej CWinApp-pochodnych InitInstance funkcji, domyślne tło okna kolorów (zestaw w aplecie Control Panel kolor) jest używany.
W MFC 1.0 Jeśli biblioteka DLL zawierał obiekt CWinApp , konieczne było zapewnienie DllMain , oferującą wywołanie AfxWinTerm. MFC 2.0 zapewnia to DllMain, tak aby dodatkowy kod zawarty w sieci DllMain powinny być migrowane do bibliotek DLL CWinApp::ExitInstance Członkowskie funkcji.
CMDIChildWnd::Create teraz poprawnie użyto parametru dwStyle . Teraz należy określić styl pełne okno okno potomne MDI. Jeśli określisz dwStyle = 0, teraz otrzymasz błąd ASSERT w CMDIChildWnd::PreCreateWindow. Aby tego uniknąć, należy określić styl WS_CHILD | WS_VISIBLE | WS_OVERLAPPEDWINDOW za zgodny wstecz z MFC 1.0.
MFC 2.0 obsługuje ustawienie różnych stylów dla okien podrzędnych MDI, więc można usunąć niektóre formanty okna ramki, w razie potrzeby.
Klasa CFrameWnd zawiera nowy członek danych, BOOL CFrameWnd::m_bAutoMenuEnable. Jest ustawiona na wartość TRUE domyślnie. Powoduje to, że elementy menu, które nie zostały ON_UPDATE_COMMAND_UI lub ON_COMMAND obsługi do automatycznie wyłączone. Elementy menu, które mają ON_COMMAND obsługi, ale nie obsługi ON_UPDATE_COMMAND_UI zostaną automatycznie włączone.
Ułatwia to wdrożyć opcjonalny poleceń, w oparciu o bieżące zaznaczenie. Ponadto to znacznie zmniejsza potrzebę aplikacji do napisania ON_UPDATE_COMMAND_UI obsługi na włączanie i wyłączanie elementów menu. Na przykład aplikacja generowanych przez AppWizard będzie edytować Wytnij/Kopiuj/Wklej wyłączona do czasu programator implementuje obsługi dla nich.
Jednakże jeżeli aplikacji MFC 1.0 nie jest aktualizowany do używania ON_COMMAND i obsługi ON_UPDATE_COMMAND_UI , następnie muszą jasno m_bAutoMenuEnable jawnie. Tymczasowo włączyć inaczej, menu, które można wyłączyć będzie ponownie automatycznie.
Zmiany projektu (kompilacja)
Można kontynuować budowanie aplikacji MFC 1.0 przy użyciu standardowego pliku makefile. Zdecydowanie Najprostszym sposobem Migrowanie projektu jest użycie instrumentu projektu Visual C++ utrzymać swój depedencies i inne opcje Projekt w środowisku Visual C++.
Typowym błędem łącze jest nierozwiązanych obiektów zewnętrznych do COMDLG32.Biblioteka DLL i pliku Shell32.dll.Biblioteka DLL interfejsów API. Należy się upewnić, że łącza z COMDLG32.LIB i pliku Shell32.dll.BIBLIOTEKA.
Można poprawić kompilacji razy umieszczając # obejmują lt;afxwin.h > w nagłówku wstępnie skompilowana. Przez Konwencję MFC 2.0 aplikacjach określenie "stdafx.h" w nagłówku wstępnie skompilowana. Następnie stdafx.cpp moduł obejmuje stdafx.h. Ta technika jest zilustrowane kod utworzony przez AppWizard i wiele próbek MFC 2.0.
Uwaganbsp; &Należy pamiętać, że można zdefiniować ani nie zdefiniowany z makra _AFX_NO_XXX w stdafx.h. Zobacz artykuł bazy wiedzy Knowledge Base "PRB: wystąpić problemy przy definiowaniu _AFX_NO_XXX." Artykuły bazy wiedzy Knowledge Base można znaleźć na dysku CD z biblioteki MSDN lub na http://www.microsoft.com/kb/.
Visual C++ i zgodności ClassWizard
Nawet przy minimalnym migracji, zalecamy, wykonaj poniższe kroki, aby mogli używać języka Visual C++ i ClassWizard, aby edytować zasoby aplikacji i kod.
//{{AFX_MSG_MAP (lt; Nazwa klasy >)
//}}AFX_MSG_MAP
lt; Nazwa klasy > jest nazwą klasy zawierający mapę wiadomości.
Podobnie Dodaj poniższe wiersze komentarza dwóch wewnątrz deklaracji odpowiedniej klasy w pliku .h:
//{{AFX_MSG (lt; Nazwa klasy >)
//}}AFX_MSG
Przykład deklaracje te wyglądają na tych samych liniach komentarza w dowolnej aplikacji utworzony przez AppWizard. O wyjaśnienie, jakie te wiersze komentarza oznacza, zobacz MFC: przy użyciu pliki źródłowe MFC w Visual C++ Programmer's Guide.
//{{AFX_VIRTUAL (lt; Nazwa klasy >)
//}}AFX_VIRTUAL
Pełnej migracji
Pełnej migracji istniejących aplikacji c lub MFC 1.0 MFC 2.0 oferuje wszystkie zalety MFC 2.0. Dla większości aplikacji pełnej migracji nie jest trudne i jest warte wysiłek.
Pomyślne pełnej migracji aplikacji MFC 2.0 wymaga zasadniczo takie same zrozumienia MFC 2.0 jak rozwijanie nowej aplikacji od podstaw. Stawali użytkownik znanych z biblioteki klas MFC 2.0, Visual C++, AppWizard i ClassWizard przed rozpoczęciem pełnej migracji. Należy zrozumieć, co to fragmenty kodu aplikacji mogą być usuwane przez równoważne lub ulepszone funkcje z klas MFC 2.0. Nie tylko będą za pomocą więcej realizacji biblioteki kodu źródłowego mniejsze, ale wprowadzi te części aplikacji lepiej zintegrowany z pozostałej części ramy MFC.
W pełni migrowanie aplikacji MFC 2.0, będzie generować dodatkowe funkcje z MFC na stosunkowo niewiele dodatkowych kosztów. Na przykład jeżeli aplikacji nie interfejsu użytkownika okno rozdzielacza, ale jeden byłoby przydatne dla użytkowników, następnie będzie można szybko dodać tę funkcję, posiadające już przeniesiona kodu MFC 2.0 widok i dokumentu architektury.
Chociaż pełnej migracji MFC 2.0 mogą wymagać parę dni wysiłków dla dużych aplikacji, sam proces jest dość oczywiste. Następujące ogólne kroki opisują proces:
To pole wyboru należy zrobić, przed rozpoczęciem edycji dowolnego kodu. Wielu programistów mają tendencję do intertwine kodu dokument w widoku Kod. Chociaż robić tak nie jest koniecznie "bad", filozofią projektowania, ramy MFC popiera i obsługuje szczególnie dobrze jest oddzielenie funkcji dokumentu i widok. Mimo że MFC 1.0 nie klasy CDocument i CView , również zatwierdziła separacji widok i dokumentów. Tak będzie wszystkie przyszłe wersje biblioteki.
Badanie próbki MFC 2.0, które za pomocą klasy CDocument i CView , szczególnie przykładowy samouczek MFC BAZGROŁY. Następnie analizować aplikację, aby określić, co dokument jest i co to jest widok. Określić, czy aplikacja ma wiele typów dokumentów lub widoków.
Nawet jeżeli aplikacji nie udzielać sobie wyczyść separacji widok i dokumentów, wciąż będzie mógł w pełni migracji do usługi MFC 2.0 i zasadniczo pełne wykorzystanie ram. Użytkownik może "fake" separacji widok i dokumentów poprzez wdrożenie CDocument- i CView-pochodnych klas, ale dokument lub widoku klasy może przekazać większość jego prac do innej klasy. Lub klasy widok może polegać na CFrameWnd- lub CMDIChildWnd-klasy do wdrożenia luzem interfejsu użytkownika aplikacji. Podsumowując istnieje prawie pełną swobodę jak dokument, widok i ramki okna klasy.
Analiz także powinny ustalić czy aplikacja wymaga wiele klas widoku i ewentualnie wiele klas dokumentów. Nawet stosunkowo prostych aplikacji muszą czasami więcej niż jednej klasy widoku. Jednakże wiele widoków, tak jak w oknie podziału, nie koniecznie dyktować mają wiele CView-klasom pochodnym. Na przykład jeśli każdy okienka w oknie podziału zapewnia tego samego interfejsu użytkownika jako innych okienek w oknie rozdzielacza, następnie mogą dzielić tej samej klasy widoku. W takim przypadku każde okienko jest po prostu odrębne obiektów tej samej klasy widoku. Prawdopodobnie należy zaprojektować wiele klas widoku, jeżeli aplikacji udostępnia interfejsy użytkownika bardzo różne w różnych oknach.
AppWizard spowoduje utworzenie szkielet aplikacji MFC 2.0, który obsługuje różne funkcje ramy, które wybierzesz jako opcji w oknach dialogowych AppWizard. Przed uruchomieniem AppWizard aby utworzyć szkielet aplikacji, najpierw stawali użytkownik znanych z opcjami, które zapewnia AppWizard.
Następnie zająć trochę czasu zdecydować, który AppWizard z opcji trzeba będzie wybrać. Nie próbować wykonać w kilka minut można uruchomić AppWizard po raz pierwszy. Na przykład jeśli aplikacja nie obsługuje już OLE, jest to ważnej decyzji, które warto wziąć pod uwagę. Jeśli nie wybrano opcję OLE AppWizard firmy, aby rozpocząć z, nadal będziesz mógł modyfikować kodu aplikacji do korzystania z funkcji OLE MFC firmy. Jednak począwszy od opcji OLE w AppWizard na początek będziesz musiał tracić czasu.
Analizę należy określić, czy aplikacja jest interfejsem jednolitego dokumentu (SDI) lub wielu aplikacji interfejsu (MDI) dokumentu. To szczególne ustalenia powinny być oczywiste, jeśli znasz się te dwa interfejsy użytkownika odrębne w innych aplikacjach systemu Windows. AppWizard spowoduje utworzenie MDI aplikacji domyślnie ponieważ interfejs użytkownika MDI jest zazwyczaj bardziej funkcjonalny użytkownikom końcowym pozwala je otwórz, więcej niż jednego dokumentu i plików naraz. Na szczęście architektura widok i dokumentu MFC 2.0, wspieranie MDI wymaga nie dodatkowych kodowania ze strony.
Dołożenie powyższą analizę, możesz teraz uruchomić AppWizard aby utworzyć szkielet kod aplikacji.
Po analizie, jak aplikacja oddziela dokument, widoki i ramka okna, należy mieć dobrze jakie nazwy do ich odpowiednich klas i moduły. Może chcesz przypisać nazwy nieco ogólne, takie jak przykładowy samouczek CScribDoc i CScribView oraz scribdoc.cpp i scribvw.cpp. Jednakże jeżeli aplikacji wymaga wiele klas widoku, można prawdopodobnie będą udzielenia pierwszej klasy AppWizard utworzony widok nazwę bardziej specjalistycznych, takich jak CDataEntryView i CReportView. Zobacz następny krok aby uzyskać dodatkowe informacje dotyczące tworzenia wiele klas dokumentu i widok.
O przewidywanych jakie dodatkowe opcje AppWizard chcesz, takich jak SDI lub MDI, i OLE, należy teraz można wybrać opcje AppWizard i utworzyć szkielet wniosku w ciągu kilku minut.
Jeśli powyższa analiza określa, że aplikacja powinna mieć wiele widoku, dokument lub ramki okna klasy, następnie jest odpowiednim czasie utworzyć szkielet kod klasy te prawa, po uruchomieniu AppWizard.
Można utworzyć szkielet kod dodatkowy widok, dokument i ramki okna klasy klonowanie ones, utworzony przez AppWizard. Oznacza to, że skopiuj pliki .cpp i .h, przypisywanie nową nazwę modułu dla drugiego dokumentu lub klasy. Następnie edytować kod szkielet, zmieniając nazwy klas. Innym alternatywą jest używanie funkcji Dodaj klasy ClassWizard aby automatycznie utworzyć nową klasę w plików, które można określić przy użyciu nazwy, którą należy określić. Już będzie zaznajomiony z ClassWizard zdolność do tworzenia nowych klas, jeśli po wykonaniu samouczek BAZGROŁY.
W każdym przypadku, w Twojej CWinApp-pochodnych klasy InitInstance funkcji, musisz zarejestrować obiekty szablonu dodatkowego dokumentu dla wszelkich stowarzyszeń, które chcesz wprowadzić między użytkownikiem wielu dokumentów, widok i ramki okna klasy.
Jest to również quick step. Można odroczyć ten krok, jeśli nie jesteś zaangażowane we wdrażanie wielu dokumentów, widoków lub ramki okna klasy w aplikacji.
Ten krok stanowi większość pracy migracji aplikacji MFC 1.0, 2.0 MFC. Należy to stopniowo. Migrowanie stosunkowo małe kawałki aplikacji jednocześnie. Jak to dowiesz się więcej szczegółów na temat jakie aspekty funkcjonalności ramach przewiduje, że umożliwi to odrzucić niektóre starego kodu aplikacji MFC 1.0.
Jak można migrować tych fragmentów kodu, należy pamiętać, wytyczne przedstawione w ramach "Minimalnych migracji". Wiele z tych wytycznych stosuje się do pełnej migracji. AppWizard będzie już dodane komentarze //{{AFX_MSG i //{{AFX_MSG_MAP do klasy docelowej polecenia (aplikacji, dokumentu, widok i okno ramek). Jest ona nie niezbędne dla można ręcznie dodać te zgodnie z podejściem minimalne migracji. Chociaż nie jest to wymagane, zaleca się przenieść funkcje obsługi wiadomości między komentarzami //{{AFX_MSG, zagnieżdżone w mapach wiadomości. Również przenoszenia deklaracje te funkcje obsługi wiadomości (afx_msg) między komentarzami //{{AFX_MSG w plikach nagłówka. Czyniąc pozwoli na używanie ClassWizard w pozostałej części projektu life cycle(s).
Te zalecenia dotyczące uwag //{{AFX_MSG również dotyczyć, prawdopodobnie mniejszym stopniu do okien dialogowych. Jeśli przewidujesz nie wielu zmianach klasy danego okna dialogowego w przyszłości, następnie może być warte Twoich wysiłków, aby dokonać tego okna dialogowego ClassWizard-aware. To świetnie. Zalecić musimy oczywiście tworzenie wszystkich nowych klas okno dialogowe za pomocą ClassWizard przez dodać klasę opcji.
Jak migrowanie aplikacji MFC 1.0 lub systemu Windows może chcesz zachować zgodność z istniejącymi formatów plików. (Mogą być nie właściwe dla aplikacji mechanizm serializacji domyślne MFC 2.0 dokumentu.) Do bezpośredniego CFile zapisywania i odczytywania wywołań lub do wykonania innych niż plik na dokument, trzeba zastąpić CDocument::OnOpenDocument i OnSaveDocument. Próbki ogólnej MFC DIBLOOK stanowi przykład tej techniki. Jeżeli aplikacji bieżącej już szereguje obiekty, a następnie nie będzie problemu.
Alfabetyczne zmiany API
Aby zrozumieć powody tych zmian, przeczytaj "Powód dla zmiany" poniżej.
| Interfejs API zmiennej | MFC 2.0 zmienić (powód zmiany) |
| CMetaFileDC::Close | Zwracany typ (2) |
| CWnd::Create | Domyślnie dodatkowych parametrów dodane, CWnd * stała (1, 3) |
| CFrameWnd::Create | Domyślnie dodatkowych parametrów dodane, CWnd * stała (1, 3) |
| CMDIChildWnd::Create | Domyślnie dodatkowych parametrów dodane, CWnd * stała (1, 3) nbsp; dwStyle domyślną jest obecnie: WS_CHILD | WS_VISIBLE | WS_OVERLAPPEDWI&NDOW |
| CWnd::CreateEx | Domyślnie dodatkowych parametrów dodane, CWnd * stała (1, 3) |
| CBitmap::CreateBitmap | Typy parametrów (4) |
| CDC::EnumObjects | Prototyp wywołania zwrotnego (2) |
| CTime::Format | Funkcja stała (3) |
| CTimeSpan::Format | Funkcja stała (3) |
| CTime::FormatGmt | Funkcja stała (3) |
| CFile::GetStatus | Nonvirtual (5) |
| CDC::GrayString | Wywołania zwrotnego prototyp i parametr typu (2) |
| CBitmapButton::LoadBitmaps | Dodatkowe domyślny parametr (1) |
| CWnd::OnActivateApp | Typ parametru (2) |
| CWnd::OnCompareItem | Dodatkowy parametr (6) |
| CWnd::OnDeleteItem | Dodatkowy parametr (6) |
| CWnd::OnDrawItem | Dodatkowy parametr (6) |
| CWnd::OnDropFiles | Typ parametru (2) |
| CWnd::OnGetMinMaxInfo | Typ parametru (6) |
| CWnd::OnMeasureItem | Dodatkowy parametr (6) |
| CWnd::OnMenuChar | Zwracany typ (2) |
| CWnd::OnNcCalcSize | Dodatkowy parametr (6) |
| CWnd::OnPaintClipboard | Typ parametru (2) |
| CWnd::OnParentNotify | Typ parametru (2) |
| CWnd::OnSizeClipboard | Typ parametru (2) |
| CWnd::OnSysCommand | Typ parametru (2) |
| CWnd::OnWinIniChange | Typ parametru (2) |
| CDC::PlayMetaFile | Typ parametru (2) |
| CEdit::SetSel | Dodatkowe domyślny parametr (6) |
| CEdit::SetTabStops | Typ parametru (5) |
| CWnd::SetTimer | Wywołania zwrotnego prototyp i parametr typu (2) |
| CRuntimeClass::m_pszClassName | Przemianowany na m_lpszClassName (5) |
| Usuniętych lub przestarzałe API | MFC 2.0 zmienić (powód zmiany) |
| CBitmapButton | Usunięto ctor z 3 params - użyj LoadBitmaps (1) |
| CMDIFrameWnd:: CreateClient | Użyj OnCreateClient (1) |
| GetChildFrame | Użyj MDIGetActive (1) |
| GetDCOrg | Użyj interfejsu API systemu Windows bezpośrednio do 3.x (4) |
| m_pMDIFrameWnd | Teraz wywołania GetParentFrame lub GetMDIFrame (1) |
Powody zmiany:
Błędy kompilatora
Większość zmian API 2.0 MFC generują jedną z kilku błędy kompilatora lub brak w ogóle standardowy typ konwersji spełniają kompilator. Następujące błędy kompilatora mogą być generowane podczas kompilowania istniejących aplikacji MFC 1.0 pod MFC 2.0:
| Numer | Komunikat o błędzie kompilatora |
| Błąd kompilatora C2039 | "Identyfikator": nie jest członkiem "klucz klasy." |
| Ten błąd jest spowodowany podczas funkcji członek lub członek danych została usunięta z klasy, na przykład CFrameWnd m_pMDIFrameWnd. | |
| Błąd kompilatora C2501 | "Identyfikator": brak decl specyfikatory. |
| Ten błąd jest spowodowany podczas korzystania z nazwą klasy nieznane. Zwykle jest to sprawy, gdy klasa już istnieje lub został przeniesiony do pliku inny nagłówek. Na przykład jeżeli otrzymasz ten błąd CMetaFile i CBitmapButton , wówczas użytkownik musi dodać # include "afxext.h" dla plików źródłowych, przy użyciu tych klas. | |
| Błąd kompilatora C2248 | "Członek" nie może uzyskać dostęp do "określenie" członek zadeklarowana w klasie „"class". ” |
| Ten błąd występuje, jeśli dostęp członka zmienił się z MFC 1.0 do 2. Na przykład nieudokumentowane API została przeniesiona z publicznych chronione Członkowskich dostępu. To powinno nastąpić jedynie w kodzie, który używa nieudokumentowane i nieobsługiwane interfejsów API, która powinna być obniżona do odpowiednich funkcji MFC 2.0. | |
| Błąd kompilatora C2642 | Oddanych do wskaźnika do Państwa muszą być z powiązanych wskaźnik do członka. |
| Ten błąd występuje, gdy prototypów funkcji obsługi wiadomości różni się od w afxwin.h. Na przykład wiersz zawierający makra ON_WM_ACTIVATEAPP będzie emituje ten błąd, jeśli parametry i zwracany typ sieci obsługi wiadomości OnActivateApp odpowiada deklaracji MFC 1.0. | |
| Błąd kompilatora C2660 | "Funkcja": funkcja nie ma parametrów "numer". |
| Liczba parametrów zmienił się z MFC 1.0, 2.0 MFC. Na przykład wywołanie konstruktora CBitmapButton z trzema parametrami powoduje ten błąd, ponieważ to szczególne konstruktora została usunięta i zastąpiona przez funkcję Państwa LoadBitmaps. | |
| Błąd kompilatora C2664 | 'Funkcja': nie można konwertować parametru "numer" z 'type1' do "type2." |
| Typ parametru uległa zmianie i konwersji standardowych nie spełniają kompilator. Przykładem tego jest CDC::EnumObjects . W tym przypadku zmienił się prototypów funkcji wywołania zwrotnego. |
Uwagi techniczne przez liczbę |nbsp; Uwagi techniczne według kategorii