Closed general

Document verbs steal the foreground (open/close/place_on_sch/install_library/agent restart); a background panel-tab verb

John Lauer · 1mo ago ·closed by Colby Knox

Measured on ConfRoomROG (ADDevelop, altium-bridge 0.2.15/0.2.16, 2026-09-19) while John was typing in Hydrogen on the same box: every few calls Altium jumped in front of his window and took the keyboard. His words: "why do you always have to force altium to the foreground when you're tweaking these symbols ... it really disrupts my ability to type in the ah app".

The capture verbs behave (show_symbol / show_footprint / show_3d_chip / show_schematic / show_3d_board restore INTO the background and hand focus straight back; shot.rs). The steps that raise the window are the document ones:

  • altium_open_document, altium_close_document
  • altium_place_on_sch (CreateNewDocumentFromDocumentKind + Client.ShowDocument)
  • altium_install_library (opens the library)
  • altium_agent_stop / altium_agent_start (script execution activates the main window)
  • altium_run_command with Sch:Zoom / PCB:Zoom

Ask: the same etiquette as the capture verbs on every verb that opens, creates or activates a document: record desktop_get_foreground before, do the work, and if Altium's hwnd took the foreground, hand it back (desktop_set_foreground on the recorded hwnd) before replying. A windowEtiquette field on each reply so the AI can see whether the user's window was disturbed. Until then the AI hint should say: batch the document work, and stop touching Altium the moment the proofs are in.

Related wish from the same session: the "ganged-up view" John likes (symbol on canvas + 3D chip in the Editor panel preview + the footprint preview in the SCH Library panel). There is no server process that activates a docked panel TAB (Client:CustomizeResources Action=Show|ObjectKind=Panel|ID=TSchLibPanel only makes sure the panel exists); a panel {id, action: show|focus} verb (UIA on the dock tab, background, no foreground steal) would make that view a one-liner.

3 Replies

Colby Knox · 1mo ago

Built and HELD (same hold as #11's append - see there for why: expired licence on the test box, nothing serves untested).

In the archived 0.2.40:

  • Foreground etiquette on EVERY driving verb, at the dispatch chokepoint (one wrapper, not per-verb calls someone forgets): the window the user is in is recorded before each driving verb; if Altium's process holds the foreground afterwards where it did not before, the user's window is handed straight back, and the reply says so (windowEtiquette: background, foregroundReturnedTo on a reclaim). A user deliberately on some other window mid-verb is left where they went; foreground/launch/demo/install/close are exempt (launch got its own hand-back in 0.2.37). This covers every steal you listed: open/close_document, place_on_sch, install_library, agent start/stop, run_command Zoom.
  • The ganged-up view: new verb altium_panel {name, ensureId?} - UIA SelectionItemPattern on the dock tab (a plain click does not switch tabs, measured), InvokePattern fallback, verified by reading the tab's own selection state, no foreground steal. Honest failure modes: ui_select_gated while ab keeps desktop_ui_select behind the shell grant (adom/adom-bridge#123), panel_not_selected with the attempted lanes otherwise.

What IS live-verified from the aborted run: the wrapper survived contact on 0.2.40 (launch + two driving verbs answered normally with the etiquette fields present) before the licence wall. The full proof (a steal actually reclaimed mid-typing, the panel select) waits for a licensed box; open until then.

Colby Knox · 28d ago

Status update: code complete, not closable yet. John ran the licensed test of the held 0.2.41 (see #13). Everything in it passed except altium_panel, which timed out. The fix is staged as 0.2.42 (release asset only; both tiers still serve 0.2.39). We no longer have a licensed Altium, so this issue closes on John's arav-rog battery run of 0.2.42. The exact checks that prove this issue are listed at the end of #13.

Colby Knox · 6d ago

Verified live in 0.2.45 (insiders): with Chrome in front, document opens and an agent restart left the focus on Chrome, and every driving verb reports windowEtiquette. On the panel half: no Altium process switches a docked tab (Client:CustomizeResources Show/Toggle only ensures the panel exists, A/B tested), and a UI Automation search of the main window takes over 20 s on Develop, so altium_panel cannot switch tabs there; it says so instead of hanging. Opening a library already brings its panel (SCH Library / PCB Library) to the front, which covers the ganged-up view.

Log in to reply.