初始化C++类成员和在你的MFC应用中加入位置栏
个奇怪的特性我应该警告你，它是关于C++初始化类成员的，它们是按照声明的顺序初始化的，而不是按照出现在初始化列表中的顺序。
class CMyClass {
你可能以为上面的代码将会首先做m_y=I，然后做m_x=m_y，最后它们有相同的值。但是编译器先初始化m_x，然后是m_y,，因为它们是按这样的顺序声明的。结果是m_x将有一个不可预测的值。我的例子设计来说明这一点，然而这种bug会更加自然的出现。有两种方法避免它，一个是总是按照你希望它们被初始化的顺序声明成员，第二个是，如果你决定使用初始化列表，总是按照它们声明的顺序罗列这些成员。这将有助于消除混淆。 问题 我刚刚在几台机器上安装了Windows® 2000 Release Candidate 1，不知道怎样在我的MFC应用中得到具有新的Outlook风格栏目的Open对话框（见图1）。
Figure 1 The New Open Dialog 我能否只设置一个标志，或者我是否需要一个新的头文件和一个新的公共对话框的DDL？我注意到一些旧的应用程序如Notepad好像可以得到新的Open对话框而无须重新编译，但它们不是MFC应用。理想情况，我希望在Windows 9x 和Windows NT®下得到一个使用旧对话框的应用，而在Windows 2000下使用新的对话框。 Warren Stevens 回答 这个问题恐怕没有令你高兴的答复。Windows 2000新的Open对话框是用一个新版本的commdlg.dll实现的，它在边上包含“Places”栏目。显示它的函数是GetOpenFileName，与在Windows 9x 和Windows NT®下使用的相同。然而，GetOpenFileName现在使用一个新版本的OPENFILENAME，这是一个在你的应用和对话框之间传递信息的结构。新的结构有一些额外的成员： typedef struct tagOFN {
对，是这样。Windows 2000是Windows的第5个版本，用16进制表示是0x500。如果你用_WIN32_WINNT = 0x0500编译程序，OPENFILENAME就会得到3个新成员。前两个是保留的，第三个标志域，FlagsEx，有一个新的OFN_EX_NOPLACESBAR栏目，它屏蔽了Places栏目。Windows——或者更准确的说，commdlg.dll——使用OPENFILENAME第一个成员lStructSize来决定显示那个对话框，如果lStructSize是76（旧的大小），Windows就运行旧的对话框；如果是76+3´4=88（新的大小），它就运行新的对话框——这是友好的Redmondtonians最初告诉我的。在我的研究中间，我发现这并不是完整的图画。 但是在我详细说明之前，先让我们走马观花的看一下MFC，讨论另外一个问题。在MFC应用中，你并不经常直接调用GetOpenFileName，而是使用CfileDialog——或者，框架使用CfileDialog。当用户调用File | Open，控制稀里哗啦的一路经过CWinApp::OnFileOpen和几个其它的函数，最终到达CDocManager::DoPromptFileName，这个函数创建一个CfileDialog。CfileDialog具有一个OPENFILENAME结构的数据成员： class CFileDialog : public CCommonDialog {
这个结构的大小是当友好的Redmondtonians 编译MFC42.DLL 时OPENFILENAME的大小；换句话说，旧的大小。而且，如果你正在进行一个静态连接，MFC代码在MFC42.DLL或NAFXCW.LIB里是冻结的，你不能仅仅设置m_ofn.lStructSize为新的大小，因为CfileDi |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
