1

我的应用程序中有几个分层窗口UpdateLayeredWindow()用于处理它们的视觉表示。根据MSDN 关于分层窗口的文章，“在使用UpdateLayeredWindow()应用程序时不需要响应WM_PAINT或其他绘画消息。” 他们共享一些与非分层窗口相同的消息处理程序，所以我想WM_PAINT如果目标是分层窗口，我会提前从处理中返回。

当然，这导致了一个主要问题：如果其中一个分层窗口确实收到了一条WM_PAINT消息，那么输入队列最终会被无穷无尽的WM_PAINT消息流淹没。这个最终结果是有道理的，因为窗口永远不会被验证，所以它会一直认为它需要绘制（我不应该在没有验证或BeginPaint()ing 等的情况下从处理程序返回），但是什么没有意义这就是它首先收到消息的原因，因为它对正在使用的窗口没有影响UpdateLayeredWindow()。

它甚至不会可靠地发生——只是偶尔，而不是每次窗口的像素需要重绘。DefWindowProc()回退到分层窗口收到消息时恢复了理智WM_PAINT，但我觉得发生了一些我不明白的事情。考虑到这个问题很少出现，我担心这可能只是隐藏了一个更微妙的问题。UpdateLayeredWindow()使用仍会偶尔收到消息的窗口是否是预期的行为WM_PAINT？只要我处理得当，这有关系吗？

附加信息，如果需要：窗口UpdateLayeredWindow()在创建后立即调用，然后它自己留下（它不会再次调用它，因为它不会改变）。使用 C++ 和 win32 API，没有 MFC。

4

1 回答 1

2

我之前也遇到过类似的问题，虽然我的记忆现在可能有点生疏了。

首先，保留 DefWindowProc。当文档说您不必回复时，我认为这意味着完全忽略该消息，而不是阻止默认处理。

我个人从两个不同的原因经历了这一点。一个是实际上发送 WM_PAINT 消息的窗口（邪恶！当心！）。另一个（IIRC）是由某些 RedrawWindow 调用引起的。在这两种情况下，我都将问题归咎于编写不佳的代码，超出了我的控制范围，并且从未出现过将其传递给 DefWindowProc 的任何情况。

希望你也有同样的经历！

祝你好运。我发现分层窗口的文档记录很差，并且充满了有趣的警告和陷阱，但是一旦解决了所有问题，就会非常令人愉悦。

于 2009-06-08T17:16:28.647 回答