我来帮你拆解下这个问题——其实这背后是窗口可见性对Windows控件消息的影响，还有PowerBI这类现代网页的特性在搞鬼，咱们一步步说：

核心原因分析 #

1. 不可见窗口的系统交互限制 #

Windows系统对标记为不可见（Visible=false）的窗口有严格的交互限制：

• ControlSend和ControlClick本质是向目标控件发送Windows消息，但当窗口不可见时，系统会默认跳过这类交互请求——因为它认为“用户看不到这个窗口，无需处理输入”。甚至有些控件在窗口隐藏状态下，根本不会完成完整的初始化流程。
• 对比前台用的Send和MouseClick，它们是模拟全局输入事件，只要窗口在前台（可见），系统会自动把输入定向到当前活动窗口，自然能正常触发交互。

2. PowerBI网页的动态交互特性 #

PowerBI这类现代网页依赖大量JavaScript动态渲染逻辑，很多交互需要完整的浏览器UI线程状态和真实输入上下文：

• ControlSend/ControlClick发送的是“伪输入消息”，不像真实的鼠标/键盘操作那样会触发完整的事件链（比如hover、focus、mousedown/mouseup的连续触发）。尤其在窗口隐藏时，浏览器的JS引擎可能会忽略这类模拟消息。
• IE的Com对象在Visible=false时，可能不会加载网页的全部交互逻辑——有些JS事件只有在窗口可见时才会绑定或激活。

可行的解决方案 #

1. 让窗口“隐形但可见” #

不要直接设置wb.Visible := false，改成让窗口保持可见但移到屏幕外：

wb.Visible := true
; 把窗口移到屏幕左上角外，用户看不到但系统认为它是可见状态
WinMove, ahk_class IEFrame,, -2000, -2000

这种方式既满足“后台运行”的需求，又能让窗口控件正常响应消息。

2. 直接操作网页DOM（最推荐） #

既然你已经用了IE的Com对象，直接通过DOM操作触发交互比模拟点击可靠得多，完全不受窗口可见性影响：

; 等待页面完全加载（不仅要等wb.busy，还要等DOM ready）
while (wb.busy || wb.document.readyState != "complete")
    sleep 100

; 示例：通过元素ID触发点击
wb.document.getElementById("target-button-id").click()

; 示例：通过CSS选择器触发点击
wb.document.querySelector(".target-button-class").click()

这种方式直接调用网页原生事件，不需要模拟鼠标，稳定性和兼容性都远高于模拟点击。

3. 精准指定Control命令的目标窗口 #

如果一定要用ControlSend/ControlClick，要确保命令精准指向IE窗口的句柄，避免系统找不到目标控件：

WinGet, hIE, ID, ahk_class IEFrame
; 所有Control命令都指定这个句柄
ControlSend,, {LWin down}{Up down}, ahk_id %hIE%
ControlClick, left, 1275, 320, , , ahk_id %hIE%

不过这种方法还是绕不开窗口可见性的限制，仅作为备选方案。

总的来说，后台控制隐藏窗口的核心矛盾是系统对不可见窗口的交互限制，加上现代网页对真实输入上下文的依赖。改用DOM操作或者让窗口“隐形但可见”，是解决这个问题最稳妥的思路。

内容的提问来源于stack exchange，提问作者RCarmody