Extensible By Design » Extensible By Design

SolidWorks API Presentation – Beginner’s Guide To The API

Jeff Cope — Wed, 17 Dec 2008 17:40:11 +0000

From time to time I do presentations on the SolidWorks API and one that gets requested fairly often is the Beginner’s Guide To The API. I just presented this in Roanoke, VA at the Blue Ridge SolidWorks User’s Group headed up by Jeremy Marks. They were a good bunch of guys (although there was a University of North Carolina fan in attendance) and it seems like a well-run group. However, after risking my life to get there by driving through what seemed the rain-storm of the century on unfamiliar mountain highways with almost no visibility I have decided that in the future it might be safer for me to simply make the presentation available on my blog : )

beginners-guide-to-the-api

Also, the SolidWorks Autonumbering Macro (w/ MS Access Database) that I usually show has been written up for ConnectPress with a link to download the Macro and Database. You can view that article here:

http://www.solidworkscommunity.com/feature_full.php?cpfeatureid=32314

© Jeff Cope for Extensible By Design, 2008. | Permalink | One comment | Add to del.icio.us digg
Who's linking ? Technorati BlogPulse Google
Want more on these topics ? Browse the archive of posts filed under CAD, Macros, SolidWorks, SolidWorks API.

Macros 201 – How To Register Your SolidWorks Macro To Receive Notifications For SolidWorks Events

Jeff Cope — Thu, 01 Nov 2007 20:56:43 +0000

Why Should I Learn How To Register My Macros To Register For Notifications From SolidWorks?

The common Macros that you see floating around the SolidWorks community are many and most of them are useful. However, most of those Macros run only when explicitly commanded to do so by the user. This is great for most Macros but there are times when it is nice to have some of your code run every time a certain event happens in SolidWorks. For example, what if you want to have SolidWorks filenames determined based on your company’s part-numbering scheme, which is pulled from a database? Wouldn’t it be nice to have the situation where every time SolidWorks prompts you to save a file, the filename box was pre-populated with the next number in the sequence?

You might be thinking, why not just write a regular Macro that will retrieve a part number from a database and then save the active file with that number as the filename? Well, that works great if and only if your users remember to always use the Macro to save the files. In this case it is better to have the user be “automagically reminded” when they attempt to save the file. To do something like this, you need to register your Macro to receive notifications from SolidWorks. This is not extremely hard to do if you know how but if you don’t know how, then the SolidWorks API Help isn’t very helpful on this topic; hence the post.

Note: This particular example may be a moot point for you if you have a PLM tool that takes care of this for you. If that is your situation, then be thankful but don’t rub it in. The general concept will still apply though albeit with a different concrete example.

For the Macro to accompany this post, I was going to do the scenario above but I saw a post on SolidWorks Community’s Q&A page that made me decide to do the example below. However, if there appears to be much interest in the auto-numbering Macro then I might post that one also.

What Does This Macro Do?

This Macro will “listen” for SolidWorks to open SolidWorks files. When this happens, the Macro will populate the document with a custom property (“sw_version”) that contains the SolidWorks version (e.g. 2007 SP4.0) used to open the file. If the user saves the file after opening it, you know without opening the file what version of SolidWorks last saved the file. If the user doesn’t save the file after opening it, then the custom property isn’t added or modified. You will need to run the Macro exactly once, each time you open SolidWorks. From then until you close SolidWorks, the Macro will monitor all SolidWorks files being opened.

How Hard Is This To Do?

This article assumes you know how to write simple Macros. You should know how to create and initialize objects and call functions. As the title suggests, this is not a freshman class on SolidWorks Macros but rather a sophomore class.

I Don’t Want To Learn Anything, Can I Just Have The Finished Macro?

Yes. You may download the Macro from here. Warning: No warranty is either expressed or implied for this Macro and the Macro is not in any way supported. By downloading the Macro, you assume all responsibility for running the Macro.

What Version Of SolidWorks Was This Macro Written For?

This Macro was written for SolidWorks 2007 but should run on 2008 as well.

How Do You Do It (High-Level)?

Open a new Macro.
Add a new class to “listen for events”
Declare a class-level sldworks.sldworks variable for the new class like this: “Private WithEvents sldworks.sldworks”
Register methods in the new class to be notified by SolidWorks when those events occur.
Register a method in the new class to be notified by VBA when the class is initialized. Make sure that class initializes a sldworks.sldworks variable that is declared at the class level.
Add a method to perform the desired work and add a call to it from the method registered in step 4, above.
Add a public (i.e. global) variable to your main module that represents the event listener class.
Add code to the main procedure in your main module to initialize the public event listener class.
Debug endlessly until it “works”

How Do You Do It (Detailed)?

Open a new Macro.
- You should already know how to do this step.
Add a new class to “listen for events”
- Call the class “clsEvents”
Declare a class-level sldworks.sldworks variable for the new class like this: “Private WithEvents swApp as sldworks.sldworks”
Register methods in the new class to be notified by SolidWorks when those events occur. The drop down box on the right with events only appears after you declare your swApp variable “WithEvents.” Also, you must have the left drop-down box set to swApp to see the events for swApp. If you have the left drop-down box set to Class, then you will see only the class events in the right drop-down box.
Register a method in the new class to be notified by VBA when the class is initialized. Make sure that class initializes a sldworks.sldworks variable that is declared at the class level. NOTE: In this case, you must have the left drop-down box set to Class in order to have the right drop-down box show Class events.
Add a method to perform the deisred work and add a call to it from the method registered in step 3, above.
- I like to put in a simple msgbox() and verify that it is getting called appropriately before I complicate things by adding my worker method.
Add a public (i.e. global) variable to your main module that represents the event listener class.
- This class will be loaded into SolidWorks memory for the duration of the SolidWorks session.
Add code to the main procedure in your main module to initialize the public event listener class.
Debug endlessly until it “works”
- I would start out by making sure that my msgbox is called first and foremost.
- Once the msgbox pops up consistently, then I would add the worker method.
- Here is the worker method that I employed:

Good luck. You can ”cheat” by downloading the finished Macro and checking it out if you need to do so.

© Jeff Cope for Extensible By Design, 2007. | Permalink | 10 comments | Add to del.icio.us digg
Who's linking ? Technorati BlogPulse Google
Want more on these topics ? Browse the archive of posts filed under Macros, SolidWorks, SolidWorks API.

From King of Prussia, PA With Love

Jeff Cope — Fri, 26 Oct 2007 05:17:12 +0000

So here is what you missed out on if you ~~were too lazy to~~ weren’t able to attend the SWUGN Technical Summit – Philadelphia, which was held in King of Prussia, PA (right down the road from the city of brotherly love) :

A chance to win a free pass to SolidWorks World 2008 in San Diego, CA
A chance to win a 3D Connexion Motion Controller
A chance to meet Dennis Miller (Susquehanna Valley SolidWorks User Group Leader) in person

Seriously, it was a lot of fun. In addition to the networking, the great food and the little technical bits of information, we were right across the street from Valley Forge. The highlights of my trip were #1-Trying to find a gas station anywhere near the airport (this is difficult in any city but Philadelphia takes it to a new level) and #2-Learning PhotoWorks tips from the master, Rob Rodriguez. I have to give a big thanks to TriMech for sending me up there. It is nice when your employer believes in giving back to the SolidWorks community.

Some of the folks who attended my session asked me for the PPT so I am posting it here. If you didn’t attend, then just make sure you smack yourself on the hands or something before you download the presentation. Note: I also included the before and after versions of the PDF-making Macro that we recorded.

One last thing, did anyone else find it interesting that all of the street signs that say “Phila” instead of Philadelphia? It seems odd that the cream cheese guys can fit the entire word on a little box of cream cheese but the DOT can’t fit the entire word on a huge highway sign. It didn’t really throw me off or anything though so we’re cool DOT. The highway-sign maker’s union is putting you on notice though.

© Jeff Cope for Extensible By Design, 2007. | Permalink | 3 comments | Add to del.icio.us digg
Who's linking ? Technorati BlogPulse Google
Want more on these topics ? Browse the archive of posts filed under Macros, SolidWorks, SolidWorks API.

GetObject( ) or CreateObject( )? Is there a difference? – Part III

Jeff Cope — Thu, 11 Oct 2007 05:24:59 +0000

At the end of my last post on this topic, I promised you that I would share a “dirty secret” so I guess I now have to come clean. FYI – “Dirty secret” may have been a bit strong but it sounded cool (at least to me). Anyways, there is a difference between how SolidWorks handles CreateObject( ) and how MS Office products handle CreateObject( ). This is something to be aware of when automating across applications.

What is the difference? In a nutshell, calling CreateObject( ) on an MS Office application interface will always create a new instance of the application and then return a handle to that instance. Calling CreateObject( ) on the SldWorks.Application interface will only create a new instance of SolidWorks if one isn’t already running. This basically ensures that only one instance of SolidWorks at a time is ever automated by your Macro. This is a basic coding pattern called “the Singleton” and it prevents untold suffering and countless tears. SolidWorks is so kind to us and many of us didn’t even know it.

Below are two Macros to illustrate the difference between SolidWorks and MS Office applications with regard to CreateObject( ). The first is an Excel Macro that automates SolidWorks and the second is a SolidWorks Macro that automates Excel. If you copy/paste the code, be sure you add references in each Macro project to the object library of the application you are automating. If you don’t know what the heck I am talking about, then just download the complete files from here.

Excel Macro to automate SolidWorks:

‘Copyright 2007 by Extensible CAD Technologies, LLC – All rights reserved
‘Written 10/10/2007 by Jeff Cope
‘User assumes all risk for using the code below.

Sub AutomateSolidWorks()

‘Declare three handles to SolidWorks instances.
Dim swx1 As SldWorks.SldWorks
Dim swx2 As SldWorks.SldWorks
Dim swx3 As SldWorks.SldWorks

‘Use CreateObject( ) for the first instance. A new instance of SolidWorks IS NOT created.
‘Note: As we showed previously, using GetObject( ) without a filepath argument here would
‘return an error since no instances of SolidWorks are available to attach to yet.
Set swx1 = CreateObject(“SldWorks.Application”)
‘Use CreateObject( ) for the first instance. A new instance of SolidWorks IS NOT created.
Set swx2 = CreateObject(“SldWorks.Application”)
‘Use GetObject( ) for the first instance. A new instance of SolidWorks IS NOT created.
Set swx3 = GetObject(, ”SldWorks.Application”)
‘At this point, we should only have one SolidWorks window open and one SolidWorks process running.
‘Add new parts using each of the three handles

swx1.NewPart
swx2.NewPart
swx3.NewPart
‘We should now have one SolidWorks window open with three new SolidWorks parts loaded.

End Sub

SolidWorks Macro to automate Excel:

‘Copyright 2007 by Extensible CAD Technologies, LLC – All rights reserved
‘Written 10/10/2007 by Jeff Cope
‘User assumes all risk for using the code below.

‘Declare three instances of the Excel.Application interface
Dim xl1 As Excel.Application
Dim xl2 As Excel.Application
Dim xl3 As Excel.Application

Sub main()

‘Use CreateObject( ) for the first instance. A new instance of Excel is created.
Set xl1 = CreateObject(“Excel.Application”)
‘A new Workbook gets added to this instance
xl1.Workbooks.Add
‘Make the instance visible so we can see what is happening
xl1.Visible = True

‘Use CreateObject( )for the first instance. A new instance of Excel is created.
Set xl2 = CreateObject(“Excel.Application”)
‘A new Workbook gets added to this instance
xl2.Workbooks.Add
‘Make the instance visible so we can see what is happening
xl2.Visible = True
‘At this point, we should be able to see two Excel windows running and each should have a
‘new Workbook added.

‘Use GetObject( ) for the first instance. A new instance of Excel IS NOT created. A handle
‘is simply returned to one of the existing instances (usually xl1).
Set xl3 = GetObject(, “Excel.Application”)
‘A new Workbook gets added to this instance
xl3.Workbooks.Add
‘Make the instance visible so we can see what is happening
xl3.Visible = True
‘At this point in the Macro’s execution, we should see two Excel windows (and two Excel processes)
‘running. However, we have three handles to Excel instances so two of the handles are pointing
‘to the same Excel instance.

‘Release handles to COM objects
Set xl1 = Nothing
Set xl2 = Nothing
Set xl3 = Nothing

‘One of the Excel windows will have two Workbooks in it instead of one. Note: If you
‘want to know which one, then just leave one of the instances invisible.
End Sub

© Jeff Cope for Extensible By Design, 2007. | Permalink | 2 comments | Add to del.icio.us digg
Who's linking ? Technorati BlogPulse Google
Want more on these topics ? Browse the archive of posts filed under CAD, Macros, MS Office, SolidWorks, SolidWorks API.

GetObject( ) or CreateObject( )? Is there a difference? – Part II

Jeff Cope — Mon, 08 Oct 2007 18:52:30 +0000

Last time I explained how the SolidWorks application object behaves differently depending on whether it is instantiated via CreateObject( ) or GetObject( ). So now you are probably thinking, “That’s it? That was too easy.” Well, I don’t want to be one to disappoint so I will let you in on the rest of the story including a dirty little secret.

So what else is there? The GetObject( ) call has another trick up its sleeve that I didn’t discuss last time. Taking a look at its Intellisense signature provides a clue as to what this is.

In the method signature you actually see two parameters, PathName and Class. We know the Class is “SldWorks.SldWorks” but what is this PathName and to where does this path lead? Well, it turns out that this is the path to a SolidWorks file and that GetObject is so cool that not only can it return a reference to a SolidWorks application interface (e.g. SldWorks.SldWorks), it can also return a reference to a SolidWorks file as well.

Below are some examples on how you can use GetObject( ).

Example 1 – The first example is basically review from the last post. This code will usually get you a handle to an already running session of SolidWorks (i.e. a handle to an instance of the SldWorks.SldWorks class)

Dim swapp As SldWorks.ModelDoc2
Set swapp = GetObject(, “SldWorks.Application”)

Example 2 – Iff (if and only if) you have “SLDPRT” associated with SolidWorks on your machine, then the code below will usually get you a handle to a SolidWorks document (i.e. a handle to an instance of the ModelDoc2 class) that resides at the address of “C:\myFiles\myPart.SLDPRT.” Note: In this particular case, an instance of SolidWorks will be created even if one doesn’t already exist. This was glossed over last time.

Dim swDoc As SldWorks.SldWorks
Set swDoc = GetObject(“C:\MyFiles\myPart.SLDPRT”)

Example 3 – The code below will usually get you a handle to a SolidWorks document (i.e. a handle to an instance of the ModelDoc2 class) that resides at the address of “C:\myFiles\myPart.SLDPRT.” This is irregardless of whether or not you have “SLDPRT” associated with SolidWorks on your machine. Again, in this particular case, an instance of SolidWorks will be created even if one doesn’t already exist.

Dim swDoc As SldWorks.SldWorks
Set swDoc = GetObject(“C:\MyFiles\myPart.SLDPRT”, _ “SldWorks.Application”)

In a nutshell, GetObject can also be used to return a handle to a specific file. To do this you simply include the path to the file as the first argument. If you do this, then the second argument becomes optional unless you don’t have the particular file’s extension associated to the application in which you desire to open it.

“Ok Jeff. That’s pretty cool but what about that dirty little secret you promised us?”

We’ll have to save that for Part III and the final installment. I’ll give you a little hint, though. SolidWorks and Microsoft don’t make ALL of the same mistakes. Some but not ALL.

© Jeff Cope for Extensible By Design, 2007. | Permalink | No comment | Add to del.icio.us digg
Who's linking ? Technorati BlogPulse Google
Want more on these topics ? Browse the archive of posts filed under CAD, Macros, MS Office, SolidWorks, SolidWorks API.