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

Question

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

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

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

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

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

所以我的问题是:

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

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

感谢您的帮助!

Answer 1

1. 当您更改选项卡时，IE 很可能会调整控件的 Z 顺序。在 IE9 中，URL 栏和选项卡有一个共同的父级。当您选择一个新选项卡时，它会激活 URL 栏(并且激活通常会将窗口带到其本地 Z 顺序的顶部)。

2. 没有。当 SetWindowPos 函数作用于您的窗口时，您会得到 WM_WINDOWPOSCHANGED。如果某些 sibling 的 z 顺序发生变化，您不会收到消息。没有人在您的窗口上调用 SetWindowPos。您可以通过编写一个调整某些子窗口的 z 顺序的测试程序来了解这一点。

这是有道理的，因为可能有任意数量的同级窗口，并且通知所有这些窗口的开销可能是无限的。考虑到一些 sibling 可能会通过进一步打乱 z 顺序来使用react，因此几乎不可能提出一套一致的规则来将这些消息传递给所有 sibling 。还没有收到第一个通知的 sibling 现在有两个待处理的通知吗？他们会立即发布或发送吗？如果队列越来越大直到溢出怎么办？

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

此外，Windows 可能需要对失去焦点使用react，这是合理的。窗口 C 不太可能需要知道 B 现在位于 A 之上，而不是相反，那么为什么要设计系统来发送大量不必要的消息？

破解不受您控制且没有明确定义的 API 来执行您想要执行的操作的应用程序的用户界面在任何地方都是困难甚至不可能的，而且它总是很脆弱。提供工具栏和浏览器自定义功能的小组雇用的人数可能比您预期的要多，而且他们一天中的大部分时间都在使用 Spy++ 进行探索和试验。这是天生的黑客行为。