在 Windows 上，当我的子窗口的 z 顺序相对于它的同级窗口之一发生变化时，我的子窗口是否应该获得 WM_WINDOWPOSCHANGED？答案

【问题标题】：On Windows, should my child window get a WM_WINDOWPOSCHANGED when its z-order changes relative to one of its siblings?在 Windows 上，当我的子窗口的 z 顺序相对于它的同级窗口之一发生变化时，我的子窗口是否应该获得 WM_WINDOWPOSCHANGED？
【发布时间】：2011-09-14 23:29:57
【问题描述】：

我正在尝试将自定义小部件插入到 Internet Explorer 8 网址栏中，在停止和重新加载按钮旁边。这只是我个人的生产力增强器。

IE 框架这部分的“窗口模型”是一个“地址栏根”窗口，它拥有组成 IE8 url 栏的窗口：一个编辑框、一个组合控件以及停止和重新加载按钮。

从另一个进程中，我创建了一个新的 WS_CHILD 窗口（具有自定义类名），该窗口由 IE 的地址栏根窗口作为父级，从而使其成为编辑框的兄弟并停止/重新加载。我用 HWND_TOP 的 hwndInsertAfter 调用 SetWindowPos 以确保它出现在 urlbar 的“上方”（即“in”）。这很好用，我看到我的窗口最初是在 IE urlbar 中绘制的。

但是，当我激活 IE 窗口时，urlbar 编辑控件会跳回到我的窗口前面。我知道这是因为我仍然看到我的窗口绘制在 urlbar 后面，并且因为当我在计时器上将 ->GetTopWindow() 打印到调试控制台时，它变成了 urlbar 编辑控件的 HWND。

如果我更新我的消息循环以在 WM_PAINT 上使用 HWND_TOP 调用 SetWindowPos，情况会更好 - 现在当我激活 IE 窗口并移动它时，我的控件正确地停留在编辑控件上方在网址栏中。但是，一旦我在 IE 选项卡之间切换，这会更新 IE 的 urlbar 编辑控件的文本，我的控件就会移回编辑控件后面。（注意：当我最大化或恢复窗口时也会发生这种情况。）

所以我的问题是：

1) IE 是否有可能在每次单击 IE 中的选项卡时故意将其 urlbar 编辑控件放回 z 顺序的顶部，或者我对 Windows 绘画和 z- 的理解存在差距订购作品？我的理解是，一旦您指定了 子窗口 的 z 顺序（最终用户无法操作），该顺序应该保持不变，直到以编程方式更改。因此，即使 IE 在选项卡选择时重新绘制其编辑控件，而我没有重新绘制或以其他方式作用于我的窗口，我的窗口仍应牢牢保持在顶部。

2) 鉴于我的窗口的 z 顺序显然正在改变，它不应该收到 WM_WINDOWPOSCHANGING/WM_WINDOWPOSCHANGED 吗？如果是这样，我至少可以响应该事件并让自己掌握在 Edit 控件之上。但是，即使当我单击选项卡时，我可以在 urlbar 编辑控件后面看到我的窗口绘画，并且即使我的调试窗口输出确认地址栏根的 GetTopWindow() 在我单击选项卡时成为编辑控件的 HWND ，即使我看到 WM_WINDOWPOSCHANGING/WM_WINDOWPOSCHANGED 在我单击选项卡时被发送到带有 HWND_TOP 的 hwndInsertAfter 的 Edit 控件，但我自己的窗口没有收到任何可以让我保持 z 顺序不变的消息。这对我来说似乎是错误的，解决它会迫使我在 IE 的进程中运行并将所有发送到它的编辑控件的消息挂钩，只是为了有一个事件来响应:(

感谢您的帮助！

【问题讨论】：

标签： windows winapi internet-explorer parent-child z-order

【解决方案1】：

当您更改选项卡时，IE 很可能会调整控件的 Z 顺序。在 IE9 中，URL 栏和选项卡有一个共同的父级。当您选择一个新选项卡时，它会激活 URL 栏（并且激活通常会将窗口带到其本地 Z 顺序的顶部）。
没有。当 SetWindowPos 函数作用于您的窗口时，您将获得 WM_WINDOWPOSCHANGED。如果某些兄弟姐妹的 z 顺序发生了变化，您将不会收到消息。没有人在您的窗口上调用 SetWindowPos。您可以通过编写一个测试程序来处理一些子窗口的 z 顺序来看到这一点。

这是有道理的，因为可能有任意数量的兄弟窗口，并且通知所有这些窗口可能是无限量的开销。考虑到一些兄弟姐妹可能会通过进一步改组 z 顺序来做出反应，因此几乎不可能想出一套一致的规则来将这些消息传递给所有兄弟姐妹。还没有收到第一个通知的兄弟姐妹现在有两个待处理的通知吗？他们会立即发布或发送吗？如果队列不断增长直到溢出怎么办？

这与 WM_KILLFOCUS/WM_SETFOCUS 通知不同，它最多影响两个窗口。这对通知的数量设置了合理的限制。即使由于失去控制试图夺回焦点而导致失控的无限循环，队列也不会溢出，因为每个传递的 WM_KILLFOCUS 只有一个 SetFocus 调用。

此外，windows 可能需要对失去焦点做出反应是合理的。窗口 C 需要知道 B 现在位于 A 之上而不是相反的可能性要小得多，那么为什么要设计系统来发送大量不必要的消息呢？

破解您无法控制且没有明确定义的 API 来执行您想做的事情的应用的 UI 几乎是不可能的，而且总是很脆弱。推出工具栏和浏览器自定义功能的团队的员工比您预期的要多，他们一天中的大部分时间都在使用 Spy++ 进行探索和试验。这是天生的黑客行为。

【讨论】：

对于#1，它不是点击编辑控件。这是对另一个浏览器选项卡的单击，它会更新 urlbar 的文本（以显示您选择的选项卡的 url），但不会将焦点放在 urlbar 上。这应该自然地改变z-order吗？更一般地说，在什么情况下 Window 会自动更新子窗口/控件的 z-order？
对于#2，是否有任何文档可以准确地说明这一点？很难基于反复试验和“一般”进行编程 :( 感谢您的帮助。不幸的是，我确实需要在 IE8 中执行此操作。
另外，我不确定我是否遵循 #2 背后的基本原理。出于同样的原因，失去焦点的控件可以请求返回焦点并开始无限循环，但 Windows 仍会通知控件。如果在所有情况下窗口位置发生变化时 WM_WINDOWPOSCHANG[ING/ED] 实际上不会触发，那么它的意义何在？
抱歉，最后一件事：即使我要在 IE9 中执行此操作，如果没有一些讨厌的 DLL 注入，我也无法进入进程。 IE 浏览器帮助对象不再在框架进程中运行。虽然它们确实允许您安装按钮，但它们将它们安装在下拉菜单后面，这没有帮助。
@Aaron Jones：我试图通过重写答案来解决您的问题。