Interview With API Expert Jeff Sweeney

Blog 9.12.2012 No Comments


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 CADSharp.com content, webinars, and special offers? Sign up for our newsletter.


Leave Comment

CADSharp.com API Programming Contest Winners

Blog 8.24.2012 No Comments

CADSharp.com’s first-ever SolidWorks API programming contest has come to a close. Some of the finest API programmers out there stepped up to the challenge described in our last post: Write a macro in as few lines as possible that discovers and displays a single message box listing the children of all part components in the assembly. Without further adieu, here are the results:

1. Ivana K. (15 lines)
2. Josh B. (19 lines)
3. Jeff Z. (20 lines)
4. Satheesh P. (26 lines)
5. Matteo O. (28 lines)
6. Anonymous (57 lines)

Congratulations, Ivana! You will receive a $100 gift card to Amazon.com or one of its international affiliates. Josh and Jeff will each receive a $50 gift card as well. Many thanks to all who participated!

Download Ivana K’s solution

The Solution

Writing a top-tier macro that meets the contest requirements involves three challenges, in my opinion.

The first challenge is simply determining how to obtain the children of a part component. Its not as simple as you might think. IComponent2::GetChildren only returns child components, not child features, which means that on a part component this method returns an empty array. To get the children, we actually need to get the IFeature pointer than corresponds to the part component and then use IFeature::GetChildren. This method returns whatever is listed in the Parent/Child dialog box of a part component. The lesson is, a component is considered a feature by the SolidWorks API. With that in mind, we know to traverse the assembly as a set of features rather than components.

The second challenge is understanding how to write recursive functions. Recursion refers to a function referencing itself. A great example of recursion can be seen in the API Help example Traverse Assembly at Component and Feature Levels Using Recursion. Indeed, many contestants used a heavily-trimmed version of this macro as a means of traversing the FeatureManager tree. Recursion lets a programmer re-use code, which can result in having to write fewer lines of code overall. Such was the case with this macro.

The third challenge is knowing tricks and shortcuts within the VBA or VB.NET programming language to remove as many lines as possible. Ivana’s winning solution illustrates this well:

  1. The text displayed in ISldWorks::SendMsgToUser2 is actually the return value of the getNames functions.
  2. Most of the variable names are declared as function arguments or as For Each loop elements, instead of on their own line. (Note that declaring variables in For Each loops is only possible in VB.NET.)
  3. Automatic type-casting is used to reduce the number of variable declarations. For example, using “swMod.FeatureByName(c.Name2).getchildren” to get the child features of a component.
  4. Use AndAlso and OrElse operators (available in VB.NET) to effectively squish two conditional statements into one line. Normal And and Or operators require all statements to be verified, whereas AndAlso and OrElse will begin executing the statements contained within the conditional once the outcome is guaranteed. So in Ivana’s case, the following logic was applied to each component in the assembly: If the component is a sub-assembly then traverse its features, or, if the component has child features then it must be a part component so add the names of those child features to the final results string.

We can see, then, that VB.NET does offer some significant advantages in terms of reducing line length.

(Note: Should you desire to count the lines in the winning solution on your own, keep in mind that comments, blank lines, Imports statements, and Class declarations are not counted. Also, lines containing 2 or more variables declarations on the same line are counted as separate lines.)

Do know of any alternate solutions or have any questions about the solution we discussed? Please share below.

Until next time,
Keith

Want to be informed of future CADSharp.com contests? Sign up for our newsletter.


Leave Comment

API Programming Contest: Win A $100 Amazon Gift Card

Blog 8.9.2012 No Comments

Think you’re a crack API programmer? We’ll find out! CADSharp.com is excited to announce its first SolidWorks API programming contest. Here’s how to enter and win one of three gift cards from Amazon or a 2-month membership to CADSharp.com:

  1. Download the example file set here and open “CADSharp_contest.SLDASM”.
  2. Write a macro in as few lines as possible that discovers and displays a single message box listing the children of all part components in the assembly.
  3. Submit the macro to contest@cadsharp.com before August 23, 12:00AM EST.
  4. The winners will be announced on our blog on August 24, along with everyone else who submitted a working macro, ranked from fewest lines to most lines.

A correct solution will contain the names of all of the children listed in the Parent/Child dialog box of each part (i.e., non-assembly) component. An example of the correct solution is shown here (list order may vary).

Prizes

Three winners will be chosen based on the number of lines of code in their macro.

First prize: $100 gift card at Amazon.com, Inc.
Second prize: $50 gift card at Amazon.com, Inc.
Third prize: $50 gift card at Amazon.com, Inc.

Please note that Amazon gift cards can only be awarded to entrants living in the United States, Canada, United Kingdom, Germany, Italy, France, Spain, China, and Japan. If a winner does not live in one of these countries, a 2-month Power User membership (valued at $199) will be awarded instead. Optionally, a winner that is entitled to a gift card may choose to receive the 2-month CADSharp.com Power User membership instead.

Contest Details
  • Comments and blank lines will not be considered in the line count.
  • You may not hard-code the name of any entity into your solution.
  • The only acceptable precondition for running the macro is this: CADSharp_contest.SLDASM is open.
  • Please read the full list of contest rules here.

May the best programmer win!
Keith

Want to be informed of future CADSharp.com contests? Sign up for our newsletter.


Leave Comment