First Automation Tasks

01The guard preamble

Every tool in this series opens the same way. It is worth writing once, understanding thoroughly, and reusing without variation.

IModelDoc2 swModel = swApp.ActiveDoc as IModelDoc2;
if (swModel == null)
{
    MessageBox.Show("Open a drawing first.");
    return;
}

if (swModel.GetType() != (int)swDocumentTypes_e.swDocDRAWING)
{
    MessageBox.Show("The active document is not a drawing.");
    return;
}

string sourcePath = swModel.GetPathName();
if (string.IsNullOrEmpty(sourcePath))
{
    MessageBox.Show("Save the drawing before exporting, so outputs can be named from it.");
    return;
}

The fourth guard is the one most often omitted and the one that produces the strangest failures. A document that has never been saved returns an empty path, and any naming rule built from that path silently produces files in unexpected places.

02Walking the sheets of a drawing

A drawing document exposes its sheets by name. The pattern is: read the names, activate each in turn, act, and restore the sheet that was active when you started.

IDrawingDoc swDrawing = (IDrawingDoc)swModel;

string[] sheetNames = (string[])swDrawing.GetSheetNames();
string   startedOn  = ((ISheet)swDrawing.GetCurrentSheet()).GetName();

foreach (string sheetName in sheetNames)
{
    swDrawing.ActivateSheet(sheetName);
    // ... act on this sheet ...
}

swDrawing.ActivateSheet(startedOn);   // put the user back where they were

The final line is not decoration. A tool that leaves the user on sheet seven of a twelve-sheet drawing has interfered with their work, and that is what they will remember about it.

03Exporting each sheet

With a sheet active, exporting is a single save call to a path whose extension selects the format. The whole batch exporter is the loop above with one call inside it and a naming rule beside it.

int errors = 0, warnings = 0;

string target = System.IO.Path.Combine(
    outputFolder,
    System.IO.Path.GetFileNameWithoutExtension(sourcePath) + "-" + sheetName + ".dxf");

bool ok = swModel.Extension.SaveAs3(
              target,
              (int)swSaveAsVersion_e.swSaveAsCurrentVersion,
              (int)swSaveAsOptions_e.swSaveAsOptions_Silent,
              null, null,
              ref errors, ref warnings);

if (!ok || errors != 0)
    log.Add($"FAILED {sheetName} (error {errors}, warning {warnings})");
else if (warnings != 0)
    log.Add($"written with warning {warnings}: {target}");
else
    log.Add($"written: {target}");

The naming rule is a design decision

Output names carry meaning downstream. Decide deliberately and document it:

• Derive from the source file name so the origin of any output is obvious from the output alone.
• Include the sheet name, since sheets frequently correspond to separate parts or separate operations.
• Sanitise the result. Sheet names may contain characters the file system will not accept. Replace them on a defined rule rather than letting the save fail unpredictably.
• Decide on collisions before they happen. Overwrite, skip, or write alongside — but choose, and make the choice visible in the log.

04Reading what a document already knows

Documents carry a large amount of information that is useful in reports, audits and file naming. It is spread across three sources.

var report = new System.Text.StringBuilder();

report.AppendLine("Title:      " + swModel.GetTitle());
report.AppendLine("Path:       " + swModel.GetPathName());
report.AppendLine("Read-only:  " + swModel.IsOpenedReadOnly());
report.AppendLine("Author:     " +
    swModel.SummaryInfo[(int)swSummInfoField_e.swSumInfoAuthor]);
report.AppendLine("Saved by:   " +
    swModel.SummaryInfo[(int)swSummInfoField_e.swSumInfoSavedBy]);

string[] configs = (string[])swModel.GetConfigurationNames();
report.AppendLine("Configs:    " + string.Join(", ", configs));

05The units trap

This is the single most common source of numerically wrong results in SOLIDWORKS automation, and it catches experienced engineers because it is invisible.

The same principle governs mass properties, distances between entities, and any coordinate you receive or supply. Where a value crosses the API boundary, assume system units until the reference tells you otherwise.

06Turning a script into a production tool

The gap between something that worked once and something a team can rely on is a short list of unglamorous additions.

1. Take the output location as an inputAsk the user, or read it from a configuration file. Never embed a path belonging to the machine you developed on.
2. Log every itemOne line per sheet, stating what was written or why it was skipped. Write the log beside the outputs so it travels with them.
3. Summarise at the endCounts of written, skipped and failed. Users read the summary; the detail is there for when it disagrees with expectations.
4. Report progressAny run over a few seconds needs to show that it is alive. Silence reads as a crash, and the user will end the process.
5. Handle the interruptionDecide what a cancelled run leaves behind, and make sure a half-finished batch is recognisable as one.
6. Make it idempotentRunning twice should be harmless. If your rule appends a counter, the second run has silently doubled the deliverables.

07Quick reference