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, который обеспечивает доступ к базе данных. Это намерение этого обновить для покрытия изменения API, которые могут повлиять на существующий код. Сведения об этих новых возможностях, не охвачены в этом технических можно найти в Руководстве Visual C++ программист.

CFrameWnd::RecalcLayout имеет дополнительный параметр, BOOL bNotify. Это определяет ли уведомления любые OLE-серверы, они макет изменилась. Это правда, как правило, и поэтому это значение по умолчанию. Эта функция является виртуальным, поэтому если ваша программа обеспечивает переопределение этой функции вам будет нужно добавить дополнительный параметр в вашей функции.

Там были другие изменения, внесенные недокументированных функций в библиотеках 2,5 MFC для поддержки OLE 2.0, а также ODBC. Если ваша программа использует недокументированные API-интерфейсы MFC, следует провести обзор всех таких видов использования, чтобы убедиться, что они по-прежнему действительны.

Перенос 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:

• Стандартный файл меню и диалоговых интерфейсов. Вы получаете функции такие как стандартный файл открытым и сохранить диалоговых окон, файловый менеджер, drag-and-drop, недавно используется интерфейс меню файл и т. д.
  
  
• Печать. Вы поставляете просмотреть код; Библиотека заботится о получении принтера DC, расклеивание прерывание диалоговое окно выполнение печати цикла и т.д.
  
  
• Предварительный просмотр. Обычно вам будет нужно без дополнительного программирования иметь предварительный просмотр функциональность в вашем приложении.
  
  
• Панели инструментов и строки состояния. Они теперь легко добавлять приложение с помощью Visual C++ и MFC 2.0.
  
  
• Разделитель окна. Если структура вашего кода в представлении классов, то вы сможете отображать их в windows разделителя при очень небольших дополнительных затратах.
  
  
• Поддержка OLE2. Используя архитектуру «Документ/представление» приложение может вероятно OLE без значительное количество работ.

В целом полного переноса метод является в основном подражать разработки приложения MFC 2.0 с нуля, начиная с AppWizard. От разработки приложения MFC 2.0 с нуля, конечно же, разница будет занимать как большую часть кода MFC 1.0, вы написали, как это имеет смысл.

Минимальная миграция

Следующие подразделы представляют подробные правила выполнения минимального миграции.

Соответствии с Windows 3.1 СТРОГИХ определений

По умолчанию строит 2.0 MFC библиотека придерживаться typedefs Windows 3.1 STRICT , которые разъясняются в SDK для Windows 3.1. MFC 1.0 было STRICT выключен, но теперь MFC 2.0 имеет STRICT включается по умолчанию. Это соответствует обязательство MFC для отслеживания отрасли стандарта Windows API и способствовать развитию практики, которые делают разработку надежных приложений проще. Так же, как СТРОГАЯ typedefs были полезны для разработчиков классов MFC 2.0 для создания надежного программного обеспечения, так что будет справедливо для вас в разработке кода вашего приложения.

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

После того, как ваше приложение соответствует STRICT, может появиться возможность компиляции исполняемый файл без дальнейших изменений. К примеру ABOUT2 и FILEVIEW MFC 1.0 образцы компилировать без дополнительных изменений. Они уже были СТРОГИЕ совместимых и сделал не используется изменении любого API-интерфейсов MFC.

Изменяет MFC 2.0 API

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

Из более чем 1800 MFC 1.0 API лишь 20 из API, которые были изменены приводят ошибки времени компиляции. Эти изменения требуют только тривиальные модификации существующих приложений MFC 1.0. Самые обширные изменения являются архитектурной перестройки классов OLE. Эти изменения описаны в технической записке 18.

Чтобы предвидеть, какие изменения вы должны сделать, смотрите раздел «Алфавитном изменения API» в конце этого обновить. Она обеспечивает полезный, краткое резюме, из которых в MFC 2.0 были изменены интерфейсы API 1.0 MFC.

Если вам не все изменения необходимых для решения проблемы кода MFC 2.0, вы получите различные компиляции и компоновки ошибки. Эти ошибки являются почти всегда легко определить. Чтобы упростить свой диагноз, мы предоставляем некоторые рекомендации в разделе «Ошибки компиляции» в конце этого обновить.

В MFC 2.0 были удалены следующие API MFC. Мы рекомендуем альтернативные интерфейсы 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-окна.

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-файлы, ссылающиеся на эти классы:

# include lt;afxext.h>

Многие интерфейсы API были изменены таким образом, чтобы они были более строгие об использовании модификатор «const». Эти изменения приводят более последовательного использования LPCSTR имя типа и имя типа LPCRECT. Обратите внимание, что нет вопроса время компиляции с этими изменениями, так как любой тип может быть повышен до const версии этого типа, когда используется в качестве аргумента. Как изменение STRICT это приводит к более надежный код, когда ваш код использует const указатели данных.

Функции окна Create , перечисленные ниже, теперь имеют дополнительный параметр, но так как последний параметр имеет значение по умолчанию NULL, существующий код будет работать без изменений. Эти функции являются

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

Следующие функции были виртуальный в MFC 1.0, но теперь невиртуальная в MFC 2.0:

• CFile::GetStatus
  
  
• CFrameWnd::GetParentFrame

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

Все статические члены классов, а также глобального оператора/друга функций, в настоящее время придерживаются Паскаль соглашений о вызовах. Все глобальные функции являются AFXAPI (Паскаль). Опять же это не является вопросом времени компиляции, но приводит к более быстрым и более мелкие сгенерированный код.

Многие из реализации только классы и структуры были переименованы не использовать префикс «C». К примеру CExceptionContext был переименован в AFX_EXCEPTION_CONTEXT. Эти классы не документированы и остаются детали реализации библиотеки классов. Маловероятно, что вы полагались на них, и обычно рекомендуется, что вы не полагаться на недокументированные API-интерфейсы библиотеки классов, так как они могут быть изменены в будущих версиях.

MFC 2.0 изменяет поведение по умолчанию

Реагирования на изменения в MFC API легко с помощью ошибок компилятора и компоновщика. Не все изменения библиотеки выявлены в заголовочные файлы библиотеки, однако. Выявлены некоторые изменения в поведение приложения во время выполнения. Эти изменения обычно не трудно заниматься, поскольку вы предвидеть их. Следующая информация поможет предвидеть такие поведенческие изменения.

CDialog и CModalDialog были объединены в один класс. CModalDialog теперь считается устаревшим классом. Однако для совместимости с MFC 1.0, все ссылки на CModalDialog по-прежнему действует до миграции макрос в afxwin.h:

# define CModalDialog CDialog

Для многих приложений MFC 1.0 этот простой # define достаточно. Однако, существуют случаи когда эта # define не достаточно.

Если выполнены немодальное диалоговое окно и полагались на «ничего не делать» поведение по умолчанию для OnOK и OnCancel, то необходимо переопределить эти и поведение по умолчанию, так как они теперь называют EndDialog (для обработки модальное диалоговое окно).

CDialog::CreateIndirect по-прежнему создает немодальное диалоговое окно. Для создания модального диалогового окна использовать CDialog::InitModalIndirect вместо удаленных CModalDialog::CreateIndirect API.

Диалоговое окно box и сообщение цвета фона окна теперь глобально задается с помощью 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, теперь вы получите ошибку ASSERT в 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 явным образом. В противном случае будет автоматически повторно включить меню, которые вы отключите.

Изменения проекта (сборка)

Вы можете продолжать строить приложение MFC 1.0 с помощью стандартного файла makefile. На сегодняшний день самый простой способ для переноса вашего проекта является использование механизма проектов Visual C++ для поддержания вашего depedencies и другие параметры проекта в среде Visual C++.

Распространенная ошибка связи — неразрешенных внешних COMDLG32.DLL и SHELL32.Библиотека DLL для интерфейсов API. Не забудьте связать с COMDLG32.LIB и SHELL32.ЛИБ.

Вы сможете улучшить сборки раз, поместив # включают lt;afxwin.h > в предкомпилированный заголовок. По соглашению MFC 2.0 приложений укажите «stdafx.h» как предкомпилированный заголовок. Затем модуль stdafx.cpp включает stdafx.h. Эта техника иллюстрируется кода, созданного AppWizard и многие из образцов MFC 2.0.

Примечаниеnbsp;  Важно определить ни переопределить любой из _AFX_&NO_XXX макросы в файле stdafx.h. В статье базы знаний "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++ программист.

• Проект должен иметь make-файла с именем lt; проекта > .mak и файл ресурсов с именем <project> .rc, где <project> — имя вашего проекта. Оба эти файла должен быть расположен в корневом каталоге проекта. С.Мак, файл может быть внешнего файла makefile.
  
  
• Запустите ClassWizard из в Visual C++. Когда ClassWizard обнаруживает.КЛИВ файл не существует, он спросит вас, если вы хотите создать его. Ответ «да». С.КЛИВ файл является по существу индексный файл, который 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 и по существу полностью использовать основы. Вы можете «поддельных» документ/представление разделения, осуществляя CDocument- и CView-производных классов, но ваш документ или вид, класс может делегировать большую часть своей работы в другой класс. Или класс представления может полагаться на вашем CFrameWnd- или CMDIChildWnd-производного класса, чтобы реализовать основную часть пользовательского интерфейса вашего приложения. Таким образом у вас есть почти полную свободу как отдельный документ, просматривать и рамка окна классов.

   Также следует определить ваш анализ ли приложению требуется несколько классов представлений и возможно несколько классов документов. Даже относительно простых приложений иногда требуется более одного класса view. Однако, несколько представлений, например, в окно-разделитель, не диктовать обязательно что у вас есть несколько CView-производные классы. Например если каждая область в окне разделителя обеспечивает тот же пользовательский интерфейс, другие области в окне разделителя, то они могут совместно использовать тот же класс представления. В этом случае каждая панель — просто отдельных объект того же класса представления. Вы захотите создать несколько классов представлений, если ваше приложение предоставляет весьма различных пользовательских интерфейсов в различных окнах.

2. Какие возможности поддерживает AppWizard framework необходимо ваше приложение будет анализировать.

   AppWizard будет создан скелет MFC 2.0 приложения, которое поддерживает различные функции framework, выбранные как в 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. Однако если приложению требуется несколько классов представлений, вы вероятно хотите дать первого класса view AppWizard создал более специализированные имя, например CDataEntryView и CReportView. Увидеть следующий шаг для получения дополнительной информации о создании нескольких документов и просмотр классов.

   Какие дополнительные опции AppWizard нужно, такие как SDI или MDI, и OLE, вы теперь сможете выбрать AppWizard параметры и создать общую схему приложения в всего за несколько минут.

4. При необходимости клонировать второе представление, документа и фрейм окна классов.

   Если ваш выше анализа определяет, что приложение должно иметь вид, документа или фрейм окна классов, то это хорошее время для создания «скелет» кода для этих классов справа после запуска AppWizard.

   «Скелет» кода дополнительного представления, документа и рамка окна классов можно создать путем клонирования те, созданный AppWizard. То есть скопируйте файлы .cpp и .h, назначение нового имени модуля для второго документа или класса. Затем измените скелет код, изменив имена классов. Другой альтернативой является использование возможностей добавления класса ClassWizard для создания нового класса автоматически в указанный вами с использованием заданных имен файлов. Вы уже быть знакомы с ClassWizard возможность создания новых классов, если вы следовали SCRIBBLE учебник.

   В любом случае, в вашем 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 Сознающий. Это нормально. Конечно, мы рекомендуем создавать все новые классы диалоговое окно, с помощью параметра Добавление класса ClassWizard в.

   Как перенести приложения MFC 1.0 или Windows, может потребоваться сохранить совместимость с существующими форматами файлов. (Механизм сериализации документа MFC 2.0 по умолчанию может не подходить для приложений.) Направлять CFile писать и читать звонков или для реализации не файл на основе документа, может потребоваться переопределить CDocument::OnOpenDocument и OnSaveDocument. В примере MFC Генеральной DIBLOOK является примером этой техники. Если текущее приложение уже выполняет сериализацию объектов, то это не будет вопросом.

Алфавитный изменения API

Чтобы понять причины таких изменений, обратитесь к «Основания для изменения» ниже.

Причины изменений:

• Улучшить функциональность. Версия MFC 2.0 этот API обеспечивает более или улучшить функциональность над его аналог MFC 1.0.
  
  
• СТРОГАЯ совместимость. MFC 2.0 API было изменено в соответствии с STRICT Windows API.
  
  
• Const корректности. Чтобы правильно применить «const» ключевое слово, чтобы облегчить более надежные программы было зафиксировано MFC 2.0 API.
  
  
• Переносимость Win32. MFC 2.0 API было изменено на правильно отразить Win32 API, который облегчает легко портирование приложений MFC для Win32.
  
  
• Использование снижение памяти. MFC 2.0 API было изменено для обеспечения более эффективной связи и методы использования памяти, что приведет к небольших приложений и сокращение использования DGROUP.
  
  
• Win 3.1 функциональность. MFC 2.0 API было изменено на правильно отражать изменение Windows 3.1 API. API-интерфейс по-прежнему совместим с Windows 3.0, но теперь доступны дополнительные параметры только Windows 3.1.

Ошибки компилятора

Большинство изменений в API-интерфейсов MFC 2.0 создаст одну из нескольких ошибок компилятора, или не на всех, если преобразования стандартных типов удовлетворяют компилятор. Следующие ошибки компилятора может возникать при компиляции существующих приложений MFC 1.0 MFC 2.0:

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