SetForegroundWindow：ForegroundLockTimeout 注册表值和 SPI_GETFOREGROUNDLOCKTIMEOUT WinAPI 参数之间的关系

Context:

• 这个问题是关于如何通过配置控制是否允许编程跨进程窗口激活（使窗口成为具有输入焦点的前台窗口），通过SetForegroundWindow https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindowWinAPI函数。

看来SPI_GETFOREGROUNDLOCKTIMEOUT / SPI_SETFOREGROUNDLOCKTIMEOUT与使用的值SystemParametersInfo https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-systemparametersinfowWinAPI函数对应ForegroundLockTimeout https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc957208(v=technet.10)持久的、每用户注册表值（在HKEY_CURRENT_USER\Control Panel\Desktop).
前台锁定超时是交互式用户输入之后跨进程窗口激活的时间段。not允许的。

我的期望如下：

• The 有效的会话中的值是报告的值SPI_GETFOREGROUNDLOCKTIMEOUT，这可能与底层不同ForegroundLockTimeout注册表值，如果非持久更新是通过SPI_SETFOREGROUNDLOCKTIMEOUT (fWinIni参数设置为0)

• 下次登录时，这两个值应恢复同步。

这个期望是not遇到以下情况：

• 在 Windows 上11, the SPI_GETFOREGROUNDLOCKTIMEOUT always报告2147483647（有符号 32 位整数的最大值）登录时 - 即使ForegroundLockTimeout注册表默认值为200000

  • Update：该行为是在ARMW11 ISO 映像通过适用于 M1 Mac 的 VMWare Fusion 技术预览，截至 2022 年 9 月 16 日。

  • While 非持久 SPI_SETFOREGROUNDLOCKTIMEOUT更新是可能的，尝试坚持不懈地改变有效的SPI_GETFOREGROUNDLOCKTIMEOUT未来会话的价值是悄悄地忽略.

  • 实际上，新用户会话默认为not允许无条件窗口激活。

• 在 Windows 上10，我观察到类似的行为一个特定的用户帐户:

  • 该行为与 Windows 11 上相同，不同之处在于0是默认值SPI_GETFOREGROUNDLOCKTIMEOUT值，无法持久更改。实际上，该用户的新会话默认允许无条件的窗口激活。

  • Another同一台机器上的用户帐户not表现出这种行为 - 在那里，上述期望得到满足。

  • 该机器是not在开发者模式下；具有不同行为的帐户是管理员，而另一个则不是 - 但我认为这并不重要。

我的问题：

• 是观察到的Windows11预期的行为？如果是这样，它是否记录在某处？

• 在 Windows 上10，对于任性的用户账号的行为有何解释？有没有another持久设置会覆盖预期行为吗？

• In Windows 10+, the registry-based setting (value ForegroundLockTimeout in HKEY_CURRENT_USER\Control Panel\Desktop) is no longer respected, and the invariable default value in a new session is [int]::MaxValue,^[1] which in effect disables programmatic activation of windows by processes other than those that happen to run in the current foreground window.

• 就我而言，它恰好是一个第三方应用程序配置为运行每次登录时（通过注册表项HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run) that 设置非持久化SPI_GETFOREGROUNDLOCKTIMEOUT价值0 on a 每个会话 basis: 自动热键 http://www.autohotkey.com/

^{[1] This value in milliseconds amounts to a duration of 24+ days(!) of the system having to be idle (in terms of user input) before a non-foreground process is allowed to activate another window, which in effect amounts to disabling such activations.}