Troubleshooting

Symptom first. Each heading is what you actually see.

"Can't reach SOLIDWORKS"

A connection attempt failed - either one you started from the header, or the one Run Batch makes on its way in. Nothing was run. The message names the reason; there are three.

"SOLIDWORKS is running but won't accept a connection." One of the two programs is running as administrator and the other is not. Windows hides elevated programs from unelevated ones, so they cannot find each other. Close both and start them the same way - normally, that means neither as administrator. SwMacroFlow deliberately stops here rather than starting a second SOLIDWORKS on top of the one you already have open.

"SOLIDWORKS isn't installed on this machine." Or it is installed for a different Windows user. SwMacroFlow drives a real SOLIDWORKS; there is nothing it can do without one.

"SOLIDWORKS didn't finish starting in time." It waited five minutes. Open SOLIDWORKS yourself, let it settle, then run again - it will join the one you opened.

Fix the cause and press Run Batch again; nothing about your setup is lost by a failed connect.

"Some macros did not compile"

The run connected, then loaded each ticked macro through SOLIDWORKS - which compiles its VBA project and checks it has a runnable Sub taking no arguments. At least one did not pass, and the message names each one with the error it gave.

• Continue runs the rest of the chain without them. They stay in the list, still ticked, and the next run tries them again.
• Abort runs nothing.

The usual causes are the same ones under A macro won't load below: VBA references the macro needs that this SOLIDWORKS does not have, a syntax error, or no Sub that can be called with no arguments. Open the .swp in SOLIDWORKS' own macro editor and press Debug > Compile to see the same error with a line number.

If nothing in the chain compiles, there is nothing to continue with and the run is abandoned without asking.

The batch seems to have stopped

Look at SOLIDWORKS. A dialog waiting for an answer blocks everything SwMacroFlow asks it to do, and a batch is unattended by definition - nobody is watching for the prompt.

Answer the dialog and the run carries on by itself; SwMacroFlow keeps retrying for five minutes before it gives up on that one file and moves to the next. The log records it after five seconds.

Your own macro's prompts are not the cause: those are answered automatically during a batch and show as amber rows. This is a dialog from SOLIDWORKS itself.

"Can't read this macro's VBA project"

Programmatic access to the VBA project is switched off. SwMacroFlow has to read your macro's source to find its inputs and its entry point, so nothing works until this is on.

In the SOLIDWORKS VBA editor: Tools → Options → Security → Trust Center → Macro Settings, then turn on Trust access to the VBA project object model. Reload the macro afterwards - remove the row and add it again.

"Macro has a compile error"

The macro is checked when you add it, by asking VBA to compile the whole project without running anything. Open it in the SOLIDWORKS VBA editor (Tools → Macro → Edit), then Debug → Compile to see the actual error.

The most common cause in a macro written for SwMacroFlow is an input declared as the wrong type. Every input must be As String, whatever its Type: metadata says:

Const Quantity As Integer = "@Quantity"   ' wrong - type mismatch, will not compile
Const Quantity As String  = "@Quantity"   ' right

"This macro has no runnable procedure"

SwMacroFlow needs a Sub that takes no arguments, preferably named main. A macro whose only procedures take arguments, or that contains only Functions, has nothing that can be called.

"… could not be prepared to run"

Before the first file opens, SwMacroFlow makes a temporary copy of each macro with your inputs filled in and its dialogs captured. When that copy can't be made, the whole batch stops. No file was opened. Running the macro without the copy is not safe: every @Name input would hold the literal text @Name, so a dry-run input would be ignored and the macro would change files.

The message says why:

• no module declares Sub main() in a form SwMacroFlow can read - put the declaration on one line, Sub main(), with nothing after it except an optional ' comment. A declaration split over several lines with _ isn't recognised.
• the file holds no VBA project - the file is not a macro SwMacroFlow can read. Open it in the VBA editor to check.
• the macro file was not found - the .swp was moved or deleted after it was added.
• anything else - the temporary copy couldn't be written under %TEMP%\SwMacroFlow, for example because the disk is full or antivirus is holding the file. The log has the details.

"This file isn't a readable VBA macro"

The file is not a valid .swp, or its VBA project is corrupt. Open it in the VBA editor to confirm. Only .swp files are accepted.

Run is greyed out

The reason is written next to the button:

A folder path that does not exist yet does not block Run. See Adding inputs.

"Scheduled batch … is running. Try again when it finishes."

A scheduled batch is running in its own SwMacroFlow window, and only one batch runs at a time. Two at once would put two SOLIDWORKS on the same files, and any file both batches touch would open read-only in one of them, so its saves would fail. Nothing was started - no SOLIDWORKS was launched and no file was opened. The line under the header shows the batch and when it started, and clears when it finishes; press Run Batch again then.

The same thing works the other way round. A scheduled batch that fires while your batch is running waits for yours to finish, for up to 4 hours.

"Fix every property placeholder in …"

Braces in a free-text input are reserved for {PropertyName} tokens. Every opening brace needs a matching close, the name inside must not be empty, and braces cannot nest. Examples of invalid values: a{b, { }, prefix_{Part{No}}.pdf.

Fix the typing, or remove the braces if you meant a literal brace character (there is no escape in v1).

Red row: property was not found

An input value contained {SomeName}, and that property was not on the open document - neither on the active configuration nor in the file-level custom properties. The batch continues with the next file; the token is not replaced with an empty string.

Check the property name (case does not matter, spelling does), and that the property exists on the configurations you actually process.

Red row: cannot resolve … no document is open

A {Property} value was used when there was no active document - typically Run once without opening any files, or a file that failed to open. Property placeholders only work against an open document in a normal batch. Use literal paths or names in run-once mode instead.

The batch has hung

Something opened a real modal dialog that nobody can click. There are only two ways this happens:

• A call written as VBA.MsgBox. The VBA. prefix binds directly to the library and cannot be intercepted. Remove the prefix.
• A UserForm. A form's dialog cannot be intercepted either. A macro that shows a form cannot run unattended.

Click the dialog to release the batch, then fix the macro.

Every row is amber

Amber means the macro opened a prompt and SwMacroFlow answered it. Somewhere in the macro there is a MsgBox with a button set other than the plain default, or an InputBox, and it is being reached on every file. The log names the message.

If the macro genuinely needs an answer, make it an input instead of a prompt. See Adding inputs.

Every row is red with Error 91

Error 91: Object variable or With block variable not set almost always means ActiveDoc was used without checking it first. Add the guard:

Set model = swApp.ActiveDoc
If model Is Nothing Then Exit Sub

In the Run once without opening any files mode there is never an active document, so a macro that needs one will hit this on its single run.

The rows are green but nothing changed on disk

Closing a document discards unsaved changes, and SwMacroFlow closes each document when the chain is finished with it. A macro that modifies a document has to save it before returning.

Files are missing from the scope

• Check the Part / Assembly / Drawing checkboxes. They filter what runs, not what is listed.
• Include subfolders is off by default when you browse a folder.
• Only .sldprt, .sldasm and .slddrw are recognised.

A library macro is missing or unchanged after an upgrade

From Library lists %LOCALAPPDATA%\SwMacroFlow\macros. Drop a .swp there to add your own - the folder button beside From Library opens it for you.

Shipped macros are seeded into that folder. If you edited one, a later upgrade leaves your edit alone. If you deleted one, it stays deleted. If the local folder cannot be written, the menu still lists the install copy but you cannot add files to it.

A macro behaves differently in the VBA editor

Two differences, both expected:

• MsgBox shows a real dialog when you run the macro yourself. During a batch it becomes a row.
• GetCurrentMacroPathName returns %TEMP%\SwMacroFlow\run_<id>.swp during a batch, because SwMacroFlow runs a throwaway copy. Your own .swp is never modified.

{Property} tokens in input values only expand during a batch (per open document). In the VBA editor you are running the unpatched macro with whatever literal is in the Const.

"The workflow could not be saved."

The chain and its values could not be written to disk. The saved workflows live in %LOCALAPPDATA%\SwMacroFlow\workflows.xml, with one file per chain in the workflows folder beside it. Check that folder exists and is writable - a locked-down profile or a full disk are the usual reasons. Nothing about the chain in the panel is lost; only the save failed.

Workflow applied "without ..., no longer on disk"

A workflow stores where each macro is, not a copy of it. If a .swp has been moved, renamed or deleted since the workflow was saved, the rest of the chain still applies and the missing step is dropped:

> 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.

Put the macro back where it was, or add the replacement to the chain by hand and save the workflow again. A workflow built only from macros in %LOCALAPPDATA%\SwMacroFlow\macros does not have this problem - that is the warning you get when you save a chain that points outside the library.

The Copilot will not change anything

Check the mode. Ask and Plan are not offered the tools that change things at all, so it will describe what it would do rather than do it. Switch to Manual and ask again.

If it is in an acting mode and a run is still refused, the refusal is the app's, not the mode's - nothing ticked, or a batch already running. The reasons are the same as Run is greyed out above, and no mode overrides them.

Where the logs are

The log panel shows the last 500 lines. The full log is written to a file, one per day, named logger_<date>.log. The folder is shown at the bottom of the log panel, and is normally %LOCALAPPDATA%\SwMacroFlow\logs - beside your macro library, not inside the install folder. Thirty days are kept.

Leftover files in %TEMP%

Each run copies the macro to %TEMP%\SwMacroFlow\run_<id>.swp and deletes it when the batch ends. A crash can leave one behind; the next run sweeps up anything older than an hour. They are safe to delete by hand.

Cancel did not stop it immediately

Cancel, and Ctrl+Shift+Q, stop the run after the macro in progress finishes - never mid-macro, so nothing is left half-written. A slow macro on a large assembly can take a while to reach that point.