feat(Win32-Front): 截图时尝试窗口前置#1334
Conversation
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - 我在这里给出一些整体性的反馈：
- 由于
ensure_foreground_and_topmost现在是连接行为中的关键环节，建议记录它的成功/失败情况（即使是在较低的日志级别），这样就可以在不影响测速结果的前提下诊断前台窗口相关的问题。 - 在调用
ensure_foreground_and_topmost之前，可能值得显式检查并防护hwnd_是否无效或为空，这样可以避免在初始化或错误状态下，新增加的前台恢复路径意外作用到非预期的句柄上。
给 AI 代理的提示
Please address the comments from this code review:
## Overall Comments
- Since `ensure_foreground_and_topmost` is now a key part of the connection behavior, consider logging its success/failure (even at a low log level) so foreground issues can be diagnosed without affecting the speed test result.
- It may be worth explicitly guarding against an invalid or null `hwnd_` before calling `ensure_foreground_and_topmost`, so the new foreground-recovery path cannot accidentally operate on an unexpected handle during early or error states.帮我变得更有用！请在每条评论上点 👍 或 👎，我会根据你的反馈改进后续的评审。
Original comment in English
Hey - I've left some high level feedback:
- Since
ensure_foreground_and_topmostis now a key part of the connection behavior, consider logging its success/failure (even at a low log level) so foreground issues can be diagnosed without affecting the speed test result. - It may be worth explicitly guarding against an invalid or null
hwnd_before callingensure_foreground_and_topmost, so the new foreground-recovery path cannot accidentally operate on an unexpected handle during early or error states.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Since `ensure_foreground_and_topmost` is now a key part of the connection behavior, consider logging its success/failure (even at a low log level) so foreground issues can be diagnosed without affecting the speed test result.
- It may be worth explicitly guarding against an invalid or null `hwnd_` before calling `ensure_foreground_and_topmost`, so the new foreground-recovery path cannot accidentally operate on an unexpected handle during early or error states.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
HarcoChen
force-pushed
the
fix/win32-front
branch
from
91080e2 to
5bf30fe
Compare
|
哦nb，玛丽 CI Gate该修了
结果：Node.js v24 默认用CommonJS解析，找不到模块 |
|
怎么在这里前置，不太对劲。需要前台的 screencapbase 类里面做吧 |
|
emm，因为我担心每次screencap都尝试前置，性能损失大，且焦点就等于始终被抢了，用户要被抢电脑了？
或许比较好的实现是冷却15s尝试拿一次焦点
获取Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: MistEO ***@***.***>
Sent: Sunday, May 17, 2026 11:30:59 PM
To: MaaXYZ/MaaFramework ***@***.***>
Cc: HarcoChen ***@***.***>; Author ***@***.***>
Subject: Re: [MaaXYZ/MaaFramework] feat(Win32-Front): Connect时尝试前置一下窗口 (PR #1334)
[https://avatars.githubusercontent.com/u/18511905?s=20&v=4]MistEO left a comment (MaaXYZ/MaaFramework#1334)<#1334 (comment)>
怎么在这里前置，不太对劲。需要前台的 screencapbase 类里面做吧
―
Reply to this email directly, view it on GitHub<#1334 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJAENWTD3DH5KIPHU62YHQL43HLLHAVCNFSM6AAAAACZBFRCG6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINZRGIZDSMBTGM>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
感觉问题不大，opus4.7说，在前台了不会有性能消耗
|
- 移除连接时前置这一逻辑 - 现在连接失败时，每5s尝试前置一次
|
OK，移除了连接时的尝试前置，改为以下逻辑： 功能实现“每次调用 foreground screencap 时检查一次”：
加入冷却是防止未预期的始终抢占焦点，MFW怎么不让我用电脑.jpg 代码逻辑代码结构上，新建了 |
HarcoChen
changed the title
|
|
||
| MAA_CTRL_UNIT_NS_BEGIN | ||
|
|
||
| class ForegroundScreencap : public ScreencapBase |
明天我把不过度封装的搬过来 |
3 participants
Closes MaaEnd/MaaEnd#2889, Closes MaaEnd/MaaEnd#2184,
Derive From MaaEnd/MaaEnd#2231
概述
在Win32-Front控制器连接时，尝试进行一次窗口前置操作（调用InputUtil的ensure_foreground_and_topmost）
本地测试
问题分析
正如在 MaaEnd/MaaEnd#2231 中提到，SceneAny识别登陆界面会进入点公告的节点，而纯识别节点并不会触发窗口前置，导致若窗口遮挡住MaaEnd的”公告“将永远卡死在识别节点。
可能的解决办法
故采用了最保守的修法，在连接控制器时前置一次。
潜在问题
改动后前端窗口，会在启动后直接被Endfield遮挡。对于proxy用户可能无所谓，但是会给手动用户带来不好的体验（X）
更无感的修法，罗列在上面了（
Summary by Sourcery
改进：
Original summary in English
Summary by Sourcery
Enhancements: