How do long-time SolidWorks API experts use their skills within the engineering industry? In an effort to answer that question, I am pleased to introduce Jeff Sweeney of 3DVision Technologies, a Great Lakes region SolidWorks reseller, where he proudly wears the title “Engineering Data Specialist”. Though much of his work involves Enterprise PDM, he has extensive experience with the SolidWorks API as well. I greatly appreciate him giving us some of his time to share his opinion of the SolidWorks API, his most notable current and past projects, and his advice for aspiring API programmers.

Jeff, you have told me in the past how much you enjoy working with the SolidWorks API. What do you enjoy most about it?

Jeff: I’ve been programming in one form or another for over thirty years. I love the feeling you get when you finally get your program to work after being stuck for several hours, then when you finally get it working, the program can do something faster than anyone has ever been able to do before. I’ve written several programs that have over a year’s worth of man hours of programming in them and it is very satisfying to know that even years later people are still making money from them.

What are some of the more interesting projects you have worked on involving the API?

Jeff: The biggest project I am currently working on is an add-in for SolidWorks Enterprise PDM. This program isn’t too far from being able to make coffee for the owner first thing in the morning. It interfaces not only with the PDM data but external databases, SolidWorks, Visio, Excel, Eagle, Word, .rar files and Adobe files. Passing data back and for to each of these applications in their native tongues has been pretty cool to make happen.

Like many of us, you’re a self-taught programmer. When did you begin learning CAD APIs and how did you learn them?

Jeff: My first experience with API was with LSP inside of AutoCAD. I worked at a company that already had many custom LSP routines. I spent many hours studying them, and taking them apart to learn how they work. My first experience with Object Oriented programming was with Microsoft Office’s API. Microsoft Office has a fantastic macro recorder and I used it along with other macros I found.

Have you ever used the APIs of any other CAD packages? If yes, How does the SolidWorks API compare to them in terms of power or ease of use?

Jeff: I’ve used APIs for many applications, honestly after you learn the basics they are all pretty much the same. When I first started with the SolidWorks API, I had been using AutoCAD’s API for several years, back then I would have told you the SolidWorks API was way more complicated than it needed to be. However I was comparing manipulating 2D geometry to manipulating 3D geometry. I have since learned that pesky third dimension has a way to make everything more complicated.

Complete this sentence: If the SolidWorks API were a vehicle, it would be a ________

Jeff: “Smooth, clean Shelby Cobra with a GPS that can only see a limited number of satellites.” As long as you stay on the beaten path, you’ll go fast, smooth and look good while you are doing it. If you start doing things that few people have ever done before, there are fewer examples, fewer people to help you, the help file is skimpier and some of the properties and methods can get you lost deep in the forest.

That is a really great analogy and certainly reflects my own experience as well. Finally, do you have any advice for aspiring API programmers?

Jeff: The typical answers to this question certainly apply: Be patient and persistent, read everything you can, wash your hands before eating and keep a good snippet library. Specifically, my favorite technical tip is to keep your main routine as small you can. An ideal main routine only calls subroutines and functions. Along those same lines, keep your subroutines and functions as simple as possible. My ideal subroutine is one that I can pull out of the program, and test its input/outputs as a simple routine that can stand on its own. You should also always look for opportunities to create classes to simplify your subroutines even further. Simple building blocks of code are much easier to maintain and debug. Lastly, remember that a program is never as simple as you think it is going to be before you start. If it was easy everyone would be doing it.

That is some sage advice, Jeff, and I couldn’t agree more. Thanks again for your time and good luck with your current projects.

Jeff: Thanks, Keith. Thanks for your web site, as well. I really enjoy its content and it is a huge time saver.

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