════════════════════════════════════════════════════════════════
【定稿】「通知」对话框（组队邀请/交易确认/系统提示）完整结构
日期：2026-09-28      状态：活体实测（组队邀请框弹出时，pid 1320/15964）
════════════════════════════════════════════════════════════════

一、回答：之前找到过吗？——找到过

    0924 就定了「通知框标志」：0x01890854（十进制 25757780，常量 通知框标志值）
    =1 表示「通知」框弹出（标题"通知"、带"確認/取消"按钮的通用对话框）。
    本次活体双端复核：1320 与 15964 两个客户端框弹着时都读到 1。

    旧版辅助的处理方式（接受组队子程序）：不点按钮，遍历窗口ID 6851~6900
    看到框出现就直接发接受组队封包 000000003400060001000100。

二、今日新增：完整对象链（框弹着时活体扫描窗口管理器所得）

    窗口管理器 [0x0188C61C]（=1072487224 @1320）
      └ wm+0x404 → InterNotice 0x3FFBF190        ← 「通知」系统总对象
           ├ +0x330 → NoticeChat                  （聊天滚动通知）
           ├ +0x334 → NoticeBanner                （横幅公告）
           └ +0x338 → NoticePopup 0x3573A1C0      ← 弹窗型（確認/取消框）★
                ├ +0x330 → InterWindow 0x51621E38 （窗体本体）
                ├ +0x334 → TextBox    0x4F53A368 （消息文本："XX 邀請組隊。接受邀請嗎？"）
                ├ +0x338 → ButtonClass 0x4B86F0B0 ← 按钮1 = 確認（控件ID 7026 / 0x1B72）
                └ +0x33C → ButtonClass 0x4B86FBC0 ← 按钮2 = 取消（控件ID 7027 / 0x1B73）

    两按钮结构相同，唯一区别在 +0x0C 的控件 ID：7026=確認、7027=取消。
    按钮 +0x08 存父对象指针（= NoticePopup 0x3573A1C0），虚表 0x010F1EE4（ButtonClass）。

    ★★ 0928 13:00 交易框实测【重大更正——控件 ID 不是固定值】★★
    交易请求框弹出时双端实测（13360 旧会话的 7026/7027 只是当时的分配值）：
      pid 1320: TextBox=7025(0x1B71)  確認=7026(0x1B72)  取消=7027(0x1B73)
      pid 15964: TextBox=7028(0x1B74) 確認=7029(0x1B75)  取消=7030(0x1B76)
    控件 ID 是会话内递增分配的窗口编号，不能写死 7026！
    稳定的规律是【顺序】：TextBox → 確認 → 取消 依次 +1（確認 = 取消-1）。
    按钮位置双端一致：確認在左(x=15)，取消在右(x=237)，可作辅助判别。

    ★ 0x01890854 通用性实锤：交易请求框弹出时双端都 =1（组队邀请框同样 =1）
      → 它是「弹窗型通知」的通用出现标志，不区分内容（组队/交易/系统提示）。
      区分类型须读框内文本；旧版"见框就发接受组队封包"在交易框弹出时会误触发。

    TextBox 对象(+0x334 所指)内部前 0x200 无内联文本、指针跟两层未见中文，
    消息文本存储位置待深挖（不影响确认/取消操作，只影响"判断通知类型"）。

    ⚠ NoticePopup 对象地址每次重启会变（堆分配），固定的是链路：
      [0x0188C61C] → +0x404 InterNotice → +0x338 NoticePopup → +0x338 確認按钮

三、自动「点確認」的两条路

    路线 A（旧版已验证，推荐）：不碰按钮，直接发接受组队封包
        发包Call (机器码到字节集 ("000000003400060001000100"))
        检测条件建议从"窗口是否出现(6851~6900)"换成读 通知框标志值==1（更稳）。
        局限：只适用于"接受组队"这一种通知；交易确认等没有对应封包。

    路线 B（通用，待找事件ID）：走事件总线派发"確認按钮点击"
        同死亡回城（push 事件ID/push 9 → mov ecx,[0x188C61C] → call 0xA60480）。
        还差"通知框確認按钮"对应的事件 ID——需要框再弹出时做一次
        按钮虚表/静态代码分析（cmp 0x1B72 / 0x1B73 的分支处能挖出发送的事件号）。

四、本次顺带收获

    1. 名字表 slot6（0x03BF3A28 = 62863912）在客户端完全重启后依然精确等于
       自己角色名（15972 重启验证）→ 定稿再加固。
    2. 窗口管理器 0x188C61C 槽位全表已扫出（wm+0x200~0x600，101 个类名），
       常用槽位：+0x3AC InterMAIN / +0x3B8 InterInventory / +0x430 InterAutoPlay /
       +0x404 InterNotice / +0x4E8 InterParty / +0x4D4 InterExchange（交易）等。
    3. 教训：读内存全空先确认进程还活着（本次 15972 已退出导致连环误判）。

    脚本：_notify.py / _notifywin.py / _notice.py / _popup.py / _buttons.py
    输出：notify*.txt / notifywin.txt / noticeobj.txt / noticepopup.txt / buttons.txt
════════════════════════════════════════════════════════════════