模态窗口原理及注意事项

前言

在开发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=0x000411e0, unsigned int uMsg=0x00000201, unsigned int wParam=0x00000001, long lParam=0x003a009c) 行90    C++

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

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

    user32.dll!_DefDlgProcWorker@20() + 0x7f 字节    

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

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

    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() + 0x36 字节    

    user32.dll!_DialogBoxParamW@20() + 0x3f 字节    

    ZK.exe!CMainDlg::OnOK(unsigned short __formal=0x0000, unsigned short wID=0x0001, unsigned short __formal=0x0000, unsigned short __formal=0x0000) 行98 + 0x1d 字节    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赋值,就会出现崩溃了。

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

 

发布了9 篇原创文章 · 获赞 0 · 访问量 4万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览