LockWindowUpdate系列4：什么样的操作中不应当使用LockWindowUpdate？

最新推荐文章于 2024-05-07 15:05:53 发布

BalonFan

最新推荐文章于 2024-05-07 15:05:53 发布

阅读量4k

点赞数

分类专栏：技术文章标签： windows 编程 null 工作

技术专栏收录该内容

25 篇文章 0 订阅

订阅专栏

那么，现在我们已经知道了什么样的操作中应当使用LockWindowUpdate ，现在我们来看一下人们在一些与拖拽无关的工作中错误使用这个函数的方式。

人们看到LockWindowUpdate“锁定的窗口将不能绘制自己”的行为，就用它来作为 WM_SETREDRAW 消息的偷懒的使用方式，尽管发送一个WM_SETREDRAW消息不不比调用LockWindowUpdate更麻烦。只是多打20来个字符，而且如果使用<windows.h>中的SetWindowRedraw宏的话还少会一半。

不使用	LockWindowUpdate(hwnd)
代而使用	SendMessage(hwnd, WM_SETREDRAW, FALSE, 0) or SetWindowRedraw(hwnd, FALSE)

不使用	LockWindowUpdate(NULL)
代而使用	SendMessage(hwnd, WM_SETREDRAW, TRUE, 0) or SetWindowRedraw(hwnd, TRUE)

就像我们在前面所说的，同一时间系统中只能有一个窗口的更新被锁定。如果你调用LockWindowUpdate的目的仅仅是防止窗口重绘，比如因为你在更新这个窗口，在你的更新完成前，不希望它不停的刷新，那么请直接禁止窗口的重绘。如果你使用了LockWindowUpdate，将引来无数下面的问题。

首先，如果另一个什么程序也以同样错误的方式使用LockWindowUpdate，那么你们中会有一个人失败。首先调用LockWindowUpdate的程序将会成功，第二个调用的程序将会失败。现在你准备怎么办？你的窗口不会被锁定。

其次，如果你锁定了自己的窗口更新，这时用户切换到另一个程序，并试图拖拽一个对象（或甚至只是尝试移动一下那个窗口），那一个LockWindowUpdate将会失败，于是用户遇到了一个由于某种神秘原因拖放失效的情形。然后，10秒钟后，一切功能又运作作正常。“愚蠢的烂Windows”用户嘀咕道。

反过来说，如果你在一个拖放或是窗口移动的过程中准备调用LockWindowUpdate，那么你的调用就会失败。

这只是更一般意义上，使用全局状态来处理局部情况的编程错误中，比较具体的例子。当你想禁止自己的一个窗口的重绘时，你不会希望这会影响到系统中的其它窗口。更新自己的窗口是一个局部情况，但是你使用了全局状态（被锁定更新的窗口）来维持它。

我可以预料到有人会说：“那么，窗口管理器应当阻止人们在一个非拖放操作中锁定窗口更新。”问题是，窗口管理器怎么知道这个？它只是知道发生了什么事情，但不知道为什么发生。一个程序到底是由于懒于使用WM_SETREDRAW消息而使用LockWindowUpdate？还是为了响应引发拖放操作的用户输入？这里没办法说“用户鼠标按键压下了”，因为用户可能用基于键盘的理论上和拖放等价的操作（例如使用方向键来改变窗口尺寸）。基本上这个问题很难于解决，除非计算机能更多一点对让他做的事情的猜想。