网学之家(5588net.com) - 执着关注互联网技术!

网学之家|5588net.com

当前位置: 主页 > 程序开发 > VC >

INFO: MFC 3.x转换为4.0的常见问题

来源:www.5588net.com 作者:网学之家 时间:2014-04-06 点击:

本文适用于:

包含于: - Microsoft Visual C++, 32-bit Edition, versions 4.0, 4.1, 4.2, 5.0 的微软基本类库(Microsoft Foundation Classes,MFC)。

概述:

本文列举了当你想把用MFC 3.x(这个MFC包含在Visual C++ 2.x中)编写的应用程序port为利用MFC 4.0(这个MFC包含在Visual C++ 4.0)工作时,最常遇到的一些bug问题,和其他问题。

一般问题

1.MFC不再预先注册Window 类。

在4.0以前的版本中,MFC预先注册了四个窗口类(WNDCLASS),正如MFC Technical Note number 1中所说明的那样。这些窗口类是AfxWnd, AfxFrameOrView, AfxMDIFrame,和AfxControlBar。大多数防止产生一个应用程序的多个实例的代码(如ONETIME样本)都依赖于这些类。现在,在4.0版本中,在创建相应类型的窗口之前,这些类是不会被注册的。如果MFC追踪功能被打开,GetLastError会将值0x57F (ERROR_WNDCLASS_DOES_NOT_EXIST)返回到调试输出窗口。基于一个自定义WNDCLASS(填满来自MFC窗口类的信息)的窗口可能会不能显示和发送窗口创建失败的消息。

从4.0版本开始,当用RegisterClass 或AfxRegisterClass注册窗口类时,你需要提供所有必要的信息。不要靠::GetClassInfo去找回MFC窗口类的类值。

如果要知道更多的信息,请看MFC Technical Note 1和下列Microsoft Knowledge Base中的文章。

ARTICLE-ID: Q140596

TITLE: MFC 4.0 No Longer Pre-Registers Window Classes

ARTICLE-ID: Q141752

TITLE: SAMPLE: Limiting 32-bit Applications to a Single Instance

2.BUG: CFormView上的第一个控件,在OnInitialUpdate执行之前获得OnSetFocus。

如果在OnSetFocus中有涉及到直到调用基本类OnInitDialog 时才被子类化的CWnd对象的代码时,就会发生问题。当任何其他句柄作为获得焦点的控件结果被调用时,也会发生这一问题。例如,当单选按钮获得焦点时,会产生一个BN_CLIKED。如果想得到其他信息和工作区,请看下列Microsoft Knowledge Base中的文章:

ARTICLE-ID: Q142274

TITLE: FIX: Assertion Failure When Handling xN_SETFOCUS in

CFormView

 

3.CWinApp::m_templateList不在存在了:

CWinApp 的m_templateList成员变量在4.0版本以前的MFC中并没有说明,但却经常使用,被称为porting issue。微软建议使用GetFirstDocTemplatePosition()和GetNextDocTemplate()成员函数访问应用程序的模板。

要想得到更多的信息,请看下列Microsoft Knowledge Base中的文章:

ARTICLE-ID: Q106455

TITLE: How to Acquire a List of All CDocument Objects

 

4.BUG:CString +=操作符可能被空字符串中断。

导致这一bug的特定事件序列是复杂的。在MFC源代码中有一个bug,当+=操作符使用一个空字符串时,它不能作出正确地处理。

要想得到更多的信息,请看下列Microsoft Knowledge Base中的文章:

ARTICLE-ID: Q142385

TITLE: FIX: Using CString::operator+= May Cause an Access Violation

5.BUG:当滚动条被编程滚动时,WM_xSCROLL 消息的OnWndMsg事件中断。

在MFC 4.0中加入了新的代码,用于将完整的32位地址(如果有)传送到OnxScroll句柄,因为WM_xSCROLL消息只能打包16位的地址信息。不幸的是,不论什么时候只要应用程序用SendMessage向自己发送一个WM_xSCROLL消息来编程滚动滚动条,新加入的代码就会中断。

要想得到更多的信息,请看下列Microsoft Knowledge Base中的文章:

ARTICLE-ID: Q147684

TITLE: FIX: Sending WM_xSCROLL Message Causes Invalid ASSERT

6.BUG:现在OnInitMenuPopup在返回前删除菜单临时 map。

在4.0版的MFC中,在CWnd::OnInitMenuPopup中加入了对AfxLockTempMaps和AfxUnlockTempMaps的调用。当调用AfxUnlockTempMaps时,MFC的临时对象映射引用计数器将变为零,使得所有的临时MFC对象都被删除。当对OnInitMenuPopup的调用返回时,被传送到OnInitMenuPopup 的CMenu指针(这是一个临时指针)将是无效的。

要想得到更多的信息,请看下列Microsoft Knowledge Base中的文章:

ARTICLE-ID: Q141532

TITLE: FIX: OnInitMenuPopup Deletes Temporary Objects

7.文档化的CRuntimeClass::m_pfnConstructObject现在是m_pfnCreateObject.

在4.0版以前的MFC中,m_pfnConstructObject是CRuntimeClass的一个文档化成员变量,但现在为了反映参数和返回值的改变,名字也相应作了更改。包含在Visual C++ 4.0中的文档并没有进行相应的更新,错误地引用了旧的函数名。

8.BUG:缺省的基于对话框的应用程序在Win32s中不工作。

当AppWizard产生一个基于对话框的应用程序时,它为主对话框使用一个DIALOGEX资源。但是,Win32s不支持DIALOGEX资源。结果,在Win32s中,对话框看起来有点不对。通过从对话框编辑器中去掉WS_EX_APPWINDOW类型和在.rc文件中将DIALOGEX声明改为DIALOG声明,可以对这个问题进行修正。

要想得到更多的信息,请看Visual C++ Readme文件和下列Microsoft Knowledge Base中的文章:

ARTICLE-ID: Q138971

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

CPropertySheet

现在,许多CPropertySheet的MFC实现已经被更改用来包装Windows Property Sheet通用控件。格式和尺寸上有一些改变,但更重要的是,如果代码使用了CPropertySheet的任何私有MFC实现,当类的大多数未文档化成员不在那时,代码就会中断。

9.CPropertySheet总是将它的字体变为缺省字体。

即使在资源编辑器中改变了属性页的字体,在运行时属性页也会以系统字体显示。如果有必要改变字体,在OnInitDialog中调用SetFont();然后使用合适的MoveWindow()调整页的大小并移动,调整页上所有控件的大小。还有,无论什么时候,当一个页被激活时,属性也就会恢复到原来的大小,因此,有必要调整页的大小以响应标签控件上的单击。

要想得到更多的信息,请看下列Microsoft Knowledge Base中的文章:

ARTICLE-ID: Q142170

TITLE: SAMPLE: PRPFONT - How to Set CPropertySheet Fonts

10.调用一个基本类后应该修改OnInitDialog中的属性页。

在CPropertySheet::OnInitDialog期间,属性页的大小被调整,四个标准按钮(OK, Cancel, Apply, 和 Help)被隐藏在非模态属性页的底部。调用基本类以后在OnInitDialog中修改页的大小或定制用户化的四个属性页按钮是合适的。在以前版本的MFC中,在OnCreate中隐藏一些模态属性页显示的按钮是很平常的事。现在,通过在PROPSHEETHEADER 结构 CPropertySheet::m_psh中修改类型,可以很容易地去掉这些按钮。

要想得到更多的信息,请看下列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

11.在Windows 95,CPropertySheet::DoModal()导致一个first chance异常。

因为属性页设置需要对话框资源中的类型,在Windows 95上将发生一个first chance异常,。操作系统需要对此进行控制,因此消息可能被忽略。如果你用一个try/catch(...)块把DoModal()调用包起来,企图自己解决异常,那么你会得到一个堆栈错误。

 

 

12.现在属性页有一个最小化的宽度。

CPropertySheet窗口的最小化宽度是四个按钮的大小,这四个按钮将会沿着一个模态属性页的底部向上显示。这一宽度甚至也应用于非模态属性页,在这种属性页中并不沿着底部显示四个按钮。

DLLs

13.在DLL启动期间,不能创建MFC线程。

尽管不是一个好办法,在以前版本的MFC中,在MFC DLL启动期间创建一个线程是可能的。这包括在DLLMain,DLL中的RawDllMain,InitInstance或任何被他们调用的函数中调用AfxBeginThread 或 CWinThread::CreateThread。由于MFC线程启动代码的同步及DLL RPOCESS ATTACH和DLL THREAD ATTACH期间在DllMain的阻塞,将不再允许这样做。 。当被应用程序调用的MFC 4.0 DLLS试图这样做时,将会被挂起。

要想得到更多的信息,请看下列Microsoft Knowledge Base中的文章:

ARTICLE-ID: Q142243

TITLE: PRB: Cannot Create an MFC Thread During DLL Startup

14.使用共享库中MFC的正常DLLs,在输出函数中需要AFX_MODULE_STATE。

以前,USRDLL模型要求MFC静态地链接到DLL。现在从一个正常(Regular)DLL(_USRDLLs的新概念)动态链接到Mfc40.dll是可能的。值得注意的是,为了将一个_USRDLL转化为一个“使用共享库中MFC的正常DLL”,你要确保正确地管理模块状态信息。下面一行代码:

AFX_MANAGE_STATE(AfxGetStaticModuleState());

应该被加到任何从操作MFC对象的DLL输出的函数的开始部分。

如果没有适当地转变模块状态,就可能发生下列问题:

由于丢失资源,在一个DLL中创建对话框和窗口时失败。
调用错误应用程序对象,导致堆栈溢出或不可预知的结果。
不可知的运行时间类信息.
Bad window-to-MFC 对象处理映射连接.
要想得到更多的信息,请看MFC Technical Note 58 (TN058)和下列Microsoft Knowledge Base中的文章:

ARTICLE-ID: Q140850

TITLE: How to Convert DLLTRACE to Use MFC in Shared Library

15.BUG:DoModal可能在MFC扩展DLLs中失败。

当MFC 4.0创建一个对话框时,它将当前实例的句柄传递给::CreateDialogIndirect Windows API椪飧?/FONT>API为DLL产生对话框而不是资源句柄。MFC已经从正确的扩展DLL装入了对话框的模板。但是,Windows将会在实例句柄指定的.exe 文件中寻找任何模板上指示的其他资源。如果他们在DLL中, Windows将找不到他们,对话框的创建将会失败。为解决这个问题,应该在任何对DoModal的调用之前,转换当前实例的句柄。其他资源包括对话框菜单,自定义控件,或对话框上的图标。

要想得到更多的信息,请看下列Microsoft Knowledge Base中的文章:

ARTICLE-ID: Q147384

TITLE: FIX: Icons, Bitmaps, & Menus Not Displayed in an AFXDLL

Dialog

16.CStatusBar和CToolBar

像CPropertySheet一样,这些类现在也是用来包装Win32通用控件功能的。依赖或修改这些类的私有非文档实现的代码,在为MFC 4.0编译时,都可能中断。这两个通用控件比以前的缺省MFC实现支持更大范围的通用定制,而且它们不通过重要的覆盖MFC 源就能完成诸如创建调色板条或制作调整大小的工具条之类的工作。如果需要,这两个类的旧的作为COldToolBar和COldStatusBar类的实现仍然可用。这些实现可以在OLDBARS样本对象中找到。

17.CToolbar::SetSizes和按钮的尺寸设置

现在,工具条要求按钮的宽度至少比图像的尺寸大7个像素。Visual C++ 4.0中的文档没有做相应的更新,是错误的。MFC version 4.0用来检验SetSizes中正确参数的ASSERT也不是原来的6。还有关于工具条,按钮,和图像尺寸的一些其他限制,但是这些限制已经被MFC源中的ASSERT声明包括了并且从MFC 3.x以来一直没有改变。

要想得到更多的信息,请看下列Microsoft Knowledge Base中的文章:

ARTICLE-ID: Q141444

TITLE: DOC: Incorrect Documentation for CToolBar::SetSizes()

CFileDialog

18.不需要替换MFC提供的CFileDialog 钩子(hook)过程。

MFC总是在CFileDialog对象构建期间为Open File Dialog指定自己的钩子过程(_AfxCommDlgProc),使它能将对话框的通知正确地发送到正确的句柄。对于MFC 4.x,这个hook过程用来将CFileDialog对象的子类到Open File Dialog窗口。如果钩子过程被替换了,这个子类过程不会发生,因此任何使用CFileDialog或嵌在它上面的控件变量(如果它是一个窗口)的企图都将失败。

19.CFileDialog总是浏览器对话框窗口的产物。

当你使用浏览器风格的CFileDialog(在Windows 95中,缺省情况就是这样)时,MFC采用用户化的浏览器模型。这意味着,对File对话框的定制改进,被包含在一个分离的模板上,这个模板被加到标准浏览器对话框周围。在MFC 4.0中,实际的CFileDialog窗口是主文件共用对话框的一个子对话框,即使你没有提供一个模板来用户化这个对话框。因此,如果你需要通过移动或隐藏控件来改变标准浏览器接口,就要在所有对Explorer控件的GetDlgItem()调用的前面加上GetParent()作为前缀。例如,表达式:

GetParent()->GetDlgItem(IDOK)

将返回一个指向浏览器对话框中Open/Save按钮的指针。然而,并不建议这样做,因为如果将来浏览器的设计改变了,那些依赖标准浏览器对话框控件详细资料的代码将会中断。

可以通过去掉OFN_EXPLORER类型改变缺省设置。

要想得到更多的信息,请看下列Microsoft Knowledge Base文章:

ARTICLE-ID: Q131225

TITLE: PRB: CFileDialog::DoModal() Does Not Display FileOpen Dialog

19.CFileDialog的成员函数GetFileName和GetFileTitle互相颠倒了。

在MFC4.0中,对于文件C:\Article.txt:

CFileDialog::GetFileName返回Article.txt。

CFileDialog::GetFileTitle返回Article。

以前版本的MFC返回的正好相反。这些函数已经变为以和同名Win32 API函数相似的方法工作。然而,包含在Visual C++ 4.0中的文档并没有做相应的更新,是错误的。

要想得到更多的信息,请看Visual C++ Readme文件和下列Microsoft Knowledge Base中的文章。

ARTICLE-ID: Q142203

TITLE: DOCERR: GetFileTitle() & GetFileName() Docs Are Switched

MFC ODBC

20.BUG:带CLongBinary域的Dynasets抛出异常。

使用带CLongBinary-bound域的dynaset recordsets 的MFC ODBC应用程序能在Visual C++ 2.x中工作,但现在Visual C++ 4.0中,当打开recordset时,它抛出一个异常。该异常是从CRecordset::InitRecord抛出的.

要想得到更多的信息,请看下面Microsoft Knowledge Base中的文章:

ARTICLE-ID: Q141303

TITLE: FIX: Dynasets w/ CLongBinary Fields Throws Incorrect

Exception

MFC OLE

21.不再有Mfcans32.dll,因此MFC应用程序中的OLE函数需要Unicode变量。

在MFC 3.x中,当调用OLE接口时,使用一个特殊的DLL(Mfcans32.dll)在Unicode和MBCS之间自动转换。MFC 4.0并不使用这个DLL;而是直接和Unicode OLE接口对话。为了处理这一改变,现在MFC应用程序必须向OLE函数传送参数的正确类型棗不管是Unicode还是MBCS。MFC 4.0已经提供了许多宏,以使这一工作更容易。

为了得到更多的信息,请看MFC Technical Note 59。

参考文献

你可以在Visual C++ CD-ROM的如下目录中找到Visual C++ InfoView中的参考MFC Technical Notes:

Visual C++ Books

MFC 4.0

MFC Technical Notes

Visual C++ Readme可以在\Msdev\Vcread.wri文件中找到,或在以下的Visual C++ InfoView中:

README for Microsoft Visual C++ Version 4.0

Microsoft Foundation Classes (MFC)"

顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
验证码: 点击我更换图片