众所周知，当模态窗口被打开之后，正常的流程会暂时挂起，或者通俗一点说，程序停住了，直到模态窗口关闭才会继续执行。例如下面这段代码：
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();iphone5
UpdateData(FALSE);
}
}
这是一段典型的MFC代码，在绝大多数情况下，不会有任何问题。但是由于模态窗口弹出的时候，只是父窗口不能操作，但别的窗口完全还能正常运行，这时候就非常有可能由于某种原因，CTestDlg类已经销毁了，而CInputDialog却不知道，还在继续执行，结果到了IDOK之后，对CTestDialog类的成员变量m_nValue赋值，就会出现崩溃了。EMS
这个问题，如果在多线程的情况下，将会更加严重。因为在多线程的情况下，将会有更加多的不可预料的因素，所以使用的时候要更加小心。