app

SOLIDWORKS Bridge

Public Made by Adom

by adom

Launch, model and quit SOLIDWORKS from any Adom container. Nothing is ever lost.

solidworksmcadcadbombridgeabadom-bridgedesktop-app
Overview Files Skills Discover Packages Releases Dependencies Issues2 Breadcrumbs Pull Requests Activity
main
solidworks-bridge / skills / solidworks-sign-in / SKILL.md
History Download
Drew Owens 0.9.28 source 0dac61e 9d ago

name: solidworks-sign-in description: "How to get through the 3DEXPERIENCE ID login that SOLIDWORKS and SOLIDWORKS Visualize raise when the platform session has lapsed - where the window comes from, how to find it, the measured two-page flow, what to type with and what never to touch, and where the login comes from (never from this skill). Use when a SOLIDWORKS launch is waiting on a sign-in, when swx_status says waitingOn userSignIn, or when a License Manager notice says it failed to check a license. Trigger words - solidworks sign in, 3DEXPERIENCE login, sign me in, login window, License Manager failed to check license, session expired, Visualize login." user-invocable: true

Parent skill: solidworks-bridge

Every line below is marked [measured] (seen on a real machine, 2026-10-02 to 2026-10-12) or [unmeasured] (not seen yet — treat as a guess and read the window first).

When the window appears

  • [measured] It appears when the 3DEXPERIENCE platform session has lapsed. It did not appear on about fifteen launches on 09-30 and 10-01, then appeared on 10-02 after licence checks failed overnight.
  • [measured] A session that is already running shows the warning first: a "License Manager" notice, "Failed to check 1 license(s): 3DEXPERIENCE SOLIDWORKS Professional: Unable to connect to server. The session will end after the next 5 unsuccessful attempts.", OK only. Notices can queue (two identical ones). The bridge never answers them.
  • [measured] Visualize asks only when it is started the wrong way. Started directly from SLDWORKSVisualize.exe (2026-10-02) it raised its own sign-in even while SOLIDWORKS was signed in — and on this edition that start is refused anyway ("must be opened from the 3DEXPERIENCE Platform or from the desktop shortcut created from the Platform"). Started through its platform shortcut (swx_start {app:"visualize"}, 2026-10-05) while the 3DEXPERIENCE Launcher already held the session, it raised no login at all.
  • [measured] After a week away (2026-10-12) the platform session had lapsed. Starting Visualize through its shortcut started SWXDesktopUpdate.exe (from %TEMP%\SWXDesktopUpdate\) the same second, and THAT showed the sign-in; Visualize itself did not start until the sign-in was done. Any app start can be parked behind it.

Finding the window

  • [measured] SOLIDWORKS's launcher shows it: class DSYSysLoginPanelWebView2Class, title "Login | 3DEXPERIENCE ID | Dassault Systèmes", owned by SWXDesktopLauncher.exe.
  • [measured] Visualize shows the same web page in a WinForms window: title "Login - 3DEXPERIENCE ID - Dassault Systemes", 968x968.
  • [measured] A THIRD host: SWXDesktopUpdate.exe, the platform updater. Title just "3DEXPERIENCE" (no "ID", no "Login"), class WindowsForms10.Window.8.app.0.30495d1_r6_ad1, UIA automationId SWXDesktopUpdateForm. Same web page ("Welcome to the 3DEXPERIENCE platform", "Email or username", "Continue"), and no cookie banner, only a "Manage cookies" link at the bottom right.
  • FIND IT BY CONTENT, not by title. A window that contains an Edit "Email or username" (page 1) or an Edit "Password" (page 2) is a 3DEXPERIENCE ID login, whatever its title, class or owner. The two titles above are only shortcuts. swx_status reports waitingOn: "userSignIn" and signInWindow {hwnd, title, ownerImage, host, recognizedBy} (host is solidworks, visualize or desktopUpdate) while any of them is up. Both sit at the TOP level of the swx_status reply, next to each other, not inside its solidworks block. The visualize block repeats signInWindow only while Visualize is parked behind the sign-in (parkedBehind).

When the tree shows only the frame

  • [measured] On the SWXDesktopUpdate host, desktop_ui_tree returned 14 nodes (Window, MenuBar, Minimize/Maximize/Close), even with maxNodes 600 and depth 40, and even after a desktop_ui_from_point wake. The page is not in it.
  • [measured] desktop_find_control {hwnd, ...} DOES reach the page. Page 1: {automationId:"username"} or {role:"Edit", name:"Email or username"} gives the Edit (settable:true); {role:"Button", name:"Continue"} gives the button (invokable:true).
  • [measured] Page 2: Edit username (prefilled); Edit password whose NAME is "Password " plus an icon glyph, so {role:"Edit", name:"Password "} does NOT match it and {automationId:"password"} does; Text "Password" (its label); Text "Remember me" (no CheckBox found by name); Button "Log in"; Button "Back".
  • [measured] {role:"Edit"} with no name matched "Address and search bar" (view_1012), a control somewhere else entirely. Never query a role alone. Look up by automation id first, then role and exact name, then role and name-contains, and check the match's role and id or name before using it.
  • [measured] desktop_ui_set {hwnd, automationId:"username", text} WORKS on this host (ValuePattern accepted), unlike the Visualize host. But the first set left the user name followed by a stray "s". Set "" first, then the value. That fixed it.
  • [measured] The tree has two states on this host. COLD it is the frame only (14 nodes). After any desktop_find_control or desktop_ui_from_point probing it stays AWAKE at about 37 nodes, with the whole page: on page 2, Edit username (prefilled), Edit password, a real CheckBox "Remember me " (on screen, settable, with a toggle pattern), Button "Log in", Button "Back", and links "Forgot your password?", "English", "Help", "Manage cookies". Read the tree first; fall back to desktop_find_control when it is cold.
  • [measured] PAGE 2 IS THE PAGE WITH THE PASSWORD BOX, whatever else is on it. The user-name box is there too, prefilled and READ-ONLY: a set answers "Cannot call SetValue on read only value". Leave a prefilled name alone, take a read-only refusal to mean "prefilled", and never let the name step block the password step.
  • [measured] A "Manage cookies" LINK is page furniture, not a cookie banner. A banner has accept/reject BUTTONS ("Accept All", "Manage my preferences", as on the Visualize host). A failed set is never evidence of a banner. Tell the user about a banner only when one is really there.
  • [measured] desktop_find_control's reply carries NO value, and the tree has no page, so on this host the user name cannot be read back. swx_sign_in says readBack: "unreadable" in its steps rather than claiming a match.
  • [measured] desktop_ui_click {hwnd, name:"Continue"} (background Invoke) moved to page 2.
  • [unmeasured] Whether a background toggle ticks "Remember me" here. The bridge tries the Toggle pattern, then an Invoke, reads the box's state back, and claims a tick only if the box says so. When the tree is cold and only a label is found, it clicks the label (user idle, window in front) and reports rememberTicked: null.
  • [unmeasured] What this host shows after "Log in": a wrong password or a second step. Read it; never retry.

The flow

  1. [measured] The accessibility tree is LAZY. The first desktop_ui_tree read gave 13 nodes with one control (Button "Close"); after one desktop_ui_from_point query on a point inside the page, the same read gave 38 nodes with the form. Wake it before deciding anything.
  2. [measured] Page 1: Edit "Email or username" (automationId username) and Button "Continue". There is NO password box on page 1.
  3. [measured] desktop_ui_set on that Edit is refused ("control found but has NO ValuePattern"), even though the tree says settable: true. Typing needs real keystrokes: desktop_click on the box, desktop_press_key ["ctrl+a"] (a failed attempt leaves the box dirty), then desktop_type. Each one needs a reason, and each takes focus (the login window comes to the front).
  4. [measured] desktop_ui_click {name: "Continue"} works in the background.
  5. [measured] Page 2 (after a good page-1 fill and Continue): Edit "Email or username" (prefilled), Edit "Password " (automationId password), CheckBox "Remember me " (off), Button "Log in", Button "Back", and the cookie banner still there.
    • [measured] The "Remember me" checkbox's own input is OFF-SCREEN (its rect centre is far left of the screen). The visible control is its Text label "Remember me…": click the LABEL to tick it, then read the toggle state.
    • [unmeasured] What the page shows after "Log in" (a wrong password, a second step). Read it; never retry.
  6. [measured] A cookie banner sits on the page ("Accept All", "Manage my preferences"). Never touch it: that choice belongs to the user. In the measured layout it does not cover the form.

Geometry and focus

  • [measured] Moving the window RE-LAYS the page: the cookie banner then covered the email box, a click at the old point hit the banner, select-all selected page text, and the typing went nowhere. After any move or resize, re-read the tree and click at the control's OWN rect.centerX/centerY (screen pixels). desktop_set_window_bounds {hwnd, x:300, y:30, w:1100, h:1450, reason} kept the box clear of the banner (email box at y=787, banner at y=1020).
  • [measured] A plain click does not take focus while the user's own app is active. desktop_raise_window {hwnd, reason} brings the login window forward; confirm it IS the foreground window before typing.
  • [measured] Typing lands when sent to the page's render widget (a Chrome_RenderWidgetHostHWND child window). Reading the user name back from the tree works.
  • [measured] Typing a password through ab from a cloud container is refused by policy ("Credential Leakage"), and rightly. The only acceptable path is the bridge reading the vault on the desktop and typing there: swx_sign_in.

Rules that never bend

  • [measured] NEVER send keystrokes while the user is typing. On 10-02 keystrokes sent while the user typed in another window left fragments of THEIR typing in the login box, and the intended text did not land. Check swx_user_presence (seconds since last input) first, and bring the login window to the front and confirm it is in front before every keystroke batch.
  • Read the user-name box back after typing and compare before pressing anything. Never read the password box back.
  • Never retry a rejected password; an account lockout is worse than a manual sign-in.
  • A second factor (a code, a captcha, a new-device check) is the user's to answer. Tell them; do not try.

Credentials

Where the password comes from, and who is allowed to touch it — all measured on 2026-10-12 on a real login window (ab 2.1.174, bridge 0.9.26):

  • The login lives in the Adom Bridge vault on the user's PC (pup_credentials {} lists hosts + user names, never a secret; the 3DEXPERIENCE host is iam.3ds.com). You never write a password into this skill, the bridge, a reply, a log or a screenshot — [measured] every value that leaves the bridge is scrubbed of it; [unmeasured] whether any ab verb can read a typed value back on the updater host.
  • The bridge prepares the page and stops. swx_sign_in {userAuthorized:true, window:<hwnd>} fills the user name from the vault's listing, presses Continue, reaches the password page, asks the vault ONCE for the password — and ab refuses a bridge: "pup_credential_reveal requires a VERIFIED local transport … this request arrived with origin "bridge"". The reply is sign_in_vault_policy with ab's words (abSaid), pagePrepared {page:2, userNameFilled:true} and waysOut. Nothing is retried, nothing is worked around. ab issue #237 asks for a fill verb (ab sets the control itself, the secret never leaves ab); until it lands the password step is outside the bridge.
  • A cloud agent cannot type it either. Sending the password through ab from a container is refused by the agent's own policy (measured twice: typing it directly, and starting a local helper that would reveal it). Do not retry by any route; do not ask the user to paste it into chat.
  • What works today: a LOCAL caller. ab hands a vault secret to a local desktop assistant (its bundled CLI on the same PC, Hydrogen, a local agent or script) behind one consent card. tools/local-sign-in.ps1 in this page's repo is that assistant: run it ON the PC that shows the login (double-click, or powershell -ExecutionPolicy Bypass -File local-sign-in.ps1); it finds the window through swx_status, asks the vault (ab's consent card appears), sets the password into the box by automation id, ticks Remember me, clicks Log in and verifies the window is gone. It never prints the secret. Tick Remember me so the platform session persists and the window stops coming back every couple of weeks.
  • The user may instead type the password into the prepared window; the bridge reports pagePrepared so an agent can say exactly that.