模态对话框可能导致程序崩溃

在开发Windows引用程序的时候，在一些需要用户确认，或者提示用户注意的场合，经常使用模态对话框，或者叫模态窗口。在绝大多数情况下，模态窗口给开发人员带来了极大的便利，并且在某些应用上有不可替代的优势。然而凡事有利必有弊，如果不正确地使用模态窗口，却有可能带来某些严重问题，甚至可能引起程序崩溃。要想知道为什么模态窗口可能带来某些严重问题，就必须首先了解模态窗口的实现原理。因此本文将首先介绍模态窗口实现原理，然后分析为什么会带来问题。

原理

 

知道了原理，一切就可迎刃而解。了解了原理，就可以知道，模态窗口并不是Windows特有的，而是可以在任何一个GUI系统中实现出来，包括手机上。

因为Windows上的模态对话框为众人所知，因此本文的例子都是指Windows上的，并且有时候会特指是MFC的。

众所周知，当模态窗口被打开之后，正常的流程会暂时挂起，或者通俗一点说，程序停住了，直到模态窗口关闭才会继续执行。例如下面这段代码：

CInputDialog  dlg;

if(dlg.DoModal() == IDOK)

{

// 执行按了确定按钮退出的流程

}

else

{

// 执行通过别的方式退出的流程，例如按了取消按钮

}

// 继续执行

在这段代码里，在CInputDialog窗口关闭之前，注释部分的代码是不会得到执行的。

接下来请先思考一个问题，为什么调用了dlg.DoModal()之后，程序会停住呢？

首先，不可能是线程被挂起，因为一般情况，只有一个主线程，如果线程挂起，那就什么也做不了了，但显然模态窗口弹出来之后还是可以做很多事情的。

其次，也不可能是用类似于Sleep之类的函数，让程序等待，和线程挂起一样。

如果我们了解Windows应用程序的运行的原理，了解消息分发的机制，就可以知道，UI线程有一个消息循环，通过GetMessage之类的函数获取消息，并且分发。如果没有这个消息循环，整个窗口系统就无法正常工作。很显然，当有模态窗口打开的时候，整个窗口系统还是正常工作的，因此可以确定，此时消息循环一定还在正常运行着。这个消息循环在哪里呢？因为当模态对窗口弹出来之后，程序就暂停了，相当调用模态窗口的函数一直没有返回，那么也就没有机会再进入缺省消息循环了，这到底是怎么回事呢？福尔摩斯经常说：“除去不可能的剩下的即使再不可能，那也是真相。”基于这个道理，真像只有一个，就是模态窗口内部有一个消息循环，负责消息的接收和转发。

为了证明这个说法，可以做个试验，弹出一个模态对话框，并设置合适的断点，查看堆栈。

使用DialogBox(NULL, MAKEINTRESOURCE(IDD_MAINDLG), m_hWnd, DialogProc);语句弹出对话框，并且在DialogProc里设置一个合适的断点，我们可以在堆栈中看到这样的信息：

         ZK.exe!CMainDlg::DialogProc(HWND__ * hwndDlg=0×000411e0, unsigned int uMsg=0×00000201, unsigned int wParam=0×00000001, long lParam=0×003a009c) 行90 C++

        user32.dll!_InternalCallWinProc@20() + 0×23 字节     

        user32.dll!_UserCallDlgProcCheckWow@32() + 0xa9 字节        

        user32.dll!_DefDlgProcWorker@20() + 0×7f 字节       

        user32.dll!_DefDlgProcW@16() + 0×22 字节        

        user32.dll!_InternalCallWinProc@20() + 0×23 字节     

        user32.dll!_UserCallWinProcCheckWow@32() + 0xb3 字节      

        user32.dll!_DispatchMessageWorker@8() + 0xe6 字节     

        user32.dll!_DispatchMessageW@4() + 0xf 字节 

        user32.dll!_IsDialogMessageW@8() - 0xeaa7 字节 

        user32.dll!_DialogBox2@16() + 0xc0 字节    

        user32.dll!_InternalDialogBox@24() + 0xb6 字节        

        user32.dll!_DialogBoxIndirectParamAorW@24() + 0×36 字节   

        user32.dll!_DialogBoxParamW@20() + 0×3f 字节        

        ZK.exe!CMainDlg::OnOK(unsigned short __formal=0×0000, unsigned short wID=0×0001, unsigned short __formal=0×0000, unsigned short __formal=0×0000) 行98 + 0×1d 字节 C++

上面的堆栈信息中，红色加粗的函数是API函数IsDialogMessage，这个函数的第二个参数是LPMSG lpMsg，这个正是从GetMessage返回的当前消息的结构体。可以想象，在DialogBox函数内部的实现里，在调用IsDialogMessage之前，必定先通过GetMessage之类的函数，从消息队里返回了当前的消息了。

到了这里，我们基本可以确定，在模态窗口内部，也实现了一个消息循环，真是这个消息循环接管了线程中缺省的消息循环，使整个窗口系统能继续正常的工作。同时由于消息循环其实也是一个有退出条件的死循环，因此到这个循环结束之前（一般是关闭了模态窗口），模态窗口后面的代码是不会继续执行的。

理解了模态窗口的原理，就可以在任何支持消息队列的GUI系统中，加入模态窗口的机制，这会减少很多开发工作。例如很多手机平台不支持模态窗口，开发一些需要用户确认的功能就比较麻烦，其实完全可以加入模态窗口，简化开发。

注意事项

模态窗口极大地简化了一些需要和用户交互的操作，好处显而易见。但这里还是要指出一些需要注意的地方，否则使用的时候很可能会出问题。

影响PreTranslateMessage机制

在使用MFC，WTL等进行开发的时候，经常用到PreTranslateMessage机制，这个机制可以让我们在消息被派发之前先做一些事情。很多人以为PreTranslateMessage是Windows本身支持的，其实不然。PreTranslateMessage是MFC和WTL自己引入的一个概念，完全是和Windows无关的。在MFC和WTL的消息循环中，这两个库的设计者在消息分发之前，人为的加了一些代码，使得整个架构支持这一套机制。

正是如此，如果在正常的流程中弹出了模态窗口，就会使正常的PreTranslateMessage机制失效。因为模态窗口中已经包含了一个消息循环，接管了线程中缺省的消息循环。而这个消息循环是在DialogBox这个API函数中执行的，显然不可能再有PreTranalateMessage机制了。

为了解决这一问题，只有让模态窗口也使用和UI线程相同的消息循环，MFC正是这么做的。在MFC中，对话框类的DoModal函数，并不是调用DialogBox函数，而是直接使用CreateWindows创建一个非模态窗口，在窗口创建成功之后再调用MFC自己的消息循环，这样就可以让PreTranslateMessage继续生效。同时在窗口创建出来之后，必须再做一些别的操作，使这个模态窗口的父窗口失效（一般直接把窗口Disable掉）。同时消息循环里有合适的退出条件，并有恢复现场的一些操作，具体可以查看MFC的DoModal函数。

WTL到目前为止，貌似暂时还没有一个合适的方案来解决这个问题。事实上WTL的PreTranslateMessage机制实现的其实是有点问题的，或许以后会在这方面做一定的增强。

可能导致崩溃

这是一个严重问题，在条件合适的情况下，这个崩溃是必然的。

因为模态窗口弹出来之后，模态窗口后面的代码在窗口关闭之前将不会得到执行。然而此时整个窗口是在正常运行的，对于一些极端的情况，是极有可能造成崩溃的。下面看一个例子：

void CTestDlg::OnOK()

{

         CInputDialog dlg;

         If(dlg.DoModal() == IDOK)

         {

                   m_nValue = dlg.GetValue();

                   UpdateData(FALSE);

         }

}

这是一段典型的MFC代码，在绝大多数情况下，不会有任何问题。但是由于模态窗口弹出的时候，只是父窗口不能操作，但别的窗口完全还能正常运行，这时候就非常有可能由于某种原因，CTestDlg类已经销毁了，而CInputDialog却不知道，还在继续执行，结果到了IDOK之后，对CTestDialog类的成员变量m_nValue赋值，就会出现崩溃了。

这个问题，如果在多线程的情况下，将会更加严重。因为在多线程的情况下，将会有更加多的不可预料的因素，所以使用的时候要更加小心。