似乎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+ * 天 *(!)的持续时间,在此期间不允许非前台进程激活另一个窗口,这 * 实际上 * 相当于禁用此类激活。