Demystifying The Solid Works Api

Editor's Notes

• #3: The program lists this as a beginners session, and that is the truth in that we’re targeting this session towards folks that have not yet done much in the way of SolidWorks programming. This is an intro to the SolidWorks API. We’ll look at the basics, certainly. Examples? You betcha. Details into what parameters each method and property require and return? Nope. That’s all documented for you. Well, mostly. I’ll show you how to find it on your own, but we’re not getting into that level of detail. This also is NOT a programming class. I’m not going to teach you how to write code or teach you how to use the development environments that SolidWorks provides. You folks are obviously smart, or you’d be at the SolidEdge conference. So I’m confident you can figure that stuff out on your own or find some books or info online about that.
• #4: What I want to do today is to inspire you. That’s right, I perspire to inspire. I want you to walk out of here saying, wow, all I need to do is get a copy of that presentation, tape it to my wall, and I can really do this! I want you to walk out of here and be so distracted thinking of what macros and programs you’re going to write that you miss all of the other sessions. Except for my other sessions, 1:30 both tomorrow and Wednesday.
• #5: Here’s the mandatory and cliché review of me and my company. Razorleaf is a services-only company providing implementation and customization, training and support for PDM including EPDM, SmarTeam, Aras, and Matrix, as well as Design Automation (that’s my specialty) including DriveWorks, Tacton, and custom solutions. As I said, services-only, so I won’t be trying to sell you anything, don’t worry.I am Paul Gimbel, known in the SolidWorks community as simply “The Sherpa.” I’ve been to every SolidWorks World, presented at quite a few of them. A trainer and demojock since the original, SolidWorks 95. So yes, I’m old, and yes, I’m starting to look it.
• #6: There are a bunch of ways that you can get code into SolidWorks. The first, and easiest, is with macros. These are little scripts, little nuggets of code that you can run from inside of SolidWorks. You can use TOOLS, MACROS, RUN to execute the macro, or you can use the CUSTOMIZE SolidWorks to add your macro to a menu or as an icon. Macro features are macros that get stuck into the Feature Manager that get executed every time SolidWorks rebuilds that part of the tree. We’ll talk more about them later.Add-ins are programs that are embedded right into the SolidWorks user interface. You may have dialogs, but more likely, you will add ribbons to the SolidWorks menus, you will add a Property Manager window, and possibly something in the Task Pane on the right side of the screen.You can use code in other programs, like in an Excel or Microsoft Access macro, to launch and do things in SolidWorks.And you can also write your own programs that run all by themselves from the Windows Start menu that call SolidWorks.As you can imagine, as you go down this list, the difficulty and skill required increases.Here’s a nice handy chart to see what you can use. You’ll see that .NET is supported across the board, as is VB6. This simply means that these are languages that can be compiled and stored as separate files. You will need something like Visual Studio for these, but you can get an express version for free from Microsoft. Imagine that, getting something free from Microsoft.
• #7: This presentation uses VB.NET. Why? Because it’s my presentation. Want C#? Get your own show. SolidWorks 2009 introduced the ability to macro record straight into VB.NET and C#.NET. The VB.NET can be edited with the free, included VSTA (Visual Studio Tools for Applications) environment. VB is a lot easier for beginners to understand. And VBA is dead. The only ones left using it are Microsoft Office and a few other products based on using Office. Most of the examples that you will find, in the API help and online, are in VB or VBA. Taking VBA and making it .NET is pretty easy. Making it C#, not so much. If you are only going to learn one language, make it a .NET language.
• #8: Some quick myths about macros. Despite what you’ve heard, you can create forms and dialogs to interact with your users. You can automate macros quite easily. And macros do not require you to have objects preselected. Most samples have you preselect, because fetching the right feature is a pain in the assssss…embly. And you most certainly can create classes and other fun stuff in macros enabling you to automatically react when SolidWorks notifies you someone is trying to save a file, for example.
• #9: Here’s the first piece of good news for those of you that question whether you can be a programmer. I was shocked to find out that even the most hardcore code junkie doesn’t write code! Everyone uses Google to find code that is close to what they want. They copy it, paste it, tweak it and test it. One of my engineering professors told me, “A good engineer knows nothing, but knows where to find everything.” At which point I asked him why his exams were not open book. But that’s right folks, life is an open book exam! So cheat as much as you can. Or as they say in codie circles, “repurpose code.”
• #13: So the big deal is how to figure out what properties or methods you need and what objects those belong to. One great method, as mentioned earlier, is to use Google. Look around this convention center. There are LOTS of people here that are writing code. There are even more that didn’t make it here that are writing code. Most of them post it somewhere for free consumption. Heaven knows I do. But there actually is a lot of information in the API Help. This is a sample of an Interface or class member page. This shows all of the properties and methods for the Idimension interface, or the Dimension class.
• #14: You want to look for these pages that list the MEMBERS. Remember, that’s all of your properties and methods.
• #15: The properties section lists all of the properties, click on them for more info. Pay attention to whether they are read only, or if they can get AND set a value. Also pay attention to what they get. Methods are actions performed by or on the object. Follow the links to see what inputs and outputs are involved in these as well.
• #16: The links give you more details, but notice that some give you back objects. Those are the accessors to other classes.
• #17: Also notice that SolidWorks likes to obsolete a lot of properties and methods. Here, they took a property away and put in two methods to get and set the value.
• #18: In other cases, SolidWorks will modify the property or method. In these cases, they will never remove the old member, because that would render your old code obsolete. They simply create a new function with an incremented number after it.
• #19: So here it is. The ultimate process for developing a SolidWorks API program. Let’s run through it and see it in action.
• #21: This macro takes a currently open part and gets a list of all of the configurations in it. It goes through them one at a time, activating the configuration, changing its material, rebuilding it, saving it as a PDF, and adding a configuration-specific property to it.
• #22: These are some of the fun things that I hope you will take out of this example. Most important is the flow for how you obtain objects and use them. These are also very common actions for API macros, so you will be able to “repurpose” my code to your heart’s delight.
• #23: OK, here’s the process. Step 1, use Macro Recorder to perform one or more steps of what you’re trying to do. Then check out what SolidWorks came up with to see if it’s useful or at least provides any useful clues.
• #24: This is what the macro recorder recorded when I changed the material for a few configs. The code is split onto this slide and the next. The most important things to note about the macro recorder are that it will record a lot of things that you do not care about and it may not record everything that you are after. So why record at all? Well, it’s quick, doesn’t cost much, and you may find clues to the members and objects and maybe even some some snippets that you can use. So let’s take a look at the basic format of the macro and at what SolidWorks is putting in here. First is the stuff in blue. It’s the header. It’s always going to be there. Let’s look at the declarations on slide 1. We’ve got a ModelDoc2. You’ll learn soon that you pretty much ALWAYS have a ModelDoc2. A PartDoc, ok, sounds reasonable since we’re working with a part. But look at these variables. A DrawingDoc object? Don’t need it. AssemblyDoc? Nope. In fact, over half of these are extraneous, unnecessary variables that are declared and never used. Minus 15 style points. But there, at the bottom, there it is. SetMaterialPropertyName2. That’s it. Jot it down, copy it to your clipboard, whatever you want to do. THAT is what we’re after.
• #25: The second half isn’t all that much help. The other thing that you’ll see a lot in the macro recorder are selections, clears, view changes and a bunch of other clicks that we will never replicate in a macro. We do see, however, a nice little ShowConfiguration2. That one sounds useful, we’ll tuck that away as well. Some other thins to notice in the format, we have a summary here, at the end, where nobody will see it. And we have the swApp. The most important variable in the whole class. So important that it’s hidden away.
• #26: Barebones, this is what you should have. It starts with these IMPORTS statements that tell VB what libraries classes you’re going to be pulling from. This is what allows us to say DIM swDoc As ModelDoc2, and VB knows what a ModelDoc2 is. You will notice that these are conspicuously missing from my final code. The objects instead have their full names. I prefer to do it that way. It is longer, but actually not that much more typing and it makes it a lot easier to read and follow later on. You should ALWAYS use Tools, Macro, New or Tools, Macro, Record, or if you have a template that you already built from one of those two sources, that’s fine. Make sure that you let SolidWorks built your framework, though.
• #27: Your class definition header is next, telling everyone what your class is going to be called. Leave the PARTIAL in there. It shows that there is a lot more going on behind the scenes than you know. If you want to change the name of your class, for goodness, sake, don’t just type over it here.
• #28: If you MUST rename it, do it in the Project Explorer on the right side. A quick peek at the SHOW ALL button reveals that there is a WHOLE LOT of stuff that you don’t normally see. Just typing over that name will cause untold levels of problems.
• #29: Comments are critical and they belong right here up front. Anything after an apostrophe is treated as a comment and ignored. Use them A LOT! This swApp is also really important, so it deserves to be up front. It doesn’t make it run any differently, it just adds visibility to the most important object you have.
• #30: OK, so we did our macro recorder, we actually got what we think are two of the methods that we need. Let’s do some research.
• #31: We’ll stick with the SolidWorks API Help, because you really need to see how to use it. It’s takes some finesse. We know we need to deal with configurations. We want a list of the config names. So let’s just search on CONFIGURATION. Here’s what we find. The first entry (of 500) looks somewhat relevant, so let’s follow the link. That shows us that there’s a ConfigurationManager object. OK, I’ll bite. Let’s see if we need that.
• #32: So here, I didn’t see anything that really meant anything to me, but I did notice that there were a lot of examples. This one especially caught my eye, because it talks about doing something with ALL CONFIGURATIONS. Now it’s VBA, not VB.NET, but what I’m really looking for at this point is what objects and what methods do I need. That’s going to be universal. And VBA and VB.NET aren’t THAT much different in terms of readability. I would stay away from the C# examples if vous no parlez C++.
• #33: So I scanned through that code and it was pretty simple at the top. A bunch of DIM statements. I know what those are. But down here, we see swModel.GetConfigurationNames. That sounds REALLY good. What doesn’t look so good is that they’re using VARIANTS. That means we need to do more research to figure out how to use this method.
• #34: OK, so we found the method that we need. We’ll search on that and the search comes up with GetConfigurationNames. Great, let’s follow it. OK, that’s obsolete. Quite often, you will get the obsolete one first. Don’t worry, just keep going.
• #35: The obsolete one led us to the current one. So from this screen, we get a few pieces of information, very few. One, we see what object we need to have to take this action, the ModelDoc2 object. Second, we find out what SolidWorks returns to us, sort of. It gives us back an object. Um, that could pretty much be anything. It’s a bit of a cop-out if you ask me. Down here, they give you a little more info, letting you know that it is an array. VBA was very sloppy and let you get away with a lot, but in .NET, we need to know for sure. It turns out to be an array of strings. How do I know? I guessed and tried it.
• #37: OK, so we did our research. Onto the next step.
• #38: In VB, we need to declare, or tell VB what our variables are going to be before we use them. We do this with a PUBLIC or DIM statement. We tell it the variable name that we’re going to use and we tell it the class of the object. Once VB knows what it’s going to be, we can then put a value or assign an object to it. Remember that Accessors are the methods that are used to obtain objects. You need an object to get an object. Sometimes, though, we’re not 100% sure what we’re getting back from our accessor, so we use an insurance function, called Ctype, that converts the output from the accessor into the specific type that we want. DirectCast is also sometimes used for pretty much the same reason. So don’t be shocked if you see these.
• #39: At the top, we can put variables that we know we’re going to use. Notice that we can declare and define in a single line.We can also define them as we go, so don’t worry if you don’t know them all. You can put them up here later, or just declare them down in the code.
• #40: The first thing that we need to do is to latch onto the open session of SolidWorks. There are three common ways to do this. You can just set it to Application.Sldworks. This requires that SolidWorks be open and running. If you’re running a macro, then it’s a pretty good bet that SolidWorks is running. You can do a GetObject which is a bit more robust, and what’s cool about this one is that you can put a parameter in here telling SolidWorks which window to open. This is not a FILE, OPEN, this gets you latched onto the SolidWorks Application with a certain document window open. If the document and SolidWorks are not open, Error City, USA. CreateObject is a bit more robust in that it will open SolidWorks if it’s not already open. Great for standalone apps or calling SolidWorks from another program.
• #41: So we need to grab the ModelDoc2 object. Why? Because the process says that we always need to. Remember that accessors are methods, so we need an object to access other objects. What object is that? Typically, it’s the ModelDoc2. So we’re going to use the swApp object with its accessor .ActiveDoc to get the ModelDoc2 object. Where do we define the swApp object? Well, that’s done by SolidWorks in that big jumble of stuff that’s hidden from you. It is ALWAYS important that whenever you define or instantiate an object, that you check to make sure that you have it. If you assume that you have it and go on, SolidWorks will barf at you and your users will laugh at you.
• #42: It is very important to know where the method or property that you need lies. ModelDoc2 does an awful lot. So much in fact, that they had to create another object, ModelDoc2.Extension. But some other things that you would imagine would be on the ModelDoc2 are more document-type specific. So you need to get a PartDoc object or AssemblyDoc object or DrawingDoc object.
• #43: So now we have the ModelDoc2, and we know that the ModelDoc2 can get us the configuration names. The first thing that we do is check to make sure that we got names. If we do, then we start looping through them. For Each…In loops are a great way to go through arrays or collections without having to care how many there are. Within the loop, we’ll switch the active config with the ShowConfiguration2 that we saw in the macro recorder, and we’ll rebuild as well. It’s interesting to note that these methods actually return a true/false value telling you if they worked or not. In practice, you will want to do an IF…THEN to make sure that they succeeded. And we will always be careful to close out our loops and our IF blocks.
• #44: So we have our ModelDoc2 and we used it to get the config names. Now we need to change the material and we know that’s on the PartDoc object.
• #45: Now normally we would use an accessor to get the Part object from the modeldoc2 object. But ModelDoc2 has a weird relationship with PartDoc, AssemblyDoc and DrawingDoc. They’re kind of the same. So you don’t need an accessor, you just set them equal. This is the only place you will see this, so don’t worry. This is generally the only time we’ll use DirectCast, too. So just set swPart equal to our ModelDoc2 object, swDoc, and recast it as a PartDoc object. Notice that we are outside of the loop, that is, before we start going through the configs because we don’t want to reassign this every time. But back inside the loop, we can then go ahead and set the material since we now have the right object.
• #46: Saving the model as a PDF is pretty easy. All of the methods that we need to use are on the ModelDoc2 object. We’re doing a little string manipulation here. By the way, go online and check out the VB.NET string members, they are way cool. You may also see this from time to time. A space-underscore means that this was too long to fit on one line, so it bleeds over to the next. I has to be a space-underscore. Not just an underscore. Down here, you can see that we have methods that will return values listed in the parameters. In the API Help, they’re listed as BYRef. ByVal, means that you are giving an input to the method, ByRef means that you are getting an output. Since you can only have one thing on the left side of an equals, this is how they pass back more. And finally, notice that two of the parameters here, VERSION and OPTIONS are integers. We use enumerations for these.
• #47: Enumerations are nothing more than aliases. Why they make them a number, I have no idea. What is the integer representing SolidWorks 2009? Who knows. So instead, we use an enumeration. The enumerations are stored in the SolidWorks.Interop.swconst (that’s out second IMPORTS that we always have at the top). The help will tell you (if you click) what enumeration to use, but if you just type SolidWorks.Interop.swconst (you’ll see that it autofills in most of it for you), then you will get a nice list to choose from. So you will not need to memorize any of these…ever.
• #48: The last step that we have is to set the custom property. Here we’re using another cool VB.NET string function. And what’s most important here is that we’re closing out our loops and our IF…THEN blocks. But which is which? You could have a half-dozen END Ifs in a row. That is not uncommon. A nice little comment afterwards lets you easily keep track of which is which.
• #49: And here is the complete code for the configuration example.
• #57: This example was for a company that uses DriveWorks to automate the design of their parts. DriveWorks has the ability to kick off a macro upon the completion of the generation of a part, and these folks had a bit of an odd situation. For anonymity’s sake, let’s say that they make plates with holes. The plates come in different sizes with different size hole patterns. The customizability comes in because not every hole is needed every time. So we needed a way for the end user, a non-SolidWorks user, you specify which holes needed to be there, and which holes should not. In SolidWorks this is easy, you right-select the pattern, edit definition, then choose the instances to skip from the pattern. But this was automated. There’s nobody there to pick. So what we did was to have DriveWorks generate a series of Xs and Os representing the pattern. X means there’s a hole and O means there is no hole. DriveWorks passed this into the part as a custom property. Our macro would then read the custom property, scan the part for a pattern that matched, then do its magic.
• #58: This one is fun because it works with features. It shows you how to loop through features, looking for patterns, and it deals with something that comes up often and is a bit weird, a FeatureData object. And now we get to read a custom property that we learned to write in the last example.
• #59: So we’re going to follow the same process. Step one, macro record.
• #60: So this is what we get out of the Macro Recorded this time. We see our ModelDoc2, which we know we’re going to need and…well, that’s about it. You can see the Hole Pattern being selected, but that’s about it. No help whatsoever. This happens sometimes.
• #61: So we go into the research phase empty handed. No worries.
• #62: We know we want to work with linear patterns. So let’s search on Linear Pattern and see what comes up. ILinearPatternFeatureData. That sounds like quite the interesting class, let’s see what it’s all about, and more importantly, what properties and methods it has. We look at the interface page and we see the link for the MEMBERS which will tell us what properties and methods this class has. We also notice the accessors area at the bottom that tells us how to obtain this object.
• #63: So looking at the members for that ILinearPatternFeatureData object, we see towards the bottom, a SkippedItemArray property. This allows us to get or set the list of instances to skip. Sounds precisely like what we want.
• #64: So how do we get this ILinearPatternFeatureData object, then? Well, the Accessors section says to use Feature.GetDefinition. By the way, this double colon really means nothing. When you use it, you will use it with a dot like you always do. You will use swFeature.GetDefinition. OK, so the GetDefinition Accessor is a method of the Feature class or Ifeature Interface. How do we get the Feature object? Simply click on the link for the IFeature interface and look at its page. Scroll down to the accessors are and here are the accessors. As you can see, there are more than a few ways to get a feature object.
• #65: OK, so let’s look just at the ways to get from a ModelDoc2 or a PartDoc to a feature. There are a few good candidates here. We’ve got FirstFeature, which I’m guessing is descriptively named, and FeatureByName. Well we COULD force the user to provide a specific name to the Linear Pattern Feature, but that would make this code a bit too specific, not very reusable or flexible. So we’ll grab the first feature, but can we get to the next feature from there? Well let’s look at the accessors to get from one feature to another. Sure enough, there’s GetNextFeature.
• #66: So here’s the flow. We get our ModelDoc, We use that to get the first feature, then we cycle through the features. If it’s a pattern, we check to see if it’s the right size. If not, we use that feature object to get the next feature.
• #67: OK, we know what to do, let’s do it
• #68: OK, so let’s get our ModelDoc2 object and then test it for existence, and test it to make sure that it’s a part.
• #69: OK, let’s get the rest of our objects and use them!
• #70: Let’s start by retrieving the list from the custom property. Again, we’ll declare and define in the same line. Custom properties are retrieved with methods from the ModelDoc2 object. We’ll immediately test the string to make sure that it’s a good string. Once we know we have a good string, we’ll retrieve that first feature. Now note, that the first feature is WAY UP there on the tree. You will get a lot of features that you didn’t even know were features.
• #71: Now that we have our first feature, let’s start looping. We have a few variables that we’ll need. One to tell us how many rows and one for how many columns. OurLinearPatternFeatureData object, and a string to check the type of feature that we have. How do I know I’m going to need these? Because I already wrote the code. You find them as you go along, and you add them to the list. We’ll use a DO WHILE loop, because it checks before it runs through each iteration of the loop. So we make sure that we have a feature object, and once we know that we do, then we start processing it.
• #72: The first step is to get the feature type, that’s a method called GetTypeName2 on the feature. The best way to find most of these is to declare the feature object, then just type swFeature dot. As soon as you hit that dot, Microsoft will show you a list of all of the members of that class. It’s called Intellisense. Once you start calling a method, it then tells you wnaat parameters of what classes you need. You don’t need to go to the API Help all the time. So once we see that it is a linear pattern, then do the GetDefinition to get the LinearPatternFeatureData object. Once we have that object, we can pull the direction1 and direction2 quantities off of it to find the size of the matrix. Check that against the length of the string. If it’s a match, then we can move on.
• #73: Now the last piece to this puzzle is to take the string and turn it into a list, a numerical list, of instances to be skipped. SolidWorks wants an array, but we’re going to use another VB.NET tool to get there. The Collection. I’m not going to go into details about collections, again, this is not a programming class, but the difference between a collection and an array is one of flexibility. Arrays are a predefined size. If you want to change the size, you have to re-declare it. Sorting, shuffling, and other such actions are not that easy with arrays. Collections are more flexible. The drawers are a fixed size with a fixed number of slots in each drawer. With collections, you just add on another bin and another and another. VB.NET has a ton of great methods for working with collections.
• #74: So how does SolidWorks number these linear pattern instances? This way. How do I know? I tried it. Sometimes, that’s what you have to do.
• #75: So what we want to do is to walk through the string, counting as we go. And every time we hit an O, then we throw that number into the collection. It’s a pretty basic, but pretty cool little loop. Things to note here are that in a string, the substring starts at position 0. We’re also using the EQUALS method to compare strings instead of a regular equal sign. This allows us to use a comparison method that ignores case. Again, how do you remember the enumerations? You don’t. Intellisense gives them to you.
• #76: So we built our collection with our loop, but SolidWorks wants an array. Not a problem, VB.NET collections have a method called ToArray. This is another commonoccurance within SolidWorks, especially when you’re working with features. Once you have pushed values to properties in an object. In order for those changes to be propagated to the model, you need to kick off some form of Modify or Update method. The other critical thing is that when you make any changes to the model, you will want to rebuild. The last thing that we’re showing here is how to handle the ELSE cases. What happens when the pattern is not the right size? Well when you’re testing, throwing a message box is nice. But when you’re having others use the program, they don’t like seeing errors. So what we did was to write the error out to a custom property. We built the message by piecing together some strings and properties, then passed that string to a custom property.
• #77: And here’s your finished code.
• #84: DOCUMENT EVERYTHING!!! I cannot stress this enough. You want to see as much, if not more green in your code than any other color. Use your comments to turn the VB, which sounds roughly like English, into complete, sensible sentences. Make sure you use it to keep track of IF blocks and loops.
• #85: Here are a couple of things that I want you to always do. In VBA, make your first line, ALWAYS, OPTION EXPLICIT. What that does is that it requires you to tell VBA what your variables are before you use them. You have to declare or DIM your variables. In VB.NET, this is always a requirement. Think of it as the REQUIRE FULLY DEFINED SKETCHES of the programming world.So you have to DIM your variables. You can be vague about them and declare them of type object, or you can tell VBA exactly what kind of object it’s going to be. Being very specific like this is called early binding or fully qualifying your variables. It is a MUST. IF you do this, your code will be easier to read and when you hit a period after your object variable’s name to get to a property or method, you will get a list to choose from. Select a method and Intellisense will tell you what parameters you need to provide in what data types. All that, just for being tidy.In VB.NET, we’re used to having SolidWorks putting the IMPORTS at the top of our macro so that we can shortcut our SolidWorks class names. Yes, it’s shorter, but I recommend spelling it out. It makes it easier to follow.
• #86: We check our return values to make sure that we have objects and we check to make sure that we are getting non-empty strings, and so on. But you’re still going to get errors. Look into the methods that are available to handle these errors. TRY…CATCH blocks in VB.NET are very powerful. OnErrorGoto is good both in VB.NET and VBA.
• #87: This one is a bit controversial, but I like it. Hungarian notation means that you put an abbreviation at the beginning of your variable to show what kind of variable it is. I for integer, d for double, s for string, and so on. I put sw for SolidWorks objects. You can get more specific if you want. If you’re a seasoned coder and you think this is a terrible idea, then don’t use it.
• #88: I’ve also included a little slide here listing some of the VB.NET functionality that you should know. Check these out and Google them to see what they are and how they work.
• #89: The last thing I want you to hear and think about is what kind of things you can do with the API. This is the part of the show where you start to think of what your first project is going to be.
• #90: Number one is don’t limit yourself to just what core SolidWorks can do. Most of the SolidWorks add-ins that come with Premium include APIs. Everything from SolidWorks Utilities to Simulation to PDM and Routing. It’s all in there. I’ll be doing a presentation tomorrow about Automating Design Validation with the API. You’re ready for that now. On Wednesday, I’ll be doing a session on linking Excel with SolidWorks through the API and VBA. Same can be done with MathCAD or other calculation engines. Use them to calculate and pass values to SolidWorks. Then have SolidWorks do a mass prop or a simulation run, then send values back. But the big reasons to write macros are to save time, create iterations that can be performed quickly so you can do more iterations, and finally, to allow people who are not as smart as you to use the power of SolidWorks.
• #91: Finally, I said I would mention macro features. The concept here is that you embed a macro into a feature in the feature manager. When SolidWorks rebuilds, it starts at the top and works its way down. When it hits the Macro Feature, it fires the code off. This could be a validation step, it could run a mass props and update your geometry to accommodate. The sky’s the limit. There’s lots of good info out there on Macro Features as well if you’re interested. The most important thing of all is to start thinking of how you can use this, then GO TRY IT!!
• #92: If you have questions, I’ll be happy to take them now or at any time during or after the conference. If you see me in the hall, feel free to grab me. Just be careful where you grab me. I’m ticklish. If I can’t talk then, we can set up a time to sit down and chat.