究竟在什么情况下发送WM_ACTIVATE？

Question

我正在尝试调试一个巨大的Win32 GUI应用程序（我有完整的源代码），该应用程序分为几个进程。问题如下：在一个进程中，我有一个带有列表框的对话框，当我双击列表框中的一个项目时，启动了另一个进程，该进程创建了自己的窗口，该窗口位于最前面并覆盖了初始对话框。如果我做了一些操作（由于我还不完全了解它们，我还不能完全解释），某些操作会迫使初始对话框开始在任务栏中闪烁。

我尝试使用Microsoft Spy ++，发现每次执行该操作时，都会将WM_ACTIVATE发送到对话框，大多数情况下，它具有以下参数：

fActive: WA_INACTIVE fMinimized:False hwndPrevious:(null)

在这种情况下，对话框不会开始闪烁。但是有时参数是

fActive: WA_ACTIVE fMinimized:False hwndPrevious:(null)

恰好与对话框闪烁相对应。

MSDN表示，通过鼠标单击以外的其他方法（例如，通过调用SetActiveWindow函数或使用键盘界面选择窗口）激活窗口时，将通过WA_ACTIVE发送WM_ACTIVATE 。

现在，在应用程序代码中从未调用SetActiveWindow（），并且我对可切换窗口的键盘不做任何操作。

WM_ACTIVATE与WA_ACTIVE一起发送还有哪些其他原因？

Answer 1

您的问题是由引起的SetForegroundWindow()。它具有适当的对策，可防止进程在用户积极使用其他应用程序时将窗口推向用户的脸部。

在SetForegroundWindow()当第二进程创建的窗口，并含蓄地试图采取前景与它正在发生。（当您写“ brought to front”时，您说了很多。）

第一个应用程序应该调用AllowSetForegroundWindow()说“没关系，允许该窗口从我这里进行前台激活”。

请注意，如果执行此操作，则用户可能会遇到这种情况：

• 用户单击列表框项。
• 第二个过程启动缓慢。
• 用户在第一个应用程序中单击其他内容。（失去耐心）
• 第二个进程从第一个应用程序窃取了前景。（用户感到沮丧，因为他正在做其他事情。）

这就是导致当前代码闪烁的情况。窗口管理器检测到用户已放弃等待第二个进程，并开始对第一个进程执行其他操作，因此当它最终绕开尝试窃取前景时，它将阻止第二个进程。