似乎SystemParametersInfo WinAPI函数使用的SPI_GETFOREGROUNDLOCKTIMEOUT/SPI_SETFOREGROUNDLOCKTIMEOUT值对应于ForegroundLockTimeout每用户注册表值（在HKEY_CURRENT_USER\Control Panel\Desktop中）。
我的期望如下：
- 会话中的 effective 值是
SPI_GETFOREGROUNDLOCKTIMEOUT报告的值，如果通过SPI_SETFOREGROUNDLOCKTIMEOUT进行了 * 非持久性 * 更新（fWinIni参数设置为0），则该值可能与基础ForegroundLockTimeout注册表值不同。 - 在下次登录时，这两个值应恢复同步。
在以下情况下，此期望 * 未 * 满足：
- 在Windows 11 上，
SPI_GETFOREGROUNDLOCKTIMEOUT* 总是 * 在登录时报告2147483647（带符号的32位整数的最大值）-即使ForegroundLockTimeout注册表默认值为200000 - 更新 *：在通过 *VMWare Fusion Technology Preview for M1 Mac * 运行的 ARM W11 ISO映像上观察到了该行为，该版本最新版本为2022年9月16日。
- 虽然 * 非持久性 *
SPI_SETFOREGROUNDLOCKTIMEOUT更新是可能的，但 * 持久性 * 更改未来会话的有效SPI_GETFOREGROUNDLOCKTIMEOUT值的尝试 * 被悄悄忽略 *。 - 实际上，新用户会话默认为 * 不 * 允许无条件窗口激活。
- 在Windows 10 上，我观察到 * 一个特定用户帐户 * 的类似行为：
- 除了
0是默认的SPI_GETFOREGROUNDLOCKTIMEOUT值（无法永久更改）之外，该行为与Windows 11上的行为相同。实际上，此用户的新会话默认允许 * 无条件 * 激活窗口。 - 同一台机器上的另一个 * 用户帐户 * 没有 * 表现出这种行为-在那里，满足上述期望。
- 机器 * 不是 * 在开发者模式;具有不同行为的帐户是管理员，而另一个不是-但我不认为这有什么关系。
我的问题：
- 观察到的Windows 11 行为是否符合预期？如果是，是否在某处对其进行了记录？
- 在Windows 10 上，如何解释用户帐户的行为不稳定？是否有 * 另一个 * 持久性设置覆盖了预期行为？
1条答案
按热度按时间nimxete21#
HKEY_CURRENT_USER\Control Panel\Desktop中的值ForegroundLockTimeout）***不再被 * 遵守 ，并且新会话中的不变 * 默认值为[int]::MaxValue，[1]这实际上禁止 * 由碰巧在 * 当前前台窗口中运行的进程以外的进程以编程方式激活窗口。HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run）时运行 *，该应用程序在 * 每个会话 * 的基础上将非持久性SPI_GETFOREGROUNDLOCKTIMEOUT值设置为0：AutoHotkey[1]这个值以毫秒为单位，相当于24+ * 天 *（！）的持续时间，在此期间不允许非前台进程激活另一个窗口，这 * 实际上 * 相当于禁用此类激活。