TN019: Оновлення існуючих додатків MFC MFC 3,0

Це технічні примітки в першу чергу містяться рекомендації щодо перенесення програм MFC 1.0 MFC 2.0 інструменти. Додаткові відмінності між MFC 2.0, 2,5 і 3.0 у першому розділі, нижче наведені.

Змінює MFC 4.0/3.0 API

Немає ніяких відомих змін до документально MFC API, що викличе існуючого коду, вимагати зміни. Є, звичайно, багато додаткових можливостей, які ви можете скористатися. Більш докладну інформацію про ці функції посібнику Visual c + + програміст.

Змінює MFC 2.5 API

MFC 2.5 додані дві основні функції бібліотеки класів: OLE 2.0 підтримки, яка замінила OLE 1.0 підтримки та підтримки ODBC, яка надає доступ до бази даних. Є намір цього technote для покриття змін в API, які можуть вплинути на існуючий код. Відомості про цих нових можливостей, не охоплених в цьому technote див керівництво Visual c + + програміст.

CFrameWnd::RecalcLayout має додатковий параметр, BOOL bNotify. Це визначає, чи слід повідомити будь-які OLE-серверів що вони змінив макет. Це правда, як правило, і тому саме за замовчуванням. Ця функція є віртуальний, так що якщо ваша програма надає заміщення цієї функції потрібно буде додати додатковий параметр для вашого, а також функції.

Там були інші зміни, внесені до недокументованих функцій в бібліотеках MFC 2.5 підтримка OLE 2.0, а також ODBC. Якщо незадокументовані MFC API використовується програмою, слід переглянути всі таке використання, щоб переконатися, що вони все ще діють.

Міграція MFC 1.0 застосункам MFC 2.0

Важливо: Зрозуміти І оцінити два підходи, представлені нижче, ви повинні бути знайомі з MFC 2.0 концепцій, таких як документ і подання архітектури та інструменти. Ми пропонуємо, принаймні роботі через MFC підручник зразок КАРАКУЛІ в навчання перед початком будь-якої міграції існуючого коду.

Існують два основні підходи до перенесення існуючих програм з MFC Версія 1, випустили з Microsoft C7, щоб MFC версії 2.

Мінімальний міграції

За допомогою методу "Мінімальний міграція", зміни лише мінімальний обов'язковий, так що:

• Ваш існуючий MFC 1.0 додаток збирає і успішно посилання з бібліотеками MFC 2.0.
  
  
• Ваші ресурси можуть успішно редагувати за допомогою Visual c + +.
  
  
• Повідомлення обробника функцій і діалогове вікно даних визнані на ClassWizard.

Це найпростіший підхід, але це не використовувати багаті можливості в бібліотеці MFC 2.0. Навіть якщо ви вибрали "Повний міграцію" метод, вам необхідно розуміти і здійснювати техніки з мінімальними міграції.

Повний міграції

Якщо виконувати "Повний міграція", ви можете скористатися повним MFC 2.0 бібліотеки. За допомогою методу мінімальний міграції, ви зможете змінити ваш додаток, за допомогою Visual c + + і ClassWizard. За допомогою методу повний міграції, ви отримуєте такі засоби підтримки MFC 2.0:

• Стандартний файл меню та діалогу користувацьких інтерфейсів. Ви отримаєте функції такі як стандартний файл відкрити і зберегти діалоги, файловий менеджер, перетягнути і падіння, більшість нещодавно використовуваних файлів меню інтерфейсу і так далі.
  
  
• Друк. Ви повідомляєте Переглянути код; Бібліотека піклується про отримання принтер DC, покласти до припинення діалогове вікно запуску друку цикл і так далі.
  
  
• Попередній перегляд. Як правило вам доведеться робити не додаткових кодування мати функціональність попередній перегляд у програмі.
  
  
• Панелі інструментів і статус барів. Вони тепер легко додати до вашого застосування за допомогою Visual c + + і MFC 2.0.
  
  
• Спліттер windows. Якщо вам структурувати код відображення на перегляд класи, то ви зможете у спліттер windows дуже мало додаткових витрат.
  
  
• OLE2 підтримку. Використовуючи "Напрямок" архітектура заявку ймовірно може бути OLE, що дозволило без значну частину роботи.

У цілому повний міграції метод в основному наслідувати розвиваються MFC 2.0 програми з нуля, починаючи з AppWizard. Відмінність від розробки MFC 2.0 програми з нуля, звичайно, є, що буде займати стільки MFC 1.0 коду ви написали, як має сенс.

Мінімальний міграції

Наступні підрозділи представити детальні рекомендації щодо виконання мінімальний міграції.

Відповідність до Windows 3.1 СУВОРОГО typedefs

За замовчуванням будує MFC 2.0 бібліотеки дотримуються Windows 3.1 СТРОГИЙ typedefs, розглянуті в Windows 3.1 SDK. MFC 1.0 була СТРОГИЙ вимкнено, але тепер MFC 2.0 має СТРОГИЙ увімкнуто за промовчанням. Це слід MFC, зобов'язання для відстеження промисловості стандартний Windows API і сприяти розвитку практики, які роблять, що розвиваються надійні програми простіше. Як СТРОГИЙ typedefs були корисні для розробників MFC 2,0 класи для виробництва надійне програмне забезпечення, так що буде істинно для вас у розвитку вашого коду програми.

При використанні СТРОГИЙ типу перевірки в перший раз, багато помилки компіляції зазвичай буде результат. Змінення заявку MFC 1.0, щоб вони відповідали Windows 3.1 СТРОГИЙ typedefs дуже добре може представляти більшу частину ваших зусиль мінімальний міграції.

Як тільки ваша заявка відповідає СТРОГИЙ, можна скласти виконуваний файл без подальших змін. Наприклад, ABOUT2 і FILEVIEW MFC 1.0 зразки скомпілювати без додаткових змін. Вони вже були СТРОГИЙ сумісні і зробив не використовували будь-який змінив MFC API.

Змінює MFC 2.0 API

За межами відповідної СТРОГИЙ, більшість зусилля зробити мінімальний міграції є визначити і змінити ваші програми код відповідати відносно мало змін MFC 2.0 API.

З більш ніж 1800 MFC 1.0 API тільки 20 API, які були змінені результатом помилки компіляції. Ці зміни вимагають тільки тривіальні модифікації існуючих додатків MFC 1.0. Найбільш значні зміни є архітектурні реструктуризації класи OLE. Ці зміни охоплені в технічних Примітка 18.

Щоб передбачити, які зміни ви повинні зробити, див. розділ "Алфавітному API зміни" в кінці цього technote. Вона забезпечує корисні, короткий резюме якого було змінено MFC 1.0 API MFC 2.0.

Якщо ви не роблять всі зміни, які необхідні для вирішення MFC 2.0 код, ви отримаєте різні компіляції та зв'язування помилки. Ці помилки, майже завжди легко для діагностики. Щоб допомогти вашому діагностики, ми надаємо деякі керівні принципи в розділі "Компілятор помилки" в кінці цього technote.

У MFC 2.0 були видалені наступні MFC API. Ми рекомендуємо альтернативні API, де це доречно. Цей список не містить зміни незадокументовані реалізації API.

CDC::GetDCOrg

GetDCOrg недоступна в Win32. Для Windows 3. x тільки додатків, просто зателефонуйте Windows API :: GetDCOrg безпосередньо.

CRuntimeClass::m_pszClassName

Ця змінна членів в даний час, є LPSTR , а не модель пам'яті-залежні (char *). Названий m_lpszClassName у MFC 2.0.

CMDIChildWnd::m_pMDIFrameWnd

У MFC 1.0 ця змінна член вказав батьківського класу в MDIFrame. Ця змінна член була замінена член функція CMDIChildWnd::GetMDIFrame. Якщо ви використовуєте кілька документів інтерфейсу (MDI) у MFC 2.0, більшість використовує CMDIChildWnd::m_pMDIFrameWnd (або GetMDIFrame) більше не є необхідними, оскільки за замовчуванням MDI підтримки ручками всі стандартними командами меню MDI Windows.

CFrameWnd::GetChildFrame

Використання CMDIFrameWnd::MDIGetActive для MDI кадрів замість.

Наступні API пішов у MFC 2.0 для підтримки 1 сумісності, але є застарілою. Її буде видалено з майбутніх версій MFC.

CMDIFrameWnd::CreateClient

Ця функція була замінена більш загальні OnCreateClient механізм, який підтримує створення подання і кращу підтримку MFC 2.0 MDI. Оригінальний CreateClient все ще може використовуватись для MDI додатків, що керувати свої власні MDI кадр меню вікна (за допомогою CMDIFrame::MDISetMenu). Підтримка MFC 2.0 MDI автоматично перейде рядок меню вікна MDI кадру до меню для поточного активного вікна MDI дитини.

Інші зміни, пов'язані з API

Два MFC класи були перенесені з у afxwin.h afxext.h заголовка файлу:

• CBitmapButton
  
  
• CMetaFileDC

У файлах. cpp, які посилаються ці класи додати такі:

# включити lt;afxext.h>

Багато API змінилися так, що вони є більш жорсткими щодо використання 'ХИБНІСТЬ' службову. Ці зміни призвести до більш послідовним використання LPCSTR введіть ім'я і нове ім'я типу LPCRECT. Зверніть увагу, існує не компіляції час питання з цих змін, оскільки будь-який тип може бути підвищений до константа Версія цього типу, коли використовується як аргумент. Як СТРОГИЙ змін це призводить до більш надійні коду, коли ваш код використовується константа даних вказівники.

Функції Створення вікон, перераховані нижче, тепер мати додатковий параметр, але оскільки останній параметр має значення Null, існуючого коду буде працювати без змін. Ці функції

• CWnd::Create
  
  
• CFrameWnd::Create
  
  
• CMDIFrameWnd::Create
  
  
• CMDIChildWnd::Create

Такі функції були віртуальний MFC 1.0, але в даний час nonvirtual в MFC 2.0:

• CFile::GetStatus
  
  
• CFrameWnd::GetParentFrame

Якщо похідного класу заявку MFC 1.0 скасовує будь-який з цих функцій, малоймовірно, що функція похідного класу буде викликатися у MFC 2.0. Крім того, GetParentFrame перенісся з CFrameWnd CWnd , щоб бути цілому корисною API.

Всі члени статичні класи, а також функції глобального оператора/друг, тепер приєднатися до ПАСКАЛЬ погодження. Всі глобальні функції, AFXAPI (PASCAL). Знову ж таки це не є питанням часу компіляції, але призводить до швидше і менше згенерований код.

Багато тільки для реалізації класів і структури були перейменовані не використовувати префікс "С". Наприклад, CExceptionContext було перейменовано на AFX_EXCEPTION_CONTEXT. Ці класи не задокументовані і залишаються деталей реалізації бібліотеки класів. Малоймовірно, що ви покладатися на них, і зазвичай рекомендується, що ви не покладатися на незадокументовані API бібліотеки класів, оскільки вони можуть бути змінені в майбутніх версіях.

Змінює поведінку за промовчанням MFC 2.0

Робота з змін MFC API є легко за допомогою помилки, повідомляє компілятор та компонувальник. Не всі бібліотеки зміни виявлені в бібліотеки файли заголовків, однак. Деякі зміни, виявлені в поведінку під час вашого застосування. Ці зміни, як правило не важко мати справу з, до тих пір, поки ви очікуєте їх. Надано такі відомості допоможуть передбачати такі поведінкові зміни.

CDialog і CModalDialog були об'єднані в одному класі. CModalDialog тепер вважаються застарілими клас. Однак, MFC 1.0 сумісності, всі посилання на CModalDialog , все ще дійсний до макросу міграції в afxwin.h:

# визначити CModalDialog CDialog

Для багатьох додатків, MFC 1.0, визначити цей простий # достатньо. Однак, є випадки, де це # визначити не є достатнім.

Якщо здійснюється немодальною діалогове вікно і покладатися на поведінку за замовчуванням "нічого не" OnOK і OnCancel, то ви маєте обійти правила ці та поведінку за промовчанням, оскільки тепер вони називають EndDialog (для обробки модальне діалогове вікно).

CDialog::CreateIndirect створює-таки немодальною діалогове вікно. Щоб створити модальне діалогове вікно використовувати CDialog::InitModalIndirect , замість того, щоб видалити CModalDialog::CreateIndirect API.

Діалоговому вікні та повідомлення поле фонові кольори можна зараз глобально встановити за допомогою CWinApp::SetDialogBkColor API. За замовчуванням параметр встановлює колір світло-сірий (не COLOR_BTNFACE) виробляти сірий фон. Можна вказати інші кольори.

Якщо SetDialogBkColor не називають у вашому CWinApp-отриманих InitInstance функція, за замовчуванням вікна фоновий колір (встановити в аплет панелі керування "Колір") використовується.

У MFC 1.0 Якщо DLL містить CWinApp об'єкт, було необхідно надати DllMain , яка включала заклик до AfxWinTerm. MFC 2.0 забезпечує цього DllMain, тому будь-які додаткові код включено до вашого DllMain повинні мігрували в DLL CWinApp::ExitInstance функції члена.

CMDIChildWnd::Create тепер правильно використовує параметр dwStyle . Тепер слід указати повний вікно стиль вікна MDI дитини. Якщо вказати dwStyle = 0, тепер ви отримаєте НАДБАННЯ -провал в CMDIChildWnd::PreCreateWindow. Щоб уникнути цього, ви повинні вказати стиль WS_CHILD | WS_VISIBLE | WS_OVERLAPPEDWINDOW бути зворотну сумісність з MFC 1.0.

MFC 2.0 підтримує параметр різні стилі для вікна MDI дитини, так що ви можете видалити деякі елементи керування вікном кадру, при бажанні.

Клас CFrameWnd має новий компонент даних, BOOL CFrameWnd::m_bAutoMenuEnable. Це має значення TRUE, за промовчанням. Це призводить до пунктів меню, що не мають ON_UPDATE_COMMAND_UI або ON_COMMAND обробників автоматично вимикається. Пунктів меню, які мають ON_COMMAND обробників, але не ON_UPDATE_COMMAND_UI обробників, буде автоматично ввімкнуто.

Це робить його легко здійснити додаткові команди на основі поточного виділення. Крім того, це значною мірою зменшує потребу додатків, щоб написати ON_UPDATE_COMMAND_UI обробників для включення/вимикання пунктів меню. Наприклад, застосунок AppWizard генеруються буде мати редагувати вирізати/копіювати/вставити вимкнуто до програміст реалізує обробників для них.

Однак, якщо заявку MFC 1.0 не оновлено для використання ON_COMMAND і ON_UPDATE_COMMAND_UI обробників, потім його потрібно зняти m_bAutoMenuEnable явно. В іншому випадку, меню, які ви вимкніть буде ввімкнення автоматично.

Зміни проекту (Build)

Ви можете продовжувати будувати заявку MFC 1.0, використовуючи стандартні makefile. До цих пір найпростіший спосіб перенесення вашого проекту є використання об'єкті проекту Visual c + + для підтримки вашої depedencies та інші параметри проекту, в середовищі Visual C++.

Поширені помилки посилання є невирішені зовнішності до COMDLG32.Бібліотека DLL і SHELL32.Бібліотека DLL API. Переконайтеся, що посилання з COMDLG32.LIB і SHELL32.LIB.

Ви зможете поліпшити побудувати рази шляхом розміщення # включити lt;afxwin.h > скомпільованого заголовка. За угодою MFC 2.0 додатків вказати "stdafx.h" як скомпільованого заголовку. Виберіть модуль stdafx.cpp містить stdafx.h. Цей метод ілюструється код, створений на AppWizard і багато хто MFC 2.0 зразків.

Приміткаnbsp;  Важливо, що ви не визначити, і будь-який з _AFX_&NO_XXX макросів у stdafx.h undefine. У статті бази знань "PRB: проблеми виникають, коли визначення _AFX_NO_XXX." Ви можете знайти статті бази знань, на компакт-Диску бібліотеки MSDN, або в http://www.microsoft.com/kb/.

Visual c + + і ClassWizard сумісності

Навіть з мінімальними міграції, рекомендується виконати наведені нижче, щоб Visual c + + і ClassWizard можна використовувати для редагування, ресурсів застосунку та код.

• Для будь-якого модуля якого повідомлення карти для редагування з ClassWizard, додайте наступні рядки два коментар у файлі. cpp, поза з будь-якої функції реалізацій:

  //{{AFX_MSG_MAP (lt; ім'я класу >)
  //}}AFX_MSG_MAP
  

  lt; ім'я класу > ім'я вашого класу, яка містить повідомлення карта.

  Так само, додайте такі коментарі два рядки всередині відповідного класу декларації в h-файлу:

  //{{AFX_MSG (lt; ім'я класу >)
  //}}AFX_MSG
  

  Наприклад ці заяви дивитися на той же коментар лінії в будь-якої програми, створені AppWizard. Для пояснення того, що ці коментарі лінії означає, перегляньте MFC: використання MFC вихідних файлів в Visual C++ програміста керівництво.

• Ваш проект повинен мати makefile, названий lt; проекту > .mak і файлу ресурсів, названий <project> .rc, де <project>-це ім'я вашого проекту. Обидва ці файли мають розташовуватися в кореневий каталог проекту. В.Мак файл може бути зовнішніх makefile.
  
  
• Запустити ClassWizard від в Visual C++. Коли ClassWizard виявляє, що є.CLW файл не існує, він запитає вас, якщо ви хочете створити. Відповідь "так". В.CLW файл є по суті файл індексу, які ClassWizard, що використовуються для визначення модулі, що мають такі лінії //{{AFX_MSG коментар.
  
  
• Для будь-якого модуля якого віртуальних функцій, які потрібно редагувати, з ClassWizard, додайте наступні рядки два коментар всередині вашого класу декларації в h-файлу:

   //{{AFX_VIRTUAL (lt; ім'я класу >)
  //}}AFX_VIRTUAL
  

Повний міграції

Повний міграції існуючих c або MFC 1.0 додатка MFC 2.0 запропонує вам всі переваги MFC 2.0. Для більшості застосунків повний міграції не є важким і добре варто витрачених зусиль.

Успішний повний міграції заявки MFC 2.0 вимагає по суті ж розуміння MFC 2.0 як розвиток нових додатки з нуля. Ви повинні ознайомитися з MFC 2.0 бібліотеки класів, Visual c + +, AppWizard і ClassWizard перед початком повний міграції. Ви повинні розуміти, що частини вашого коду програми можуть бути вилучені продиктована MFC 2,0 класи еквівалентні та вдосконалені функції. Не тільки використання більш Бібліотека впровадження зробить ваш вихідний код менші, але це буде зробити ці частини вашого застосування краще інтегрованої з рештою MFC рамках.

Повністю переходу вашу заяву MFC 2.0, ви зможете отримати додаткову функціональність з MFC на відносно невелику додаткових витрат. Наприклад, якщо ваша заявка не було спліттер вікно користувальницький інтерфейс, але один буде корисно для користувачів, потім можна буде швидко додати цю функцію, маючи вже перенесені свій код на MFC 2.0 перегляду документа/архітектура.

Хоча повний перехід на MFC 2.0 може знадобитися кілька днів зусиль для великих програм, сам процес є досить проста. Такі загальні кроки описують процес:

1. Проаналізувати, як існуючі застосування архітектури фактори документа, переглядів і рамка вікна.

   Це слід зробити, перш ніж починати редагувати будь-який код. Багато програмісти, як правило, переплітаються код документа з Переглянути код. Хоча це не обов'язково "погано", поділу документа і зору функціональності є філософія, що MFC рамках схвалює та підтримує особливо добре. Хоча MFC 1.0 не мали CDocument та CView класів, вона також ухвалили документ/вигляд кольороподіл. Так буде всі майбутні версії бібліотеки.

   Вивчення MFC 2.0 зразки, які використовують CDocument і CView класи, особливо MFC підручник зразок КАРАКУЛІ. Потім аналізувати вашу заявку, щоб визначити, що документ і що подання. Визначити, чи вашого застосування кількох типів документів або переглядів.

   Навіть якщо ваша заявка не піддається зніміть документа/вигляд кольороподіл, все одно можна буде повністю міграцію MFC 2.0 і по суті повний скористатися рамках. Ви можете "fake" документ/вигляд кольороподіл шляхом впровадження CDocument- і CView-отриманих класів, але ваш документ або подання, клас може делегувати більшість його робіт для інших класів. Або ваш клас подання може покладатися на CFrameWnd- або CMDIChildWnd-отриманих клас для здійснення більшу частину вашого застосування інтерфейс користувача. Таким чином у вас є майже повну свободу, про те, як окремий документ, перегляд і класи вікон кадру.

   Ваш аналіз також повинна визначити чи вашого застосування декількох класів подання і можливо декілька класів документа. Навіть відносно простий програми іноді потрібно більше одного класу подання. Тим не менше, кілька подань, наприклад, в спліттер вікно, не обов'язково диктувати наявність кількох CView-отриманих класів. Наприклад, якщо кожен області вікна спліттер дає той же користувальницький інтерфейс, як інші областей у вікні спліттер, то вони можуть поділитися одного класу подання. У цьому випадку, кожна область-це просто окремих об'єктів одного класу подання. Ви мабуть, хочуть створити декілька класів подання, якщо ваше додаток забезпечує дуже різні користувацьких інтерфейсів у різних вікнах.

2. Які функції підтримуються AppWizard рамках ваша заявка буде потрібно проаналізувати.

   AppWizard створює скелет MFC 2.0 додатка, який підтримує різні рамках функцій, які було вибрано параметри в діалогових вікнах AppWizard. Перед запуском AppWizard створити скелет додаток, ви повинні спочатку ознайомитися з параметрів, AppWizard надає.

   Потім взяти трохи часу, щоб вирішити, який з AppWizard в параметри, які ви хочете вибрати. Не намагайтеся робити це за лічені хвилини під час першого виконання AppWizard. Наприклад, якщо програма вже не підтримує OLE, це основні рішення, які ви хочете, щоб розглянути. Якщо ви не вибрали параметр OLE AppWizard, почати з, ви, як і раніше, мати можливість змінити ваш коду програми для використання MFC, функції OLE. Але починаючи з параметром OLE в AppWizard почати з заощадить вам час.

   Вашого аналізу слід визначити, чи вашого застосування один документ інтерфейсу (SDI) або декількох документа інтерфейс (MDI) програму. Цього конкретного визначення має бути очевидно, якщо ви знайомі з цих двох окремих інтерфейсів в інших програмах Windows. AppWizard буде створювати MDI програми за промовчанням з інтерфейсу користувача MDI є як правило, більш функціональним для кінцевих користувачів, бо це дозволяє їм відкрити більше, ніж одного файлу документа/одночасно. На щастя, з MFC 2.0 перегляду документа/архітектура, підтримку MDI вимагає не додаткового кодування з вашого боку.

3. Створити новий додаток, за допомогою AppWizard.

   Зробивши наведений вище аналіз, ви зараз можна запускати AppWizard для створення скелет код для вашого застосування.

   Проаналізувавши як розділяє заявку на документ, переглядів і рамка вікна, ви повинні мати гарна ідея що імена, дати їх відповідних класів та модулів. Ви можете призначити кілька загальних імена, такі як підручник зразок CScribDoc і CScribView і scribdoc.cpp і scribvw.cpp. Однак, якщо ваша заявка вимагає декількох подання класи, ви мабуть, хочуть дати перший AppWizard створений подання клас більш спеціалізовані ім'я, наприклад, CDataEntryView і CReportView. Див наступний крок, щоб отримати додаткові відомості про створення декількох документів і перегляду класи.

   Маючи передбачати, що додаткові параметри AppWizard ви хочете, наприклад SDI або MDI, і OLE, тепер можна вибрати параметри AppWizard і створити скелет додатків на кілька хвилин.

4. За потреби можна клонувати другого подання документа та класи вікон кадру.

   Якщо вище аналіз визначає, що ваша заявка повинна мати кілька подання, документ або рамка вікна класи, то це гарний час, щоб створити правильний скелет код для цих класів, після запуску AppWizard.

   Можна створити скелет код для додаткового подання, документів і рамка вікна класи клонування ті, створені AppWizard. Тобто, копіювати. cpp і .h файли, призначення нове ім'я модуля другий документ або клас. Натисніть змінити скелет код, змінивши імена класів. Іншою альтернативою є використання на ClassWizard додати клас функціональність автоматично створити новий клас у файлах, які ви вказуєте, використовуючи імена, які ви вказуєте. Ви вже будуть знайомі з в ClassWizard можливість створювати нові класи, якщо ви дотримувалися ПИСАНИНА підручник.

   У будь-якому випадку, ваші CWinApp, у-отриманих класу в InitInstance функцію, ви повинні зареєструватися, додаткові об'єкти шаблону для будь-яких асоціацій, що ви хочете зробити між вами декілька документів, перегляд і рамка вікна класи.

   Це також швидкий крок. Цей крок може відкласти, якщо ви не прагне реалізації кількох документів, переглядів або рамка вікна класів у вашому додатку.

5. Міграція відповідних частин MFC 1.0 код на класи, створені AppWizard.

   Цей крок являє собою більшу частину роботи при переході заявку MFC 1.0 на MFC 2.0. Ви повинні робити це поступово. Міграція відносно невеликими шматочками заявку в той час. Як ви робите це, ви дізнаєтеся, більш докладної інформації про те, що функціональність в рамках надає, що дозволить вам відмовитися від деяких з вашого старого коду програми MFC 1.0.

   При перенесенні ці шматки коду, майте на увазі, інструкцій, наведених у розділі "Мінімальний міграцію". Багато хто з цих керівних принципів, застосувати до повного міграції. AppWizard буде вже додали //{{AFX_MSG і //{{AFX_MSG_MAP коментарі вашої команди цільової класи (застосунку, документа, вигляд і рамка вікна). Це не є необхідним для ви вручну додати ці під мінімальний міграції підхід. Хоча це не обов'язково, ми рекомендуємо, перемістити функцій обробки повідомлення між //{{AFX_MSG коментарів, вкладених у повідомлення карти. Крім того, переміщення декларації ці функції обробки повідомлення (afx_msg) між заголовні файли, коментарі //{{AFX_MSG. Це дозволить вам використовувати ClassWizard на решті частини вашого проекту life cycle(s).

   Ці рекомендації щодо //{{AFX_MSG коментарі також застосовувати можливо в меншій мірі, щоб діалоги. Якщо ви не очікуєте багато майбутніх змін до даного діалоговому класу, потім він не може бути варто ваші зусилля, щоб зробити що діалоговому ClassWizard-aware. Це добре. Ми рекомендуємо, звичайно, створити всі нові класи діалогове вікно за допомогою параметра Додати клас ClassWizard.

   При перенесенні застосунок MFC 1.0 або Windows, ви можете зберегти сумісність з наявних форматів файлів. (За замовчуванням MFC 2.0 документ серіалізацією механізм може не підходити для вашої програми.) Прямого CFile читати та писати дзвінки або реалізувати non файл на основі документа, вам потрібно буде змінити CDocument::OnOpenDocument і OnSaveDocument. Генеральний MFC зразок DIBLOOK містить приклади цього методу. Якщо ваші поточні програми вже серіалізует об'єкти, то це не буде проблемою.

Алфавітний API зміни

Щоб зрозуміти причини цих змін, зверніться до "Причина для змін" нижче.

Причини змін:

• Поліпшена функціональність. Версія MFC 2.0 цього API забезпечує більше та вдосконалені функції на його колега MFC 1.0.
  
  
• СТРОГИЙ відповідності. MFC 2.0 API була змінена на відповідність СТРОГИЙ Windows API.
  
  
• Константа коректність. MFC 2.0 API була виправлена правильно застосувати 'ХИБНІСТЬ' ключового слова, щоб сприяти більш надійні програми.
  
  
• Win32 переносимості. MFC 2.0 API було змінено належним чином відображають Win32 API, що полегшує легко портування MFC додаткам Win32.
  
  
• Використання обмежених пам'яті. MFC 2.0 API було змінено, щоб забезпечити більш ефективний зв'язок та методи використання пам'яті, який призведе до невеликих додатків і скорочення використання DGROUP.
  
  
• 3.1 Виграти функціональність. MFC 2.0 API було змінено належним чином відображають зміни Windows 3.1 API. API, все ще залишається, сумісною з Windows 3.0, але необов'язково Windows 3.1 тільки параметри тепер доступні.

Компілятор помилки

Більшість змін до MFC 2.0 API буде генерувати один з декількох компілятор помилки або немає взагалі якщо стандартний тип перетворення задовольнити компілятор. Такі помилки компілятор створюються при компіляції існуючі програми MFC 1.0 під MFC 2.0:

Технічні примітки за номером |nbsp; Технічні примітки за категоріями