INFO: Frequently Encountered MFC 3.x to 4.0 Porting Issues

This causes problems if there is code in OnSetFocus that refers to CWnd objects that won't be subclassed until the call to the base class OnInitDialog. This problem may also occur in any other handler called as a result of the control getting the focus. For example, radio buttons will generate a BN_CLICKED when they get the focus.

For additional information and a workaround, please see the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q142274
   TITLE     : FIX: Assertion Failure When Handling xN_SETFOCUS in
               CFormView

The m_templateList member variable of CWinApp was undocumented in MFC versions prior to 4.0 but was used frequently enough to be called a porting issue. Microsoft recommends that you use the GetFirstDocTemplatePosition() and GetNextDocTemplate() member functions of CWinApp to gain access to the templates for an application.

For additional information, please see the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q106455
   TITLE     : How to Acquire a List of All CDocument Objects

The particular sequence of events that result in this bug is complex. There is a bug in the MFC source code that incorrectly handles the case when a null string is used with the += operator.

For additional information, please see the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q142385
   TITLE     : FIX: Using CString::operator+= May Cause an Access Violation

Code was added in MFC 4.0 to pass the full 32 bits of position (when available) on to the OnxScroll handlers because the WM_xSCROLL messages can only pack 16 bits of position information. Unfortunately the code that was added breaks whenever an application programmatically scrolls a scroll bar by sending a WM_xSCROLL message to itself by way of SendMessage.

For additional information, please see the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q147684
   TITLE     : FIX: Sending WM_xSCROLL Message Causes Invalid ASSERT

In MFC version 4.0, calls to AfxLockTempMaps and AfxUnlockTempMaps were added to CWnd::OnInitMenuPopup. When AfxUnlockTempMaps is called, MFC's temporary object map reference count will go to zero causing all temporary MFC objects to be deleted. When the call to OnInitMenuPopup returns, the CMenu pointer passed in to OnInitMenuPopup (which is a temporary pointer) will be invalid.

For additional information, please see the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q141532
   TITLE     : FIX: OnInitMenuPopup Deletes Temporary Objects

m_pfnConstructObject was a documented member variable of CRuntimeClass in MFC versions prior to 4.0, but the name was changed to reflect the change in parameters and return value. The documentation included with Visual C++ 4.0 was not updated to reflect this change and incorrectly references the old function name.

1. BUG: Default dialog-based application doesn't work in Win32s:

For additional information, please see the Visual C++ Readme file and the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q138971
   TITLE     : BUG: Default Dialog-Based Application Doesn't Work in Win32s

CPropertySheet

Much of the MFC implementation of CPropertySheet has changed to now wrap the Windows Property Sheet common control. There have been some formatting and sizing changes, but more importantly, if code made use of any of the private MFC implementations of CPropertySheet, the code will likely break as most of the undocumented members of that class are no longer there.

1. CPropertySheet always changes its font to the default font:

For additional information, please see the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q142170
   TITLE     : SAMPLE: PRPFONT - How to Set CPropertySheet Fonts

During CPropertySheet::OnInitDialog, the property sheet is resized and the four standard buttons (OK, Cancel, Apply, and Help) are hidden at the bottom of modeless property sheets. The proper place to modify the size of the sheet or to customize the four property sheet buttons is in OnInitDialog after the call to the base class. In previous versions of MFC, it was common practice to hide some of the buttons shown with a modal property sheet in OnCreate. These buttons can now be easily removed by modifying styles in the PROPSHEETHEADER structure CPropertySheet::m_psh.

For additional information, please see the following articles in the Microsoft Knowledge Base:

   ARTICLE-ID: Q140585
   TITLE     : PRB: Resizing CPropertySheet in OnInitDialog Does Not Work

   ARTICLE-ID: Q141039
   TITLE     : How to Hide the Apply Button in CPropertySheet

A first chance exception occurs on Windows 95 because the property page sets required styles in the dialog resource. The operating system needs to handle this, so the message can be ignored. If you surround the DoModal() call with a try/catch(...) block in an effort to handle the exception yourself, you will get a stack fault.

1. Property Sheets now have a minimum width:

DLLs

1. MFC threads cannot be created during DLL startup:

For additional information, please see the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q142243
   TITLE     : PRB: Cannot Create an MFC Thread During DLL Startup

Previously, the USRDLL model required that MFC be statically linked to the DLL. It is now possible to link dynamically to the Mfc40.dll from a Regular DLL (the new term for _USRDLLs). The caveat is that to convert a _USRDLL to be a "Regular DLL using MFC in a Shared Library," you need to make sure that you manage your module state information correctly. The single line:

   AFX_MANAGE_STATE(AfxGetStaticModuleState());

The following problems are likely to occur if the module state is not switched appropriately:

• Dialogs and windows fail at creation in a DLL because of missing resources.
• Functions for the wrong application object are called and cause stack overflow or unpredictable results.
• Unrecognized run-time class information.
• Bad window-to-MFC object handle map linkage.

   ARTICLE-ID: Q140850
   TITLE     : How to Convert DLLTRACE to Use MFC in Shared Library

When MFC 4.0 creates a dialog box, it passes the current instance handle to the ::CreateDialogIndirect Windows API - which creates the dialog instead of the resource handle for the DLL. The template for the dialog was already loaded by MFC from the correct extension DLL. However, Windows will look in the .exe file specified by the instance handle for any extra resources indicated on the template. Windows will not find them if they are in the DLL, and the dialog creation will fail. To work around this problem, the current instance handle should be temporarily switched before any calls to DoModal. Extra resources include such things as the dialog's menu, custom controls, or an icon on the dialog.

For additional information, please see the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q147384
   TITLE     : FIX: Icons, Bitmaps, & Menus Not Displayed in an AFXDLL
               Dialog

CStatusBar and CToolBar

Like CPropertySheet, these MFC classes now wrap the functionality of the Win32 common controls. Any code that relied on or modified the private, undocumented implementation of these classes will likely break when compiled for MFC 4.0. These two common controls support a greater range of common customizations than did the previous default MFC implementation, and they do not require significant overrides of the MFC source for such tasks as constructing palette bars or making resizable toolbars. If needed, the old implementation of these two classes is still present as the COldToolBar and COldStatusBar classes. These implementations can be found in the OLDBARS sample project.

1. CToolbar::SetSizes and button sizing:

For additional information, please see the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q141444
   TITLE     : DOC: Incorrect Documentation for CToolBar::SetSizes()

CFileDialog

1. No need to replace the MFC-supplied CFileDialog hook procedure:

1. CFileDialog is always a child of the Explorer dialog window:

   GetParent()->GetDlgItem(IDOK)

This default can be changed by removing the OFN_EXPLORER style. For more information, see the following Microsoft Knowledge Base article:

   ARTICLE-ID: Q131225
   TITLE     : PRB: CFileDialog::DoModal() Does Not Display FileOpen Dialog