Using the app

A walk through the window, panel by panel, in the order they appear on screen.

Opening and closing it

Start SwMacroFlow from the Start menu. The whole window opens straight away, with no connection behind it - you can build a complete batch before SOLIDWORKS is involved at all.

The header carries a dropdown listing every SOLIDWORKS installed on the machine plus any that are already running. You do not have to connect from it. Set up the batch, press Run Batch, and the run connects to whatever is selected there - joining a running instance, or starting one, which can take a couple of minutes from cold. Connecting by hand first is still there if you want to watch it happen, or to check that a macro compiles before you commit to a run.

If the connection fails, the reason appears next to the Run button and nothing is run. The usual cause is that one of the two programs is running as administrator and the other is not; start both the same way. See Troubleshooting.

SOLIDWORKS stays usable while SwMacroFlow is open - they are separate programs, and neither blocks the other.

If the session drops, the next run simply connects again. The only connection state that keeps the Run button down is a machine with no SOLIDWORKS on it at all, which reads No SOLIDWORKS installation was found on this machine.

SwMacroFlow opens one window at a time. Starting it again while it is open brings the open window to the front instead of opening a second one.

A scheduled batch is the exception. Windows runs it in a window of its own, so it still runs if you left SwMacroFlow open. Only one batch runs at a time, though. A scheduled batch that fires while another batch is running waits for it to finish - for up to 4 hours, after which it is recorded as blocked and does not run. While a scheduled batch is running, Run Batch in your window tells you which one and when it started, and runs nothing; try again when it has finished. The line under the header shows a scheduled batch that is running or waiting, and the schedule list picks up how it went as soon as it ends.

Closing the window closes SwMacroFlow, and with it everything you had set up: the macros, the files, the inputs, the results. It asks first if a batch is still running. If SwMacroFlow started SOLIDWORKS itself, it closes that too; if you had SOLIDWORKS open already, it is left exactly as it was. Use Reset when you want a clean slate without closing anything.

The header

Buttons top right (and the connection / instance controls when they apply):

MACROS

There are three ways to add a macro, and they behave identically:

• Add Macro... browses for a .swp. Select several at once and they all join the chain, in the order the dialog lists them.
• From Library drops down the macros that ship with SwMacroFlow - pick one and it is added without browsing.
• Drag a .swp from File Explorer onto the window. Drop several together, or mix them with SOLIDWORKS files and each goes where it belongs.

None of them needs a connection. If SOLIDWORKS is not connected yet, SwMacroFlow reads the macro file directly so you can fill in its inputs. Every macro is still compiled through SOLIDWORKS before it can run - that check just happens later now: the moment you connect if you connect by hand, and otherwise as the first step of the run itself. Anything you typed is kept across it either way. Disconnecting drops the check, so the next connection - perhaps to a different SOLIDWORKS - runs it again.

The library is the folder %LOCALAPPDATA%\SwMacroFlow\macros. Dropping a .swp there yourself makes it appear in From Library the next time you open the menu - no restart required. (If that folder cannot be written, the app falls back to the install copy for listing only.)

The folder button beside From Library opens that folder in File Explorer, so you can drop a macro in without going looking for the path. It works whether or not the library has anything in it yet, and creates the folder the first time if it is not there.

Each row in the list has:

• A checkbox. Unticking leaves the macro out of this run without discarding its inputs. Untick it, run, tick it again later and everything you typed is still there.
• ↑ and ↓ to change the order. Reordering does not disturb the values you have typed.
• ✕ to remove the macro from the chain, along with its inputs.
• A ! glyph when something is wrong with it. Hover for the reason.

Below the list: Keep running the other macros if one fails on a file - see When a macro fails below.

The list order is the run order. The same macro can be added twice: exporting as STEP and then again as PDF is one macro with two sets of inputs, so add it twice and give each row different values.

INPUTS

Click a macro in the list to see its inputs. The panel shows one macro at a time and names which one at the top. The section hides itself when the selected macro declares none.

Inputs are declared inside the macro itself - see Adding inputs. SwMacroFlow reads them when the macro loads and builds a matching control:

Inputs never leak between macros. Two macros that both declare @Name each get their own value.

Property placeholders in values

On String, FilePath and FolderPath fields you may type {PropertyName} mixed with ordinary text - for example {PartNumber}_{Revision}.pdf. Those tokens are highlighted magenta as you type.

They are resolved per document when that file runs, from the open document's custom properties (active configuration first, then file-level). A missing property fails that file with a red row; it does not expand to empty. Integer, Bool and Option fields do not take property tokens.

{FileName} is the one reserved name - it always resolves to the document's filename, not a custom property. Full rules are in Adding inputs.

Do not use {Property} values when Run once without opening any files is ticked - there is no document to resolve against. Full rules are in Adding inputs.

Validation

Inputs are validated before the run starts, on purpose. A mistyped template path would otherwise fail every file in the batch, one slow open-and-close at a time.

• Blank is always allowed.
• A non-blank number must parse.
• A non-blank FilePath must exist, unless it contains {Property} tokens (then only brace syntax is checked).
• A FolderPath need not exist - macros often create it.
• Malformed braces in a free-text value block Run.

WORKFLOWS

A workflow is the macro chain and the values typed into it, saved under a name so that next week you can bring the same setup back instead of rebuilding it.

It does not save the files in scope. The panel says so under the heading - Saves the macro chain and the values typed into it. Not the files in scope. That is the point rather than a limitation: a workflow is the work, not the batch. Apply it, then point it at whatever folder you have this time.

Saving one

Two buttons sit in the MACROS header row: Apply a saved workflow and Save this macro chain as a workflow.

Build the chain, fill in the inputs, then press Save this macro chain as a workflow. A SAVE WORKFLOW box drops down: type a name and press Save.

The box is pre-filled with the workflow you last applied, so re-saving the one you have been editing is what happens by default. Names are matched without regard to case: typing the name of a workflow that already exists asks whether to overwrite that one, and answering no leaves the box open so you can type a different name.

Three things stop a save, each saying so in the box:

A workflow whose chain points at a .swp outside the macro library still saves, with a warning:

> This workflow points at macro, which is outside the macro library, so it will stop working if > that file is moved.

A workflow stores where each macro is, not a copy of it. Macros in %LOCALAPPDATA%\SwMacroFlow\macros stay put; one you dragged off a network share is only as reliable as that share.

Applying one

Apply a saved workflow, in the MACROS header row, picks one and brings it back. The same workflows are also listed under Settings → Workflows by NAME, MACROS and SAVED, where Apply into the setup on a row does the same thing.

Applying replaces the whole chain and every input value with the saved ones. You are only asked to confirm when there is a chain to lose - applying onto an empty panel just happens. Your files, your scope and your results are not touched either way.

A batch that is running blocks it, with A batch is running. Wait for it to finish.

If a macro in the saved chain is no longer on disk, the workflow still applies - without it - and says so:

> Workflow name was applied without macro, which is ticked in the saved chain but no longer on > disk. This chain will not do what the workflow did. Dismiss this to run it anyway.

Read that one before dismissing it. The chain will run. It is just shorter than the one you saved, and the step that went missing is often the one that did the work.

Renaming and removing

Both are under Settings → Workflows. Rename by typing over the name in the row. Two workflows cannot share a name - Another workflow is already called "…" - and a blank name is refused with A workflow needs a name.

Delete this workflow asks first, and deletes only the saved chain; the .swp files it pointed at are left alone.

Workflows live in %LOCALAPPDATA%\SwMacroFlow\workflows.xml, with one file per chain in the workflows folder beside it.

SCOPE

Four ways to put files in scope:

• Browse Folder... scans a folder. Include subfolders decides how deep (off by default).
• Add Files... picks individual files.
• Drag and drop files or folders onto the panel.
• Remove Selected, or the Delete key, takes them out again.

Only .sldprt, .sldasm and .slddrw are recognised.

Files land in three lists - Part, Assembly and Drawing - each with its own checkbox. The checkbox filters what actually runs. A file in an unticked list is still in your list; it is just not in scope for this run.

Run once without opening any files

Tick this when the macros do not act on a file you hand them.

• The chain runs a single time. One row per macro, titled with the macro rather than a file.
• The Part / Assembly / Drawing checkboxes clear and grey out, along with Browse Folder, Add Files, Remove Selected, Include subfolders and drag-and-drop. Nothing on screen offers you a scope the run would ignore.
• Your file list is not thrown away. Untick the box and it comes back, with the type checkboxes exactly as you left them.
• Inputs, validation and reporting all work exactly the same - except {Property} placeholders cannot resolve without a document.
• The skip rule still applies: a chain is a chain whether or not a document is involved.

Your macro must not rely on ActiveDoc in this mode - there is no active document, so it will be Nothing.

When a macro fails on a file

By default the macros after it are skipped for that file, and the batch moves to the next file. Their rows say so, and name the macro that stopped them. The next file starts the chain clean.

That is usually what you want. An order you arranged tends to mean a dependency - the second macro reads what the first one set - and closing a document discards unsaved changes, so stopping throws away a half-finished edit rather than letting a later macro save one.

Tick Keep running the other macros if one fails on a file when your macros happen to share a document but not a purpose, and each should get its turn regardless.

An amber row - a partial success, or a prompt the batch answered - does not stop the chain. Only a real failure does.

Running, and stopping

Run Batch starts the job. In run-once mode the button reads Run Once instead.

Two things happen before any file is opened, and the button reads Starting... through both:

1. Connect. If there is no session yet, the run connects to the instance selected in the header, starting SOLIDWORKS if it is not already running. If that fails, the reason appears and nothing is run.
2. Compile. Every ticked macro is loaded through SOLIDWORKS, which compiles its VBA project and checks it has something runnable in it. If they all pass, the batch starts.

If a macro does not compile, SwMacroFlow stops and asks, naming each macro and the error it gave. Continue runs the rest of the chain without them - they stay in the list, still ticked, so the next run tries them again. Abort runs nothing. If nothing in the chain compiles there is no question to ask, and the run is abandoned.

The panel and the instance dropdown are locked from the click until the batch is handed over, so the run is against exactly the setup that was on screen when you pressed the button.

The window stays responsive while it runs - the batch happens on its own thread, so the results and the log fill in live and every button keeps working. Cancel stops the run after the macro in progress finishes - never mid-macro, so nothing is left half-written. You do not have to wait out the rest of a file's chain. Ctrl+Shift+Q does the same thing when the SwMacroFlow window has focus.

A big batch is bounded by how fast SOLIDWORKS opens and closes documents, not by SwMacroFlow.

RESULTS

Every macro-file pair gets exactly one row, showing the most severe thing that macro reported for that file:

Each row carries the macro name under the file name, so a chain's rows can be told apart. The list scrolls to the newest row as the batch runs.

LOG

The log panel is collapsible and shows every message, not just the one that made it onto the row, in the order they happened. It keeps the last 500 lines on screen.

• Copy puts the whole visible log on the clipboard.
• Clear empties the panel. It does not touch the file on disk.
• The folder at the bottom of the panel is where the log files are written, one per day, named logger_<date>.log. Thirty days are kept. The folder is %LOCALAPPDATA%\SwMacroFlow\logs, beside your macro library rather than inside the install folder, so uninstalling does not take the logs with it.

When Run is greyed out

The reason is written next to the button. It is always one of these:

A FolderPath that does not exist yet does not block Run - macros commonly create it.

What leaves the machine

Nothing about your work - unless you turn the Copilot on.

The app itself transmits nothing. No file name, no macro, no result, no log line. Two things do go out on their own, both of them small:

Both are plain downloads: they ask for a file and read the answer. Neither sends anything about you, this machine, or your work. There is no usage tracking and no install identifier of any kind.

The Copilot is the exception, and it is a real one. It is off until you enter an API key, and it sends nothing before then. Once configured, what you type, any file you attach, and whatever it reads while answering - macro source, the file list, results, log lines, your settings - is sent to the provider you chose. Four of the five providers are somebody else's servers; LM Studio is a model running on your own machine, and nothing leaves it. See Using the Copilot.

If that trade is not one you want to make, leave the API key blank. Everything else in SwMacroFlow works exactly as described above.