Blog · Inventor · 1 Oct 2026 · 4 min read
How to run an iLogic rule from outside Inventor, from a script or an AI agent
The iLogic automation object is there, but from VBScript every call that takes a document fails. The bridge that works in Inventor 2025: a VBA macro that loads the rule from a file and runs it, and a launcher that starts the macro safely. Steps, code, failures and guardrails.
Short answer: in our tests on Inventor 2025 you cannot call iLogic directly from an outside script. What works is a two-part bridge: a VBA macro inside Inventor that reads the rule from a file, pastes it into the document and runs it, plus a launcher that starts that macro from the terminal. The AI agent edits a text file and runs one command. Inventor does the rest.
Why the direct route fails
You can reach the iLogic add-in over COM:
Set oAddin = oApp.ApplicationAddIns.ItemById("{3bdd8d79-2179-4b11-8a5a-257b1c0263ac}")
Set iL = oAddin.Automation
Then every call that takes an Inventor.Document fails:
| Call, from VBScript | Result |
|---|---|
iL.AddRule(doc, name, text) |
Invalid procedure call or argument (err 5) |
iL.RunExternalRule(doc, path), by full path or by name |
same error |
| The same calls from an early-bound C# bridge | E_NOINTERFACE on the cast |
| Running a VBA macro as a command definition | VBA macros are not exposed as ControlDefinition |
The same calls work inside the Inventor process. So the job is to get code running inside Inventor.
The bridge, step by step
- Keep the rule as a text file (
rule.iLogicVb). The agent edits only this file. - Import a VBA module into Inventor's application VBA project over COM, from a
.vbsscript (oApp.VBAProjects→VBProject.VBComponents). - The macro runs inside Inventor. It reads the file, writes the text into a rule on the active document, checks it, and runs it.
- A launcher starts the macro from the terminal and waits for the result.
- The rule writes a log file. The agent reads the log, not the screen.
The core of the macro:
Set oAddin = ThisApplication.ApplicationAddIns.ItemById("{3bdd8d79-2179-4b11-8a5a-257b1c0263ac}")
If Not oAddin.Activated Then oAddin.Activate
Set iL = oAddin.Automation
Set r = iL.GetRule(oDoc, RULE_NAME)
If r Is Nothing Then Set r = iL.AddRule(oDoc, RULE_NAME, "")
r.Text = sTxt ' text read from rule.iLogicVb
If Len(r.Text) <> Len(sTxt) Then ' pasted text must match the file
Log "STOP: length differs, not running"
Exit Sub
End If
res = iL.RunRule(oDoc, RULE_NAME)
The length check matters. If the pasted rule is not the file you wrote, running it runs something you did not review.
The launcher
The macro has to be started from Inventor's Macros dialog. Our launcher is a PowerShell script that brings Inventor to the front, opens the dialog with Alt+F8, types the macro name and presses Enter.
Sending window messages to the dialog instead (CB_SETCURSEL, WM_COMMAND) was tried first. The dialog state got scrambled. Keystrokes are reliable, but only with guardrails, because keystrokes go to whatever window has focus:
- With a large multi-body part open, stray letters inside Inventor are modelling shortcuts.
- Once, an Enter meant for Inventor landed in a Word document.
Guardrails the launcher must have
| Check | Why |
|---|---|
After Alt+F8, confirm the foreground window is titled Macros, or abort |
Otherwise the keys go to the model, or to another program. |
| Press Enter only if the Run button is enabled | A disabled Run button means the macro name was not recognised. |
Find the right Inventor through Application.MainFrameHWND |
With two Inventors open, Get-Process returns an array. |
Skip windows that are reported visible but are not, such as a dialog titled AIP Migration Errors |
Inventor keeps it around and it fools the "is a dialog open?" check. |
| Make every launcher parameter mandatory | A missing PowerShell parameter was silently ignored, and the launcher ran the wrong rule. |
| Abort if a modal window is open in Inventor | The macro cannot start behind it. |
Two traps after the first success
The VBA module does not survive an Inventor restart. Import it again every time Inventor starts. A launcher that finds no macro must say so, not type into the void.
The rule's closing message box blocks the next run. It cannot be closed from outside: neither keystrokes nor BM_CLICK worked. The fix: the launcher writes a flag file, and the rule skips the message box when the flag is there. The summary goes to the log instead.
Do and don't
Do
- Keep the rule in a file under version control. The rule inside the document is a copy.
- Compare the pasted text with the file before running.
- Log to a file and have the agent read it.
- Check the target window before every keystroke.
Don't
- Don't send keystrokes without checking the foreground window.
- Don't leave a message box at the end of a rule run by a script.
- Don't assume the macro is still loaded after a restart.
- Don't launch again while a run is still going.
Questions people ask
Why not run everything as an external VBScript and skip iLogic? Many jobs do run that way: driving Inventor from the terminal. Drawing creation stays in iLogic because it runs in-process, with the full API and none of VBScript's limits.
Is SendKeys not fragile? Without checks, yes. With the checks above, the launcher stops instead of typing into the wrong window. Aborting is the expected failure, and a safe one.
Does this work in other Inventor versions?
We tested it on Inventor 2025 only. Test the direct route on your version first: if RunExternalRule works for you from outside, you do not need the bridge.