有一位读者问了这样一个问题：

“为什么鼠标光标的设定绑定在窗口类，而不是窗口上？”

这个问题隐含地假设了光标与窗口类相关联。虽然每个窗口类都有一个关联的光标，但决定使用哪个光标的是窗口。

光标设置过程在 WM_SETCURSOR 消息的文档中进行了描述，请看如下：

===================================

DefWindowProc 函数在处理 WM_SETCURSOR 消息之前，会将其传递到父窗口。如果父窗口返回 TRUE，则停止进一步处理。将消息传递到窗口的父窗口可使父窗口控制子窗口中光标的设置。DefWindowProc 函数还使用此消息将光标设置为箭头（如果它不在工作区中）或已注册的窗口类的光标（如果它位于工作区中）。

===================================

以上文档几乎涵盖了整个光标的设置过程。从现在开始，我所写的只是重述这几句话。

WM_SETCURSOR 会传递到光标下方的子窗口。（显然，它转到子窗口而不是父窗口，因为文档说 DefWindowProc 将消息转发到其父窗口。 如果消息最初发送给父窗口，则没有人可以将消息转发到！) 此时，窗口过程可以捕获 WM_SETCURSOR 消息，设置光标并返回 TRUE。因此，窗口在决定光标是什么时具有第一优先级。

如果窗口不处理 WM_SETCURSOR 消息，则 DefWindowProc 会将消息转发给父级，父级又可以决定是处理该消息还是依次转发到其父级。一种可能性是，其中一个祖先窗口将处理消息、设置光标并返回 TRUE。在这种情况下，TRUE 返回值告诉 DefWindowProc 光标已设置，无需再执行任何工作。

另一种更有可能的可能性是，没有一个祖先窗口关心设置光标。每次返回到 DefWindowProc 时，光标将设置为窗口类中关联的光标。

下图描述了整个过程。

假设我们有三个窗口，A、B 和 C，其中 A 是顶层窗口，B 是子窗口，C 是孙窗口，它们在 WM_SETCURSOR 中都没有做任何特别的事情。进一步假设鼠标位于窗口 C 上：

请注意观察，WM_SETCURSOR 从底部（窗口 C）开始，向上冒泡到顶部（窗口 A），然后向下移动到窗口 C。在向上时，它会询问每个窗口是否要设置光标，如果它一直到顶部，没有人发表意见，那么在向下时，每个窗口都会将光标设置为 C 类光标。

现在，当然，沿途的任何窗口都可以决定“我正在设置光标！”并返回 TRUE，在这种情况下，消息处理将立即停止。

所以你看，窗口确实决定了光标是什么。是的，有一个与该类关联的游标，但仅当窗口决定使用它时才使用它。如果要将光标与窗口关联，可以通过显式处理WM_SETCURSOR 消息来实现，而不是让 DefWindowProc 默认为类光标。

这位读者提出了另外一个问题：”许多程序在每个 WM_MOUSEMOVE 调用 SetCursor。这合理吗？”

虽然没有规则禁止在 WM_MOUSEMOVE 消息中设置光标，但这会导致一些问题。

首先，不那么严重的后果是，你将无法参与 WM_SETCURSOR 谈判，因为你没有在那里进行光标设置。

但真正的问题是，你会得到一个光标闪烁。WM_SETCURSOR 将被发送到你的窗口以确定光标。由于你没有执行任何操作，因此它可能会变成窗口类光标。然后你得到你的WM_MOUSEMOVE 并再次设置光标。

结果：每次用户移动鼠标时，光标都会变为类光标，然后变为默认光标。

让我们看看实际的效果，从我们的例子程序开始，并进行以下更改：

运行程序并将鼠标移到工作区上。请注意，它在箭头（类光标，在 WM_SETCURSOR 期间设置）和十字光标（在 WM_MOUSEMOVE 期间设置）之间闪烁。

总结

新技能 GET: 在正确的位置设置你的鼠标光标，这个正确的位置是：WM_SETCURSOR 消息的处理函数中。

最后

Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一，里面有很多关于Windows的小知识，对于广大Windows平台开发者来说，确实十分有帮助。

本文来自：《What is the process by which the cursor gets set?》