Winapi SetForeGroundIndow的记录条件是否准确？

指

Windows故意拒绝许多将特定窗口设置为前台的请求，其目标是：

当用户使用另一个窗口时，应用程序不能将窗口强制置于前台

SetForegroundWindow

成功的条件记录如下：

系统限制哪些进程可以设置前台窗口。仅当以下条件之一为真时，进程才能设置前景窗口：

• 这个过程就是前景过程
• 该进程由前台进程启动
• 进程接收到最后一个输入事件
• 没有前台进程
• 进程正在调试中
• 前台进程不是现代应用程序或开始屏幕
• 前景未被锁定（请参见

  locksetforegroundindow

  ）
• 前台锁定超时已过期（请参阅

  systemparameters sinfo

  中的

  SPI\u GETFOREGROUNDLOCKTIMEOUT

  ）
• 没有激活的菜单

此文档听起来不正确。我认为，它最初只是一个较短的清单，其中只需要满足一个条件。但实际行为更为复杂

有人能证实实际的行为吗？是：

只有满足以下所有条件时，进程才能设置前景窗口：

• 以下一个或多个条件为真：
  • 这个过程就是前景过程
  • 该进程由前台进程启动
  • 该进程是在前台进程发出的

    allowSetForeGroundIndow

    调用中标识的
  • 进程接收到最后一个输入事件
  • 没有前台进程
  • 进程正在调试中
• 前台进程不是现代应用程序或开始屏幕
• 以下两个条件之一为真：
  • 前景未被锁定（请参见

    locksetforegroundindow

    ）
  • 前台锁定超时已过期（请参阅

    systemparameters sinfo

    中的

    SPI\u GETFOREGROUNDLOCKTIMEOUT

    ）
• 没有激活的菜单

---

如果其他专家一致认为此处的文档有误，我将提交一份引用此问题的Connect错误报告。

是关于提出相同问题的。是的，我很确定这些条件——以目前的列表形式——是假的，仅仅是因为最后一个要点，这与整个概念相矛盾。“进程接收到了最后一个输入事件。”这对于鼠标和键盘输入似乎是正确的。不过，触摸输入的处理方式似乎有所不同（至少在Windows7上是这样），而且它并不能立即限定设置前景窗口的过程。显然，一旦系统合成了伴随的鼠标输入事件，进程只能设置前景窗口。有人能证实这一点吗？