SolidWorks API

My own versions of tips and tricks that I employ while programming the SolidWorks API. These tips are not intended to be a repeat of tips you can find elsewhere on the internet.

    Most of us have seen simple macros that can be used to create a model. This is fine if that's the only type of model you create. I have also seen macros that randomly change colors of models. These are just a few simple examples of the automation that can be accomplished with the SolidWorks API. To really take advantage of the potential time savings that this automation provides, consider creating macros that reduce or eliminate the tasks you do most often.

    Here are some ideas/examples:

    • If you are always exporting models for rapid prototyping or tooling build, create a macro that provides a one button export with all of the options set by the macro. This eliminates guessing what options and types you need. See my DocExport macro.

    • If you are always following the same steps to retrieve specific data about the model to generate a report, create a SolidWorks macro to retrieve this data and create a simple report. This ensures consistency in how the data is retrieved and reports are created. See my AssemblyBOM macro.

    • You need to maintain compliance with specific standards set by your company. You can create a macro that ensures specific settings are properly set, and the document complies with these settings. See my AnnotationsPro macro.

    For more ideas, take a look at my Macros page.


    Here are some techniques I use when writing a new macro.


      When writing a macro, is very easy to get overwhelmed very quickly. The idea here is to write and test small portions of code at a time. This minimizes how much code you need to debug each time you test the macro.


      If you have already been writing macros, export the code and forms into another directory where they can easily be referenced while you writing other macros. There are a lot of websites on the internet where you can get existing code for doing those common tasks. Do some research ahead of time to save time for you later on.


      Instead of creating arrays, of potentially unknown length, place the values in a hidden column in an existing combobox or listbox on the form, or if necessary, create a new combobox or listbox, and hide it from the user. The advantage is that you don't need to know, or have to set/limit, the size of the data array when the program is executed. Your only limit is the maximum number of rows that can be places into the combobox or listbox that is defined by the programming software you are using.

      The following example was used in the macro MaterialProperties where material data is read into the material selection combobox control on the form. The data that does not need to be viewed by the user is hidden by setting the column's width to zero (0).

      Here are the steps used:
      • Read external source file (see below) for list of material options.
      • If external source file does not exist, use program defaults.
      • Place list into 'ComboMaterial' combo box as it's read from the external source file.
      • The list is formatted as follows: Material Name, Density, Hatch Name and Color.
      • Set column widths for columns 2 thru 4 to zero (0) to hide the data in these columns.
      • Use 'ComboMaterial.AddItem' to add a row. This places material data entry in a separate row.
      • Use 'ComboMaterial.List(ComboMaterial.ListCount - 1, column)' to add data to each column of the last row.
      • Use 'ComboMaterial.ListCount - 1' to determine list length, number of rows or entries in list.
      • Use 'ComboMaterial.List(row, column)' to access specific data in the list.
      • After user makes selection, use 'ComboMaterial.ListIndex' to identify selected row.
      • Retrieve specific data via 'ComboMaterial.List(ComboMaterial.ListIndex, column)'.


      These routines are used in a number of macros I have written and placed on these web pages. An external source file allows users to define their own parameters and options that are used when running a macro. This makes the macro customizable without having to know how to program VBA, C++, or the SolidWorks API.

      For the example shown here, I have defined the following rules to maintain consistency within my macros and source files:
      • Data/source file must be in same directory as macro file.
      • Data/source file must have same name as macro file with '.ini' extension.
      • Section names must be enclose with [] brackets.
      • Section names are case sensitive and must match.
      • An empty line must exist at the end of each section.
      • Data with special characters should be enclosed in "" quotes.
      • If the data/source file is not found, the macro should have values, defined within the macro, that can be used in place of the missing data/source file.

      Download my SourceFileAccess macro for a working example of this technique.

    The examples shown here were created using SolidWorks 2003, Visual Basic for Applications which is installed with SolidWorks, and information found in the SolidWorks API help file, and Visual Basic help file.