OK, maybe “happy” isn’t really a term one would use when working with the SOLIDWORKS API. I’m not saying that the SOLIDWORKS API is bad, it just…well, it can be challenging at times. But if you insist that you NEED to write custom code (I find it rare that I need to if I use DriveWorks to its full potential), then you certainly can use DriveWorks and the SOLIDWORKS API together.

DriveWorks will automatically run SOLIDWORKS .swp macros at the end of the generation of a model or drawing.  I’ve covered this in the past.  And since I know that every one of you has religiously followed the Razorleaf newsletter and posted every column on your cubicle wall next to that Dilbert with the Dogbert’s  Tech Support line (I love that one), I won’t bore you by covering it again. But a few releases ago, DriveWorks introduced the ever-powerful Model Generation Task, adding a new level of SOLIDWORKS customizability.

The goal of the model generation task is the same as the specification task, to reduce or remove the requirements for anyone to use programming. Instead of code, DriveWorks administrators can drag and drop these tasks to perform common SOLIDWORKS generation steps. DriveWorks requires no code (so stop saying that, please, they’re called “rules”), but, those of us that refuse to color within the lines, can utilize these tasks to introduce the kind of functionality that makes the DriveWorks developers say, “you really need to make your implementation do that? Seriously?” In most cases, this is a very specialized process that your company has developed over years of making products.

Model Generation Tasks and SOLIDWORKS

Model generation tasks will be run during the model generation phase which comes after the specification has been closed by DriveWorks. This is critical to understand, because that means that you are not interacting with the DriveWorks specification, but rather with SOLIDWORKS and the clone that DriveWorks created. Inheriting the SpecificationTask class gives you the SpecificationContext; the gateway to the DriveWorks specification, project, navigation and all things DriveWorks. But, inheriting the GenerationTask class provides you with the GenerationContext which delivers the SOLIDWORKS document that will be or has been generated, the open SOLIDWORKS application instance, and the DriveWorks information provided for the generation. With generation tasks, the bulk of your effort will involve the SOLIDWORKS API programming.

The two things that I would like to focus on here are making SOLIDWORKS code DriveWorks-friendly and troubleshooting your SOLIDWORKS code. One massive recommendation that I can’t stress enough is this:

Error trap 10 times more than you think that you will need to.

And then error trap twice more on top of that. The SOLIDWORKS API is famous for assuming that you have objects and for returning generic objects that you have to assume are instances of a specific object. In most cases, there is no return Boolean or enumerated value to let you know whether you have the object. Even if there is, after every object that you receive, you should always run an error check to make sure that you have the object and it is of the correct type.

The SOLIDWORKS API is also famous for what I like to call the staircase approach to obtaining items. You rarely have an opportunity to fetch the object that you need. More likely, you need to return an object which will give you an object which will give you another object from which you can get another object that will have an accessor to the object that you’re hunting. There are a lot of steps involved and if you don’t get an object or you get the wrong object anywhere along the line, the whole house of cards collapses.

Use DriveWorks Reporting Tools for Debug Information

Which brings us to recommendation number two, use the DriveWorks reporting tools to provide gobs and gobs of debug information. The DriveWorks report writer supports multiple levels of reporting, so you can toggle your “debug mode” through the DriveWorks settings on the SOLIDWORKS Settings tab with the “Reporting Level” value. DriveWorks Model Generation Reports will automatically break out your generation task into a new, collapsible section. The BeginProcess/EndProcess feature allows you to further segregate your information into nested, expandable compartments. Each call to the report writer also allows you to specify a message and details. Once again, this results in a collapsible entry, this time using the plus sign at the right side of the message.

Razorleaf best practices ensure that debug information contains not only documentation of what is happening within the code, but also all of the values being determined or passed that are relevant to that report entry. If a Razorleaf generation task is calling a method, there will be a debug entry listing what method is about to be called and the parameters that are to be passed to that method. Similarly, the result will be reported along with those inputs again. With copy/paste and string.fomat(), this is not nearly as tedious as it sounds. But what it does provide is all of the information that you need to troubleshoot, in a single line that can be easily isolated with the pervasive search built into the DriveWorks reporting tool. This report is definitely one of the primary methods of troubleshooting that we employ.

More Techniques

Additionally, there are two other techniques that we recommend. Firstly, remember that this is inherently SOLIDWORKS code, so we will often troubleshoot these tasks by removing isolated snippets and putting them into a simple SOLIDWORKS macro that we can test right in SOLIDWORKS. Isolating your code from all outside influences makes troubleshooting orders of magnitude easier. This also allows you to make assumptions to further simplify your situation. For example, you can remove the tedious selections process because when troubleshooting SOLIDWORKS macros, you can easily preselect items.

But once you progress past that point, and you are running your task within a DriveWorks specification, you can still test and walk through your code. Microsoft Visual Studio will allow you to attach to processes. By attaching to the DriveWorks and SOLIDWORKS processes, you can easily walk through your code by performing a model generation through SOLIDWORKS, or more easily, through Model Insight, generating interactively in the specification test mode. The main downside to this process is that DriveWorks plugins are loaded on startup. So, if you make changes to your code, you need to close both SOLIDWORKS and DriveWorks before you can rebuild your project. Then you need to restart DriveWorks to load the new version of the plugin and reattach Visual Studio to the new processes. This may seem like a big pain, but seriously, suck it up, buttercup. In the old days, we had to compile just to find a single missing parenthesis. It’s just a few clicks. It’s worth the extra effort.

It’s important to remember that model generation tasks really hand the reigns over to the SOLIDWORKS API. But even though we are in SOLIDWORKS, we can still leverage the DriveWorks reporting mechanism. And we definitely should. This is a powerful tool for troubleshooting, along with attaching Visual Studio to live processes and isolating code within SOLIDWORKS macros, outside of the DriveWorks realm.

But who needs to troubleshoot? Everything is going to work fine because we’re going to error trap every SOLIDWORKS object then recast and check every generic object that SOLIDWORKS gives us. We are, right??

And just remember, if you ever run into any SOLIDWORKS API questions at all, no matter how small, feel free to just dash off an email to your SOLIDWORKS VAR. That’s why they’re there.