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.
This is a great post, I wish I’d thought of this sooner. I just went through a lot of my macros to save out some snippets.
One thing I would recommend to add is a visual marker of some sort (I used a commented out line of dashes) to show where the snippet begins and ends. That just makes it easier to see what is prerequisite info, and what is the actual snippet.
To use your example from above:
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
Using comments to denote the code snippet is a great tip. Thanks for sharing.
Having written vba for both excel and access and studying C# C++ and WPF I believe written comments are just about as important as the code itself especially if you will not get it written in one session. I am particularly fond of writing comments as a to do list when I am writing a module so I can keep make notes about functions I need and tasks I need to complete so I can keep focused on the immediate code task and not be distracted.
when I began working with a keyboard I was typing challenged and to get myself an accelerated progress, I decided to not abbreviate words so I would type more not less. It is the same way with coding, write more not less and don’t abbreviate unless it is something you will never forget or confuse like db or rs these variable names are so well known you’ll never miss them. Besides once your variables are declared and set they appear in intellisense so it doesn’t matter how long they are if you only need to type them once.
Great tips. 7 Mistakes New API Programmers Make discusses the importance of commenting.
I like your tip not to abbreviate words. That is wise.
VBA’s intellisense, unfortunately, is not as robust as Visual Studio’s. The variables you create will not appear in the VB Editor’s intellisense. :(
Ctrl+Space brings up the intellisense with your variables in there. I’m tempted to start
my variables with something unique like “mx”. Then I just type Ctrl+Space + “mx” and there are all
my variables. I can do a search and replace with an empty string if I’m sharing the program
with the SolidWorks API community. So “mxswSelMgr” becomes “swSelMgr’. Just a thought.
Another interesting idea, thanks for sharing.
A student in one of my live training class also pointed out that Microsoft OneNote is also a good tool for organizing code. Has many of the same features as Evernote. The downside is that it isn’t free, as far as I know.
I’ve been using Excel to organize my code. I store the code in the comment property of the cell and an explanation of the code in the cell itself. I can hover over the cell to get a quick look at the code. To the adjacent cell I put a link to the folder containing the .bas file that I exported as a module earlier. I can then drag and drop the .bas file (module) from the folder into the VBA editor Project Explorer window.
Cool workflow, thanks for sharing!