Issues Shown by the Migration Tool

To use the migration tool, run the tool against each C file from the C-language version of SHOWDIB. In the Migrating Options dialog box, select Phase 1. Later, you can select each of the other migration phases listed.

For SHOWDIB, run the MFC Migration Tool on the .C files in the SHOWDIB sample directory. Note the issues that the tool points out. This guide will take up most of those issues. The main isssues (corresponding to information in this guide) include:

In Phase 1:

• WinMain is not needed in an MFC application.
• WndProc functions need to move into overrides of the WindowProc member function in your MFC derived view class.
• WM_COMMAND code belongs in an override of the OnCmdMsg member function in your MFC derived view class (and will later be moved into individual message-mapped handler functions).
• WM_PAINT code belongs in an override of the OnDraw member function in your MFC derived view class.
• Disambiguating calls to Windows API functions. The tool flags the names of Windows API functions that MFC encapsulates; you should prefix these with the C++ scope resolution operator (::).
• Calls to DefWindowProc and Other Non-MFC Functions. You don't use DefWindowProc in MFC applications.
• Window registration calls outside WinMain. These need to be checked.

In Phase 2:

• Handler code for other Windows-based messages (such as WM_KEYDOWN) in your switch statement in your WindowProc function override should ultimately move into individual MFC message handler functions. The tool flags WM_ messages.
• Handler code for WM_COMMAND messages in your switch statement in the OnCmdMsg function override should also move into individual MFC message handler functions.
• Using MFC menu update handlers to update the state of your menus and toolbar buttons.
• Replacing your use of cbWndExtra and cbClsExtra in the WNDCLASS structure, along with calls to the SetWindowWord, GetWindowWord, SetWindowLong, GetWindowLong, SetClassWord, GetClassWord, SetClassLong, and GetClassLong functions.

In Phase 3:

• In the long run, you should adopt the MFC way of doing things. This includes transliterating calls to the Windows API functions, including global GDI function calls, to use C++ syntax and MFC, member functions. The tool flags GDI function calls. (The functions flagged for disambiguation in Phase 1 are also prime candidates for conversion to the corresponding MFC functions that encapsulate them.)
• Moving your printing code to MFC. You should consider moving your old print loop code into the MFC view class. The tool flags calls to the StartDoc, StartPage, EndPage, EndDoc, and SetAbortProc functions.
• Using document serialization for input/output. The tool flags calls to the OpenFile, _lread, _lwrite, _lopen, and _lclose functions.