Writing macros

Reporting a result

Use MsgBox. During a batch no dialog opens - SwMacroFlow defines its own MsgBox inside the throwaway copy it runs, so each call becomes that file's row in the results list instead.

If Not model.ForceRebuild3(False) Then
    MsgBox "Rebuild failed", vbCritical   ' red row, batch continues to the next file
    Exit Sub
End If

MsgBox "Exported " & n & " configs"       ' green row

If skipped > 0 Then
    MsgBox skipped & " configs skipped", vbExclamation   ' amber row - partial success
End If

Your macro needs no SwMacroFlow-specific code, and it still shows real dialogs when you run it yourself in the VBA editor. The macro is identical either way.

What makes a file pass or fail

In your macroRowReturns
MsgBox "text"Green - a status notevbOK
MsgBox "text", vbCriticalRed - the file failedvbOK
MsgBox "text", vbExclamationAmber - finished, but not entirelyvbOK
MsgBox "text", vbInformation / vbQuestionGreen - statusvbOK
MsgBox "text", vbYesNoAmber - prompt auto-answeredvbNo
MsgBox "text", vbOKCancelAmbervbCancel
MsgBox "text", vbYesNoCancelAmbervbCancel
MsgBox "text", vbRetryCancelAmbervbCancel
MsgBox "text", vbAbortRetryIgnoreAmbervbAbort
InputBox("...", , "42")Amber"42" - the default you supplied
An unhandled runtime errorRed, with number and description-
Missing {Property} / no document to resolve itRed, named error from the host-
Nothing at allGreen-

vbCritical marks a failure and vbExclamation marks a partial success - the run finished, but not everything worked. Reach for vbExclamation whenever the honest answer is "3 of 5 sheets": without it that file is indistinguishable from a clean one. vbInformation and vbQuestion are status notes and leave the row green.

A crash no longer passes silently. An unhandled VBA error is caught, reported as Error 91: Object variable or With block variable not set or similar, and the batch moves on to the next file. No "Run-time error" dialog appears.

Severity order is red, then amber, then green. Within one severity the first message wins, and the row's status and text always come from the same call.

Write a message worth reading

A row you will read four hundred of should say what happened to that file. "Wrote C:\Exports\bracket.pdf" is useful; "Done" is not. Put the value that varies - the path, the count, the property - in the message.

Reporting more than once

Call MsgBox as often as you like. The row shows the most severe message, and the log panel keeps all of them in order.

MsgBox "Checked 4 configurations"
MsgBox "Rebuild failed", vbCritical
MsgBox "Cleaned up"

That file gets one red row reading Rebuild failed, and three lines in the log. The status and the message always come from the same call, so a failed file never shows the text of a later message that succeeded.

Do not ask questions

A batch runs unattended, so there is nobody to click a prompt. Rather than stall, SwMacroFlow answers on your macro's behalf and marks the file amber so you know it happened.

The answer is always the one that declines, because neither choice is safe on its own. Returning vbOK would skip the destructive branch in If MsgBox("Overwrite?", vbYesNo) = vbYes Then Kill f - but it would also skip the Exit Sub in If MsgBox("Continue?", vbYesNo) = vbNo Then Exit Sub and carry on as though you had agreed.

Amber is deliberate. It is neither a clean pass nor a failure, and after a 400-file batch you cannot reconstruct which files had a question guessed at for them unless it was recorded.

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

Property resolution failures

If an input value contains {Property} tokens and a property is missing on that document, or there is no document open to resolve against, the host fails that file with a named error. That shows as a red row - the same severity as vbCritical or an unhandled runtime error. See Adding inputs.

The one thing that still hangs a batch

MsgBox works because an unqualified call resolves against your macro's own project first. A call written as VBA.MsgBox is bound directly to the library instead and cannot be intercepted - it opens a real dialog and the batch stops dead until someone clicks it. Drop the VBA. prefix.

The same applies to a dialog raised from a UserForm. There is no way to intercept one, so a macro that shows a form cannot run unattended.

For the full authoring contract in one pasteable document, see Macro authoring spec.