Early binding vs Late Binding: How to write macros that will always run with no errors

TLDR: Here’s what you need to know about Early Binding Vs Late Binding

• Use early binding for writing macros. It provides IntelliSense and enforces types.
• Late binding is a great way to avoid missing references errors. It allows the Visual Basic Editor (VBE) to resolve variable types during runtime. All variables must be defined as Object.
• Check this SOLIDWORKS documentation article on early and late binding.

The topic of Early Binding vs Late Binding is really close my heart: The eternal question on whether to use early binding or late binding for SOLIDWORKS or Excel VBA macros. Each of these approaches has its consequences and we’re going to discuss those in great detail in this article.

Now, before I give you my personal take on early and late binding, let’s define what they are and go over the pros and cons of each other. By the end of this article, you will be able to discern when use late or early binding.

Let’s begin with early binding.

Early Binding when writing macros

When you early-bind your variables in a VBA macro, you tell the VBE, to assign a specific type to a variable, when it compiles the macro for execution.

For example:
Dim swApp as SldWorks.SldWorks

This tells VBE: “Hey, make sure you that swApp is of type SldWorks.SldWorks”.

Now this is awesome because VBE doesn’t have to do anything extra. It will go and find the type that matches SldWorks from the referenced libraries in Tools > References and enforce that type assignment for the rest of your macro.

This is called type-enforcement. It means if you misspell a method name or miss a parameter, VBE won’t allow you to run the macro until you have those compile-errors fixed.

Now, because you’re early-binding your variables, VBE is able to grab the methods and properties definitions from the tlb reference and assist you into writing the api calls by making autocompleted suggestions. This feature is called “IntelliSense”.

It is a productivity boost and sometimes is a necessity when you are working with ill-designed API calls that have +10 parameters like FeatureManager::FeatureExtrusion3

Early binding is great but it also comes with its shares of problems. A good example is when the type definitions cannot be found. You will have to go to Tools > References and fix any missing ones to allow VBE to resolve variable declarations appropriately.

Late Binding to the rescue

When you use late binding, you’re telling VBE to resolve variables types during runtime. VBE has access to all the COM libraries installed on your machine is able to run through them and grab the appropriate type that matches the declared variable and how it is used.

This is great way if you don’t know what version of SOLIDWORKS the end-user has on their computer.

To use late binding, simply declare all variables as Object. You can even remove the SOLIDWORKS references from the Tools > References window.

You will also have to replace the line :

Set swApp = Application.SldWorks
with
Set swApp = GetObject(, "SldWorks.Application")

Here’s an example that prints a hello world message using late binding:

Dim swApp As Object
Sub main()
'Attach to the active sldworks session
Set swApp = GetObject("", "SldWorks.Application")
If Not swApp Is Nothing Then
'print process id
Debug.Print "Process ID is : " & swApp.GetProcessID()
'display message to user
swApp.SendMsgToUser "Hello from late-bound SOLIDWORKS macro!"
End If
End Sub

Unfortunately when you do that, a few things will happen:

• You lose access to the IntelliSense since all variables are declared as Object.
• You will need to either define swConst enumerations in your macro or use their integer values which is a really bummer. Your code is less readable.

As you can see writing a macro using late binding is equivalent of writing code on a white board which is unpleasant because no-one memorizes the API. This brings me to my personal take on binding. Continue reading below.

Early Binding vs Late Binding conclusion: How to score two birds with one stone

• Use early binding to write your SOLIDWORKS or Excel VBA macro. Make full use of IntelliSense.
• Distribute your finished macro after late-binding your variables and explicitly defining the SOLIDWORKS enumerations. This VBA macro from the SOLIDWORKS documentation does that with the DocumentTypes_e enum.

What to do next?

That’s a good question! VBA is becoming an obsolete scripting language. It’s great for automating small tasks but is not the sharpest tool in the shed for automating complex workflows in SOLIDWORKS or PDM. At Blue Byte Systems, Inc., we encourage our customers reach out to us to upgrade their VBA macros to add-ins. This secures your code and make it easier to maintain and deploy.