Blog

If you’re even the least bit serious about SolidWorks API programming, then you need to have a game plan for efficiently doing each of these:

• Finding code for use in a macro you are currently writing or plan to write
• Organizing code so it can be easily found and re-used

Tips for Finding SolidWorks API Code

For example, let’s pretend that we want to learn how to change the active configuration of every component in an assembly. Here are a few avenues we might explore for finding such code (in rough order):

1. Record the action with the macro recorder and then study the code. In this particular case, the best we can do is record ourselves changing the configuration. There’s no way to record performing this task on every component in an assembly.

2. Look in the API Help for an example. This is where I usually start. Unless you’re researching something obscure, the API Help may very well have something similar to what you need. In our case, we might try looking under “Components –> Traverse” and “Assemblies –> components”. Both yield some fruit, but the latter in particular will take you to a list including IAssemblyDoc::GetComponents, which is the ideal method to use in this situation. Since this is such a common method, there are several examples of its usage, though these examples are far more complex than we really need.

3. Search on CADSharp.com. Over the years I’ve amassed a pretty formidable code library, I am not shy to admit. While only Premium members have full access, it is often-times useful to use the search field at the bottom of each page to search for a particular API call. This will usually bring up macros from the macro library. For example, if you search for “GetComponents” than you’ll be taken to a list of results including “Run code on every part in an assembly”. Unlike the examples in the API Help, I tend to keep my examples as simple and focused as possible, making them much more snippable (yes, I just coined that word).

4. Look on the SolidWorks API forums. This is usually my last resort, but it is worthwhile nonetheless. The topics covered by inquiring minds over the years are quite substantive, including many obscure topics not covered in the API Help. The challenge here is mostly figuring our what keywords to type in to ensure good results. Don’t be surprised if takes you a while to dig through the results. To ensure that you’re only relevant results, click the “Only for API” option before searching.

5. Search on Google. I almost never do this, because most results take you to the forums (which is easier to search within the forums’ search tool) or the online API Help (which is usually harder to search than the local API Help). Nevertheless, there’s a plethora formerly-active forums and API enthusiast websites tucked away in the omnipotent Google cache that might yield a gem of information.

Tips for Storing and Organizing SolidWorks API Code

Once you’ve learned how to change every assembly component’s active configuration, a wise move is to keep that code in an easily accessible place for later use. If you neglect to do this, then the next time you need that code, not only do you have to dig for it in any existing macro but you have to spend time extracting the relevant code from the irrelevant code. Spare yourself the tedium and store your code in a single, accessible location:

1. One large macro. Each code snippet should be in its own module, or at least its own function or sub-procedure. The advantage is that you can quickly test your code since it’s already in .swp form. The disadvantage is that you need SolidWorks open to in order to look at the code, making it more tedious to reference, especially if you’re working in .NET. I don’t recommend this approach, though a lot of people use it.

2. Word document. Certainly the simplest solution. Just make sure your document is backed up.

3. Evernote. This is my personal favorite. I use Evernote for far more than just API code, because it’s such a useful tool for organizing any information you need to access quickly. You can create a separate note for each snippet, and then tag them with “API”. Since the local Evernote client syncs with your online account, you’re data is safe and accessible from anywhere. Oh, and it’s free unless you need to upload more than 60 MB per month.

4. Code snippets feature in Visual Studio (.NET only). This is a little-known feature within the Visual Studio environment. Even the snippets can be accessed very quickly, they are stored locally, which means a lot of data down the drain if your hard-drive crashes.

5. Snip2Code.com I have never used this, but it seems like a good alternative to Visual Studio’s built-in code snippet manager. This will also work with VBA code. If I weren’t already using Evernote I might give this a try.

Additional Advice for Code Snippet Storage

Finally, let me offer two pieces of advice for those storing code snippets, regardless of location:

—Include comments in your code snippets. Yes, I know, documenting what your code does seems annoying in the moment, but 6 months later you’ll thank yourself for it.

—All but the simplest snippets should be stored as complete, self-contained, fully-functioning programs. Some might say, then, that we’re no longer talking about snippets at all, and perhaps that is true. But I have found that unless you work with the API regularly, it is easy to forget what prerequisite code is necessary for a snippet to work correctly. Let’s consider our earlier example. Here’s what a complete program changing every component’s active configuration looks like:

Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swAssy As SldWorks.AssemblyDoc
Dim swComp As SldWorks.Component2
Dim i As Integer
Dim vComps As Variant
    
Sub main()
    Set swApp = Application.SldWorks
    Set swModel = swApp.ActiveDoc
    Set swAssy = swModel
    vComps = swAssy.GetComponents(False)
    For i = 0 To UBound(vComps)
        Set swComp = vComps(i)
        swComp.ReferencedConfiguration = "Test"
    Next i
End Sub

This takes up quite a few lines. So you might be tempted to store a truncated, incomplete instead:

vComps = swAssy.GetComponents(False)
For i = 0 To UBound(vComps)
    Set swComp = vComps(i)
    swComp.ReferencedConfiguration = "Test"
Next i

Do not do this. You are defeating the purpose of using code snippets. The whole purpose is to prevent the need to re-research and re-write code, and yet that is invariably what will happen because you 1) forgot the context of this code (i.e., the data types involved and how to access those objects), 2) need to share the code with someone who doesn’t know the context, or 3) need to test the code (and in its current state, it will not compile).

Conclusion

There’s a lot of places to look in order to find the code you need, though starting with the macro recorder and local API Help is probably best. When it comes to storing code, Evernote is the clear winner, in my opinion. Always store code snippets as complete programs and always include helpful comments.

That ends our look at finding and storing SolidWorks API code. If you have any other tips or tricks you’d like to share, I’d love to hear about them! Please share below.

Want to hear about new videos, macros, webinars, live training events, and blog posts? Sign up for our newsletter.

If you’re interested in automating some or all of your company’s workflow on your own or with the help of CADSharp’s automation services, you need to answer this very important question: Is this problem best solved using a macro, add-in, or stand-alone? Answering this question requires us to answer several other questions:

• What are the technical differences between these three types of programs?
• How much time and money can I invest into this program?
• What is the skill level (in terms of programming and API) of the person writing this program? What languages does this person know?
• How do I want this program to be deployed? Maintained? Modified (if necessary)? Secured?
• How integrated with SolidWorks do I want this program to be?

In this article, I want to evaluate macros, add-ins, and stand-alones from a variety of perspectives so that you can make the best choice for your automation project. For those with limited time, skip to the Summary and Recommendations section at the end and you’ll probably find all of the information you need.

Macros

A macro is a program that runs only inside of another program. In the case of SolidWorks, macros come in two flavors: VBA macros and .NET macros. Both VBA and .NET macros can be recorded, run, and edited using the commands in Tools–>Macro.

VBA Macros

VBA macros are written using the Visual Basic for Applications (VBA) programming language in the built-in Visual Basic editor. Whether being edited or run, the .swp file is always used.

Advantages

• VBA is easier to learn than .NET languages (both VB.NET and C# are .NET languages), therefore VBA macros tend to be easier and faster to write (with some exceptions – see Disadvantages).
• VBA code can be modified even while the programming is running, making debugging much faster.
• VBA macros are contained in a single file, making them easier to store and share.
• More code samples exist in VBA than all other languages combined, which is another huge benefit to novice SolidWorks API programmers.

Disadvantages

• VBA lacks object-oriented programming capabilities (unlike .NET languages), making VBA macros more cumbersome for very complex programs.
• Due to idiosyncracies with 64 bit systems, VBA macros that use user forms or reference Windows DLLs can cause a lot of compatibility headaches that require extra code to resolve.
• Missing reference issues can occur when sharing VBA macros.
• Not a good choice if you always need your program running as long as SolidWorks is running (choose add-in instead), though it is possible.

.NET Macros

.NET macros are written using VB.NET or C# in the built-in Visual Studio Tools for Applications (VSTA) editor. When being edited, use the .vbproj or .csproj file found in the solution folder. When running from outside VSTA, use a compiled DLL. In my experience, however, these DLLs are unstable and for that reason I do not recommend using .NET macros as a serious part of your company’s workflow. If you really want to automate using the .NET language , create an add-in or stand-alone.

Note that I said “as a serious part of your company’s workflow”. This means a program that you might be deploying across the company or might expect someone else to maintain long after you are gone. That is very dangerous, in my opinion. On the other hand, if you simply want a macro for your own personal use, you should be fine. Also, if you’re new to .NET languages and need a sandbox in which you can play around or hone your skills, .NET macros are a great option since you don’t have to jump through all of the hoops of setting up an add-in or stand-alone.

Examples

If you’d like to see some VBA macro examples, we have hundreds available in our Macro Library.

Where to Start

If you want to start writing VBA macros, you can learn to run, edit, and create a simple VBA macro in the next couple of hours by watching our free online tutorials. No programming or API experience required.

Add-ins

An add-in, also known as add-on or plug-in, is also a program that runs inside of another program. Unlike macros, however, they must be registered and loaded before they can work properly. Add-ins can be written in VB.NET, C#, or C++, which means that they’ll be written and edited using Visual Studio project files and then run from a compiled DLL.

Advantages

• Preferable over VBA macros if you want a more integrated, SolidWorks-native look and feel to your program. Can be turned on and off using Tools–>Add-ins.
• The best choice for programs that always need to be running as long as SolidWorks is running (as long as the Startup checkbox is checked under Tools–>Add-ins).
• Written using VB.NET, C#, or C++, which are much more powerful, feature-rich languages compared to VBA (although more difficult to learn if you’re a beginner).
• More secure, since users probably don’t know how to reverse engineer the DLLs. This means the code is kept private and safe from tampering.

Disadvantages

• The most complicated of the three types of programs to write. Not a good choice for new API programmers.
• Since add-ins run “in-process”, SolidWorks must be open for an add-in to run, unlike stand-alones.
• More administration overhead, since add-ins must be registered. This can be simplified somewhat if the add-in is distributed with an installer, but creating an installer also adds programming overhead.

Examples

If you’re using PhotoView 360 or any CAM package, you’re probably already familiar with using add-ins. Any add-in that is registered with SolidWorks will appear in Tools–>Add-ins.

Where To Start

If you’d like to start programming SolidWorks add-ins: First, I’d encourage you to get basic SolidWorks API programming using VBA under your belt. You’ll learn the API a lot quicker than if you try to start with add-ins. Second, I’d encourage you to watch some professional .NET training tutorials to learn VB.NET or C# (I recommend these and these). Unless you have a background in C languages, I’d recommend learning VB.NET over C#. Third, you can start practicing with add-ins using the SolidWorks SDK add-in templates.

Stand-Alones

A stand-alone is a Windows application that runs in its own process, outside of the SLDWORKS.EXE process, hence its name. Add-ins can be written in VB.NET, C#, or C++, which means that they’ll be written and edited using Visual Studio project files and then run from a compiled EXE or DLL, depending on the project type.

Advantages

• Tremendous flexibility. Stand-alone code can be part of a larger program that doesn’t only involve SolidWorks or they it can run or attach to multiple sessions of SolidWorks for the program’s duration.
• Easier to set up than add-ins.

Disadvantages

• Since stand-alones run outside of the SLDWORKS.EXE process, there is a slight performance decrease compared to add-ins and macros. This is insignificant in the majority of applications, however.
• Not ideal if your program needs to be integrated into the SolidWorks environment.
• Can’t use in-process methods. (Unless you’re writing unmanaged C++ code, this should never be a concern, however.)

Examples

If you have Visual Basic 2010 Express installed (recommended over 2012 Express) then you can download and look at a stand-alone I created in VB.NET that creates a part from parameters contained in an Excel spreadsheet. Both SolidWorks and Excel run invisibly while this occurs. If you need help running it, watch the last part of my SolidWorks World 2014 presentation titled “Using Microsoft Excel with the SolidWorks API”.

Where to Start

If you’d like to start programming SolidWorks stand-alones: First, I’d encourage you to get basic SolidWorks API programming using VBA under your belt. You’ll learn the API a lot quicker than if you try to start with stand-alones. Second, I’d encourage you to watch some professional .NET training tutorials to learn VB.NET or C# (I recommend these and these). Unless you have a background in C languages, I’d recommend learning VB.NET over C#. Third, you can learn how to set up a basic stand-alone in VB.NET, C#, or C++ using this tutorial by Artem Taturevich.

Summary and Recommendations

Macros run inside of SolidWorks are usually written with VBA. Since they’re easy to write and debug, they’re the ideal option for 1) new SolidWorks API programmers, 2) programmers with limited time, 3) programmers who have no need for some of the more robust capabilities of .NET programming languages, 4) personal use or use with no more than a few engineers within the same department.

Add-ins are like macros on steroids. They’re written with the more robust .NET programming languages (or C++) and allow for a more non-intrusive, integrated user experience since they can be turned on and off via Tools–>Add-ins. I would recommend add-ins for 1) experienced programmers who already know VB.NET, C#, or C++, 2) a strongly integrated program experience, 3) use across a company or several companies, 4) increased security needs (versus macros).

Stand-alones are also written using .NET or C++, but unlike add-ins they do not need to run inside the SolidWorks process, which gives the programmer extra flexibility. I would recommend stand-alones for 1) experienced programmers who already know VB.NET, C#, or C++, 2) programs that use SolidWorks in only one part of the program, 3) programs that need to work with multiple SolidWorks sessions during the duration of the program.

If you’re writing a program that you intend to sell or give to other companies and departments, you should definitely create an add-in or stand-alone.

Conclusion

I hope this article has shed light on the fundamental as well as subtle differences between macros, add-ins, and stand-alones. If you still have questions about which option is right for you, leave a comment or shoot me an email and we’ll discuss it.

Finally, don’t forget that CADSharp LLC has a great team ready to help you with your next automation project. Check out our Services page to learn more and request a quote.

Giving you the macro perspective,
Keith

Want to keep up with new CADSharp.com content? Sign up for our newsletter.

The presentations I delivered at SolidWorks World 2014 (“SolidWorks API for Total Beginners” and “Using Microsoft Excel with the SolidWorks API”) are now available for public viewing. Both of these videos contain new material, so even if you’ve watched the tutorials at CADSharp.com, check them out because you might pick up something new. Here’s how you can watch them and get the presentation files:

1. Visit the SolidWorks World presentations page
2. Enter “Keith” for the presenter name
3. Choose “Design Automation” for the Select Category dropdown
3. Make sure that “2014 Proceedings” is chosen
4. Click Search

Once the videos appear, click the film reel button to watch the video and the document button to download the presentation files.

Let me know what you think! I always appreciate feedback.

Keith

Want to keep up with future CADSharp.com content, webinars, and special offers? Sign up for our newsletter.