LockWindowUpdate 的误用

LockWindowUpdate系列1：LockWindowUpdate的行为？

对LockWindowUpdate可怜的误解。

 

这是关于LockWindowUpdate系列的第一篇。LockWindowUpdate的行为，它是用于做什么的，以及（可能更重要的是）它不是用于做什么。

 

LockWindowUpdate 做的事情其实很简单。当一个窗口被“锁定”，所有向它及其子窗口的绘制都会失败。取代绘制操作的是，窗口管理器记住了应用程序试图在窗口的哪一部分中进行绘制。当窗口“解锁”后，这些区域被无效化，使得应用程序得到一个WM_PAINT消息，从而重新恢复了屏幕内容与应用程序认为应当在屏幕上显示的内容之间的同步。

  

大家已经在CS_SAVEBITS看到了“记录在情形X有效时，应用程序试图做的绘制，并在情形X不再有效时做无效处理”这样的行为。在这种意义上，LockWindowUpdate做了同样的簿记的工作。在你用一个CS_SAVEBITS窗口覆盖锁定的窗口时这个行为就会发生，只是这里不会保存什么数据。

 

在文档中明确的指出，同一时间只能有一个窗口被锁定。同时这也可以由函数原型暗示得出。如果两个窗口可以同时被锁定，将无法可靠的使用LockWindowUpdate。当你做下面的事情时将会怎样：

LockWindowUpdate(hwndA);  //  锁定窗口A
LockWindowUpdate(hwndB);  //  将窗口B也锁定
LockWindowUpdate(NULL);  //  ???

 

第三个对LockWindowUpdate的调用会做什么么？是把所有的窗口解锁？还是只解锁窗口A，或是只解锁窗口B？不论你如何回答，都不可能让下列的代码可靠的使用LockWindowUpdate：

void  BeginOperationA()
{
 LockWindowUpdate(hwndA);
 ...
}
 
void  EndOperationA()
{
 ...
 LockWindowUpdate(NULL);
}
 
void  BeginOperationB()
{
 LockWindowUpdate(hwndB);
 ...
}
 
void  EndOperationB()
{
 ...
 LockWindowUpdate(NULL);
}

 

设想BeginOperation开始了由异步行为触发的某个操作。例如，假设操作绘制播放的反馈，因此开始于鼠标按下，并结束于鼠标释放。

 

现在假设仍在播放过程中时，操作B结束了。EndOperationB将会清理操作B，并调用LockWindowUpdate(NULL)。如果你假设这将解锁所有窗口，那么就会破坏了操作A，因为它预期hwndA仍被锁定。类似的，如果你提出应当只解锁hwndA，那么不只操作A被破坏了，操作B也会被破坏（因为尽管操作B已经完成，hwndB仍被锁定）。另一方面，如果你建议LockWIndowUpdate(NULL)应当解锁hwndB，那么请考虑一下操作A先于B完成的情况。

 

如果LockWindowUpdate同一时间能够锁定多于一个窗口，那么这个函数的原型就需要修改，以使得解锁的操作可以知道那一个窗口正在被解锁。有很多方法可以做到这一点，例如添加一个新的参数或是创建一个单独的函数。

//  方法A – 新参数
//  fLock = TRUE 锁定, FALSE 解锁
BOOL LockWindowUpdate(HWND hwnd, BOOL fLock);
 
//  方法B – 独立函数
BOOL LockWindowUpdate(HWND hwnd);
BOOL UnlockWindowUpdate(HWND hwnd);

 

但是这两个都不是实际的情况，LockWindowUpdate函数同一时间只锁定一个窗口。这样做的原因在了解了LockWindowUpdate是用来做什么的之后会更加清晰

LockWindowUpdate系列2：LockWindowUpdate是打算如何使用的？

现在我们知道了LockWindowUpdate的行为。现在我们来看一下它是用于做什么的。

 

事实上，LockWindowUpdate的设计意图可以用一个词表达：拖拽。但我们稍后再说到这个。

 

LockWindowUpdate 的目的是允许一个程序暂时的接管绘制窗口的工作。为了做到这个，你当然需要防止窗口函数（或其它任何人）进行他们正常的绘制活动；否则，两处的代码（正常绘制窗口的代码和试图接管绘制的代码）会互相争夺对窗口的控制，由于互不知道对方在做什么，最后得到的将是一团糟。

 

但是，如果你已经锁定了窗口的更新，那么如何才能在窗口上绘制呢？你可以在GetDCEx函数中使用DCX_LOCKWINDOWUPDATE标志。这个标志表示“即便是窗口已经锁定，也让我绘制到上面”。当然了，只有锁定了这个窗口的代码才能传递这个标志，否则又会引发LockWindowUpdate起初试图解决的那类冲突。

 

由于人们都很喜欢看表格，我制作了一个表格总结了当一个窗口被锁定更新时发生了什么变化。

 

	正常行为	更新被锁定
BeginPaint ,  GetDC , 等等…	绘制操作绘制到窗口上	绘制操作没有在窗口上绘出任何东西，但影响的区域被记录下来以供后面无效化
带DCX_LOCKWINDOWUPDATE 标志的 GetDCEx	（不要使用）	绘制操作绘制到窗口上

  

换句话说，当一个窗口更新被锁定后，普通的DC获取函数（BeginPaint及其伙伴）向窗口上绘制的能力将被剥夺，赋于了GetDCEx( DCX_LOCKWINDOWUPDATE) 。注意，如果没有窗口被锁定更新，不要使用DCX_LOCKWINDOWUPDATE标志，这个标志的目的是指出“我就是那个调用了LockWindowUpdate的家伙，快放行！”

 

窗口管理器有几分像喜剧中的情节。你告诉守卫说“不许任何人进入这个房间。”一小时后你回来了，守卫不让你进去。

“对不起先生，我不能让任何人进这个房间。”

“但我就是那个告诉你不让任何人进去的人呀。”

“是的，先生，我是按照您的指示做的。任何人都不能进入这个房间。” 

错误在于最初给守卫下达的命令。你应当说：“除了我以外，任何人都不允许进入这个房间。”  DCX_LOCKWINDOWUPDATE就好比你对窗口管理器说：“是我，让我进去。”

 

如果回头看一下LockWindowUpdate函数的工作方式，你会发现如果一个锁定的窗口没有试图做任何绘制，那么当窗口解锁时，不会有区域被无效。尽管 CS_SAVEBITS 窗口类属性会在窗口从屏幕上移除时自动保存原始的象素，并自动还原这些象素，LockWindowUpdate不会做任何类似的事。你需要自己负起责任确保在窗口被锁定更新时你修改的象素，在调用LockWindowUpdate(NULL)后恢复到原始的值。这通常可以通过在做自己的绘图操作前，将原始象素保存到一个屏幕外的位图中，并在完成后将它们绘制回去。

 

好，那么下面这就是意图的使用方式：

 

• 当你想接管另一个窗口的绘制，对那个窗口调用LockWindowUpdate。
• 保存你将要覆盖绘制的窗口的象素。
• 绘制新的象素（这些象素往往是原始象素的修正，比如在将一个对象拖动到一个窗口上方时，你可能会添加一个表示此对象的图片）。
• 只要你的操作还在进行中，尽管重复。（这么做时，如果你正修改的屏幕区域与之前修改的不同，可能需要“备份”更多的屏幕上的象素。你可以增量的做备份/还原。例如，你不必在绘制新图片前累计需要恢复的象素集，只需要先把保存的所有象素恢复到屏幕，然后计算拖动图片的新位置，保存新位置处的象素，接着就可以在新位置绘制新图片。通过这种方式，你只需要处理一组“备份象素”）
• 当操作完成，恢复原始象素，并调用LockWindowUpdate(NULL)。

 

下一篇，我们将看到“拖拽”这个词的更多内容，以其是如何紧密的与整个LockWindowUpdate的概念绑定在一起的。

 

尽管我们才刚刚开始讨论LockWindowUpdate，你应当已经足以回管这个问题。

 

（注意：写这个系列的目的在于描述LockWindowUpdate的意图使用方式，不是讨论这首先是不是一个好的设计）

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

如我在前面所说的，LockWindowUpdate的设计意图可以用一个词表达：拖拽。

LockWindowUpdate 最简单的使用场景是在“拖动时显示窗口内容”功能关闭的情况下，当你移动或是改变窗口尺寸时，被窗口管理器使用。当你开始移动/改变尺寸操作，窗口管理器锁定整个桌面以便可以绘制细点矩形反馈，而不会因为其它窗口偶然与细点矩形交叠而导致冲突的风险。当移动/改变尺寸的操作完成，桌面被解锁，所有东西恢复原貌。

 

应用程序使用LockWindowUpdate的常见的场景，是希望为拖拽提供反馈而绘制一个自定义的图片。在这个情况下，应用程序锁定它自己的窗口以绘制拖拽的反馈。使用 DCX_LOCKWINDOWUPDATE 标志来获取一个可以用来绘制所需的反馈的DC，这样就不必担心窗口函数或应用程序中任何其它的代码偶然的绘制到反馈窗口上，并搞乱了拖拽图片。例如，如果这个应用程序正在一个列表视图中绘制拖拽的反馈，此时某个异步事件引发这个列表视图的内容改变（比方说添加了一个列表项），并且拖拽的图片正好在新添加的列表项要出现的位置，你一定不会想让列表视图的标准重绘行为覆盖（或是更糟，重合）了拖拽的图片。

 

可能你需要锁定其它应用程序的窗口的场景是当你要把一个物体拖过整个屏幕。如果你的程序是一个类似Spy那样的程序，允许用户通过拖拽一个“选择器”到一个窗口上方来选择它时，你可能会需要这么做。你需要锁定用户当前选择的窗口，不仅让它自己的重绘制不会与你的“选择器”冲突，也使其不会与你放置在窗口边沿的高亮效果冲突。

 

现在，你可能已经注意到所有使用LockWindowUpdate场景中一个共同的思路：他们都和某种形式的拖拽有关。拖拽窗口的标题以移动它、拖拽窗口的边框以改变它的尺寸、将一个对象拖入窗口或是拖出窗口。这不是一个巧合，LockWindowUpdate就是专门设计用于这些拖拽场景的。由于拖拽对象要用到鼠标按键，而只会有一个鼠标，故而同一时间不会有多个拖拽操作进行。因此，没有必要同时锁定多个窗口的更新。也许这个函数应当更准确的命名为LockDragWindow。

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

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

 

人们看到LockWindowUpdate“锁定的窗口将不能绘制自己”的行为，就用它来作为 WM_SETREDRAW 消息的偷懒的使用方式，尽管发送一个WM_SETREDRAW消息不不比调用LockWindowUpdate更麻烦。只是多打20来个字符，而且如果使用中的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？还是为了响应引发拖放操作的用户输入？这里没办法说“用户鼠标按键压下了”，因为用户可能用基于键盘的理论上和拖放等价的操作（例如使用方向键来改变窗口尺寸）。基本上这个问题很难于解决，除非计算机能更多一点对让他做的事情的猜想。

 

下一回是对LockWindowUpdate的最终评论。

LockWindowUpdate系列5：关于LockWindowUpdate的最终评论 

现在大家了解了LockWindowUpdate的设计意图，我现在将要告诉大家你们为什么不应当使用这个函数，甚至不是因为其设计意图的缘因。

 

这需要回到LockWindowUpdate被创造出来的历史环境。回到16位Windows（特别是Windows 3.1）的时代。在那时，内存还是很昂贵的，显示驱动功能也很有限。还没有DirectX，没有AlphaBlend函数。你所拥有的一切就是一块屏幕缓冲区。LockWindowUpdate函数允许你接管这个屏幕缓冲区中对应一个窗口的部分，以得以在不需窗口知道的情况下应用自己特别的效果。

 

Windows 3.1 距今已经十年多了，在这期间，我们有了DirectX覆盖、区域化窗口、分层窗口、alpha混合、桌面合成，种种我们在过去不曾拥有的绝妙图象特效。特别是这些美妙的分层窗口和区域化窗口，允许你做几乎所有你希望用LockWindowUpdate去做的事情。如果你希望在一个窗口边沿绘制高亮，你可以在其边沿放置一个区域化窗口。如果你希望在一个窗口上方绘制一个拖拽图片，你只需要创建一个分层窗口，并把它放置到目标窗口上方即可。使用的是分层窗口、一个区域及你想要的无论哪一种奇特的alpha通道，而将冗重的alpha混合和合成推给图象引擎来完成。更好的是，分层窗口可以伸展到拖拽经过的窗口以外，这是LockWindowUpdate无法完成的。（你可以在Windwos XP中看到这种特效，在资源管理器窗口中“全选”，并将整个选择内容在屏幕上拖拽。你将看到拖拽图像没有局限于拖拽经过的窗口边界。）

  

更甚者，在Vista的桌面窗口管理器（desktop window manager）令人惊奇的全新合成方式中，LockWindowUpdate更是不再值得使用。锁定一个特定窗口的更新还不算太成问题，因为桌面窗口管理器可以只是给你这个窗口的后台位图。但是如果你锁定了整个屏幕（我常见到人们这么做），桌面窗口管理器就需要将所有窗口合成到一个实际位图中，以便在你使用 DCX_LOCKWINDOWUPDATE 标志调用GetDCEx时可以返回给你。桌面窗口管理器通常是在DirectX和显示驱动加速的辅助下直接进行合成的，所有的合成结果通常是直接送到屏幕上，实际上根本不会存放在一个“合成后的”位图中。但是如果你锁定了屏幕，并请求一个屏幕的DC，桌面窗口管理器只得模拟老式的行为，使得你可以访问一个代表了假如根本没有合成这回事的情况下，你“应当得到”的东西。这并不轻松！

 

尾声 。我并不清楚这个系列是否成功。我的目标只是帮助人们更有效的使用LockWindowUpdate，并在LockWindowUpdate不适于一个工作时指导他们转向其它的替代物。换句话说，这是一篇关于LockWindowUpdate的文章，不是函数文档。我试图让我的表达显得轻松一些，但我估计我的幽默并不好笑，人们只是用他们来做为否定注解的跳板。

 

特别感谢那些把这个系列用来作为一个抱怨文档的机会的人们。我的意思是，咄，如果文档是完美的，我也大可不必写这么一个系列。不过这些人们往往只是看了函数说明那一页，而忽视了阅读所有文档。嘿，除了单纯的函数说明外，还有更多的文档哪！函数说明只是一个参考，你应当是在已经知道会发生什么，并只是需要微调一些细节时，才会到那里去看一下。真正的学习应当是从概览和文章中去进行。如果你想学习如何操作你的收音机，你不会上来就看电路图的。

 

我认为当Ronald D. Moore说“听播客时你必须有足够的忍耐力”时，他一定是在搞什么鬼。

LockWindowUpdate系列1：LockWindowUpdate的行为？

LockWindowUpdate系列2：LockWindowUpdate是打算如何使用的？

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

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

LockWindowUpdate系列5：关于LockWindowUpdate的最终评论


原文出处：http://blogs.msdn.com/oldnewthing/archive/2007/02/19/1716211.aspx
原文出处：http://blogs.msdn.com/oldnewthing/archive/2007/02/20/1726880.aspx
原文出处：http://blogs.msdn.com/oldnewthing/archive/2007/02/21/1735472.aspx
原文出处：http://blogs.msdn.com/oldnewthing/archive/2007/02/22/1742084.aspx
原文出处：http://blogs.msdn.com/oldnewthing/archive/2007/02/23/1747713.aspx