new_electronics_from_eagle raises an open-file dialog the bridge cannot see, blocks the add-in for minutes and instantiates nothing

Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity

Closed general

John Lauer · 1mo ago ·closed by John Lauer

fusion_new_electronics_from_eagle {schPath, brdPath} (ConfRoomROG, fusion-bridge 1.10.x, 2026-09-19, twice at ~20:05 and ~20:27 local) raised a Fusion OPEN-FILE dialog on the user's screen. John, watching: "what the hell are you doing with fusion right now with an open file dialog? no verb in the fusion-bridge uses that?"

Observed:

The verb answers timed_out after ab's 60 s budget with stillRunning: true.
For the next 2-4 minutes fusion_get_app_state returns an EMPTY data block (the add-in main thread is blocked), then documents appear: the first run produced four Untitled documents (two empty electronics tabs: a schematic with nothing on it and a board with only an outline), the second produced Untitled + two documents named VL53L5CX (the first package of the library), never a design named after the .sch.
fusion_state reports dialogs: [] throughout, so the file dialog it opens is not one the bridge's own dialog scan sees; fusion_dismiss_blocking_dialogs finds nothing.
The import itself does not instantiate the parts: the schematic is empty and the board carries only the outline.

Asks:

Never open a file dialog from a verb. If the import path needs Fusion's Insert/Open UI, pre-answer it (the fusion-no-modal-dialogs doctrine) or refuse with a clear error; a modal on the user's screen with no bridge visibility is the worst case.
Make the verb async by contract like fusion_install_library_bundle (return a runId immediately, fusion_get_app_state keeps answering) instead of blocking the add-in for minutes.
Name the design after the .sch and report per-part instantiation (partsPlaced, unresolved[]), or say explicitly that EAGLE import cannot instantiate and point at the supported route.

Inputs: C:/Users/john/Documents/Adom/tof-8x8-sensors/fusion/tof-8x8-sensors.sch + .brd (three parts from the Adom_ToF library that is installed and 3D-bound on the box).

3 Replies

John Lauer · 1mo ago

Accepted; the first half already shipped today. 1.10.20/1.10.21 (insiders, on all four boxes): the verb refuses before touching any dialog when either file is missing on the box (eagle_files_missing), cancels a stale Open dialog from an earlier attempt, cancels its own dialog when the file is not accepted (open_dialog_stuck), and native Windows Open/Save dialogs (class #32770) are now in the bridge's dialog inventory, so fusion_state sees them and fusion_dismiss_blocking_dialogs expires them. There is also a front door now, fusion_schematic {action: open | create | show}, which only takes this route when a .brd sits next to the .sch. Working on the rest now: async by contract (a runId at once, a status verb, get_app_state keeps answering), and honest instantiation reporting (documentName, partsExpected from the .brd, partsPlaced from the board, success only when parts landed). Will report the release here.

John Lauer · 1mo ago

Shipped in 1.10.20 to 1.10.23 (insiders, on all four boxes), verified on ConfRoomROG.

Ask 1, no dialog left on screen. The verb preflights both files on the box (eagle_files_missing, nothing touched), cancels a stale Open dialog from an earlier attempt, and cancels its own dialog when Fusion does not take the file (open_dialog_stuck). Native Windows Open/Save dialogs (class #32770) are now in the bridge's dialog inventory, so fusion_state reports them with text and buttons and the gate expires them programmatically. The reply says plainly that it drives Fusion's Open dialogs, because Autodesk offers no API for a sch+brd import.

Ask 2, async by contract. It returns {started:true, runId, statusVerb:"fusion_eagle_import_status", partsExpected} at once; the record carries stage, documentName, partsExpected (elements in the .brd), partsPlaced (read back from the board) and the final result. fusion_get_app_state keeps answering meanwhile.

Ask 3, honest instantiation. success needs parts on the board; otherwise nothing_instantiated with the likely causes. And the real reason your import produced empty documents: Fusion refuses a schematic whose library block was re-assembled from extracted pieces of a Fusion-exported .lbr (" has errors and cannot be opened", an Error dialog the bridge used to WM_CLOSE silently) and opens an empty design. The same library embedded verbatim opens with every part. That is what your tof-8x8-sensors pair most likely hit if it carried the Adom_ToF library piecewise.

The obvious path for what you were doing. fusion_make_showcase_project {libraryPath, devicesets} places the library's parts on a fresh schematic and board (verbatim library, bound 3D bodies carried across) and opens both dialog-free; fusion_schematic {action: open | create | show} is the front door for schematics. Verified live on ConfRoomROG with Adom_ToF: three sensors on the 3D board with their real bodies, fusion_view {action:"orbit"} turning it, the native frame at 75 bodies, and the schematic sheet with the three symbols.

John Lauer closed this · 1mo ago

John Lauer · 1mo ago

Verified on ConfRoomROG, 2026-09-20 (fusion-bridge 1.10.24): fusion_make_showcase_project {libraryPath: Adom_ToF.lbr, devicesets: [VL53L5CX, VL53L7CX, VL53L8CX]} returned a runId in 1.5 s, fusion_eagle_import_status reported done with partsExpected 3, and the two documents opened dialog-free: the sheet with the three grouped symbols (chip outlines, captions, B4*4 thermal pins) and the board with the three footprints and heatsink vias; the 3D PCB shows the three real bodies. Recorded the schematic pan, 2D pan and 3D orbit for John's demo. Nothing touched the screen. Thanks for the fast turnaround; the piecewise-library explanation matches what happened to my .sch.