SolidWorks API Building Blocks – Part 2

By HawkRidge Systems Engineering Team

Are you new to the SolidWorks API?  Well, you’re in the right place.  We are going to go through some of the fundamentals of API programming to get you building macros in no time! When we start a new macro in SolidWorks (Tools -> Macro -> New), this is what you see:

The lines “Sub main()” and “End Sub” define where the macro starts and ends. SolidWorks will begin executing the main() subroutine when the macro is run and continue executing the code until it reaches “End Sub.” So what do the other two lines mean?

First, we’ll tackle this one:            Dim swApp As Object

In VBA (the language used to write macros for SolidWorks and other Windows applications such as Microsoft Excel), the “Dim” keyword is used for variable declaration. In plain English, you might read the first line as, “Reserve a container called swApp that will hold some object later.” The “swApp” part of it is arbitrary – you can call it almost anything you want, although swApp is declared by default.

Now we tackle this line:                Set swApp = Application.SldWorks

This line is used to connect the SolidWorks application that is currently running to the swApp variable. In other words, it’s taking the container that we created in the first line and filling it with an address for the running instance of SolidWorks. After making this connection, we use “swApp” to refer to the SolidWorks application instead of having to type out Application.SldWorks every time.

We can think of it using a basketball analogy. When Kobe Bryant checks into a game for the Lakers, he checks in as #24. Before the game, that number is reserved (or declared, if you want to use programming terminology) for him specifically. When a referee later calls a foul on Kobe, he tells the scorer’s table that #24 committed the foul and the scorer’s table knows that he means Kobe. If we were to declare and set Kobe in the same way we declare and set SolidWorks, the statements might look something like this:

Dim num24 As Person

Set num24 = Person.KobeBryant

Once we’ve made the connection to SolidWorks, we then have access to all (or at least most) of the things that SolidWorks can do – create new documents, manipulate geometry, export files… the list goes on.  Looking at this screenshot from the API Help File (in SolidWorks, go to Help -> API Help), we’ll see the start of the long list of things that we can interface with within the SolidWorks application.

If you prefer, you can replace the first line of auto-generated code with the following:

Dim swApp As SldWorks.SldWorks

Instead of saying, “The swApp container will hold some generic object,” we are specifying that the swApp variable will point to an instance of the SolidWorks application. This allows the macro to more specifically assign a memory space and also make sure that we don’t accidentally reference a non-SldWorks object into the swApp container. Going back to our basketball analogy, it might look something like this:

Dim num24 as BasketballPlayer

The original declaration of num24 as a “person” is technically correct but very generic. A “person” can be anything from an infant to a couch potato to a sumo wrestler. Declaring num24 as a basketball player tells our program to expect something that’s about 6’3” and 200 pounds.

Any time we declare and set variables, the same principles apply – we tell the program what type of data (a generic object, a specific type of SolidWorks object, an integer, a text string, etc.) to expect, and at some point we take something and assign it to that name so that we can refer to it in the code more easily.  See http://en.wikipedia.org/wiki/Data_type for more information.

If you’re interested in the SolidWorks API, make sure to check out the webinar: “Introduction to the SolidWorks API”

See the previous posts from this series: Getting Started with the SolidWorks API