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.

Setting Up and Troubleshooting Your SolidWorks Add-in Development Environment. Take off, eh…

Jeff Cope — Thu, 12 Jun 2008 05:31:31 +0000

Writing Add-ins in SolidWorks can be tricky stuff as it involves class libraries, COM, interfaces, etc… It can be argued whether it is easier or harder in .NET (ease of use of .NET versus pain in the rear of COM Interop) but your good friends at SolidWorks set out to make it easy on all of us by creating Visual Studio templates for quickly creating SolidWorks Add-ins. The templates are packaged with the SolidWorks API SDK, support VB and C# and are analagous to having a SolidWorks part template that already has some geometry in it, custom properties, material assigned, etc… When it was introduced back in the day, it was a Godsend. It does have its issues from time to time though. For some reason, I have had trouble deploying both on SolidWorks 2007 and 2008. The SolidWorks API SDK installer runs without errors but when I attempt to create a new SolidWorks Add-in, I see this unfriendly message:

The I have spoken to a few other developers and concluded that I am not the only one so I decided to write a post on it. Besides, I go through this everytime I have to reinstall SolidWorks, which is just often enough to be a real pain but not quite often enough for me to ever remember the steps to fix the issue. I should admit then I am writing this as much for myself as I am for you. Here goes…

The Cause:

Based on the error message, you might get the impression that this is a trust or security issue. That might lead you down a path of signing the dll with a strong name, configuring .NET security policy on your machine, etc… (i.e. the path to frustration). To find the real cause, we must examine the Global Assembly Cache, GAC, to take a look at this SolidWorksTools dll file. The GAC is where shared .NET assemblies are placed so that they can be made available to other applications. On Windows XP, the GAC is located at “C:Windows\assemblies\”. Taking a look at the GAC, we see that it contains a different version of the SolidWorksTools dll file than that which is expected by the SolidWorks Add-in Template for Visual Studio. The version in the GAC is version 2.0.0.0 and not version 1.0.0.1, which is what the SolidWorks Add-in Template for Visual Studio is looking for.

If we take a look at the template itself, then we can see where the version is specified for the SolidWorks Add-in Template for Visual Studio. FYI, the template is contained in a zip file (SWVBAddin.zip for Visual Basic) which in turn is contained in the “…Templates\Project Templates\” folder of your Visual Studio 2005 directory. Note: I have Visual Studio 2008 but it is still in the box so I’ll let you know once I try it if the templates go in the same place.

The zip file contains various bitmaps, icons, classes and modules as you would expect to see in an Add-in but it also a file called VBAddin.vstemplate which is a Visual Studio template file. Once you open it, you see that indeed a different version of the SolidWorksTools dll file has been specified than the one which is installed in the GAC. .

In theory, one should be able to update the VBAddin.vstemplate file above to refer to the insalled version of the SolidWorkTools dll file. One of my favorite philosophers once explained why this might not work for me:

”In theory there is no difference between theory and practice. In practice there is.” – Yogi Berra

What I do is just to uninstall the SolidWorksTools dll file in the GAC (right mouse button on the file in the GAC and select uninstall) and replace it with the version 1.0.0.1 file that SolidWorks API support gave me the first time I ever reported this issue (a long time ago, in a galaxy far, far away…) . You can do this by simply dropping the file in the GAC folder (e.g. C:\Windows\assemblies).

Once you add the version 1.0.0.1 SolidWorksTools dll file to the GAC, you can go into Visual Studio and attempt to create a new SolidWorks project from the SolidWorks Add-in Template for Visual Studio.

And it works! Now you can begin writing that Add-in (i.e. the one that is now a few days late while you fought with the SolidWorks SDK).

Note: For any SolidWorks Add-ins that were previously compiling using the 1.0.0.1 dll, you will have to change your Visual Studio Project to reference the newer version.

Good luck.

© Jeff Cope for Extensible By Design, 2008. | 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 .NET, COM, SolidWorks, SolidWorks API.

Free SolidWorks Add-In To Remind You To Eat Your Custom Properties

Jeff Cope — Sun, 24 Feb 2008 02:50:51 +0000

In spite of all their positive benefits, which are many, more than a few SolidWorks users look upon custom properties with the same disdain that a pre-schooler would have for green leafy vegetables. You can explain the benefits of custom properties, how they help you find things, how they lead to healthy drawing title blocks, how they improve PDM implementations, etc… until you are blue in the face and with some individuals you still won’t make a dent. There might be a change for a few days even a few weeks but inevitably you are back to files with no custom properties filled out.

In order to increase the life-expectancy of CAD administrators everywhere, I have posted a free .NET Add-In for SolidWorks that will “remind” your users to enter certain custom properties whenever they create a new file or save an existing one (after the initial save). The list of custom properties is configurable and

the user cannot proceed with their file until they enter the custom properties. I am sure the program can be improved upon but for those without SolidWorks API skills of their own this should be a nice little app. Also, for those who do have SolidWorks API skills using Visual Basic.NET, I am more than happy to share the code if you request it.

The Add-In, called “Big Brother” is written for SolidWorks 2008 and targets the 2.0 .NET Framework, which means if you have SolidWorks 2008 installed on your machine then you can use it.

To get started,

1. Download the installer package for Big Brother from here.

2. Run the installer, agreeing to the overly wordy license agreement on the way.

3. After installing the software, run the “Register Big Brother.bat” file in the installation directory. Running this batch file will register Big Brother with COM and add the appropriate registry entries for SolidWorks to load Big Brother when SolidWorks is run.

4. This is an optional step but if you don’t already have a decent XML editor, then I recommend you download XML Notepad which is a free XML editor from Microsoft.

5. Use XML Notepad to edit the XML configuration files in the installation directory. The installation has three XML files which are used to configure which custom properties are managed by Big Brother for each of the three main part types in SolidWorks.

AssemblyPropertiesToManage.XML – Represents custom properties for assemblies.
DrawingPropertiesToManage.XML – Represents custom properties for drawings.
PartPropertiesToManage.XML – Represents custom properties for parts.

Edit the list of custom properties to manage for each document type using XML Notepad. Each “ExtProperty” node represents a custom property. PropName represents the name of the custom property to be managed. PropValue and PropType should not be touched. Leave those alone. Save the file(s) when finished.

6. Open SolidWorks and create a new part. After selecting your template, you should be prompted to verify or fill in the values for the custom properties in your PartPropertiesToManage.XML file. The same thing should happen for subsequent file saves. The original Save (for new documents) doessnot trigger the FileSaveNotify event. I suspect that it is triggered by the FileSaveAsNotify event. If anyone tries that and gets the answer then please let me know.

7. Additional configuration of the Add-In may be performed by editing the “ExtensibleEventManager.dll.config” file, which you should also use XML Notepad to edit.

If BigBrotherMode=True then it is mandatory that users enter values for all custom properties. If BigBrotherMode=False then the dialog pops up as an FYI.
If CatchFileNewEvent=True then files are managed on FileNew in addition to FileSave.

© Jeff Cope for Extensible By Design, 2008. | Permalink | 14 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 .NET, CAD, COM, SolidWorks, SolidWorks API, XML.

Macros 301 – Generate Document Numbers From MS Access Database And Auto Insert Them Into New Documents

Jeff Cope — Sat, 09 Feb 2008 04:04:27 +0000

Father forgive me. It has been two weeks since my last blog post. I apologize everyone for the long interval but things have been crazy. In addition to some long nights at my day job, I am in the process of releasing a new version of InspectionXpert, the Quality Inspection Sheet generating software from my company Extensible CAD. It is a rewarding endeavor but also very demanding.

Anyways… not so long ago I posted a Macro & tutorial on how to register for SolidWorks events. One application of that technique that I mentioned was to automatically generate document numbers for your SolidWorks document and insert them into SolidWorks “auto-magically.” Well, not too long thereafter I was bombarded with emails asking me to post that little Macro and I promised to do so. This post is the fullfillment of that promise. I’m sorry it took so long but I think you guys will like it. I feel it is “auto-magically delicious” myself : )

You can download the database and the macro from here.

Keep reading to see a flash video of the macro in action…

The Macro In Full Effizact

Disclaimer: As I am pretty pressed for time, as usual, I have not added any error handling to this macro. You will have to do that yourselves. At some point in the future (here I go making promises again), I will add a post on error handling with VBA.

What this Macro does: If you didn’t understand the movie then (please check your home’s water for lead contamination) this macro registers with SolidWorks to receive notification (aka ‘callback’) when a new file is created in SolidWorks (i.e. File, New). The official Event is ‘FileNewNotify2′ and when fired, the macro will determine the type of file (e.g. SLDASM, SLDDRW or SLDPRT) and then use ActiveX Data Objects, ADO, to contact an MS Access database to find out the next available document number for that document type. The document number is then written to the new document title, in essence the filename, and then the number in the database is incremented by one so that next time the document will have a unique number.

How Do You Set It Up?

Create a database (I used VBA and MS Access because they are friendlier for newbs but SQLServer Express would be more appropriate for a production solution) that contains three colums; a primary key (i.e. unique identifier for each record), a lookup key (we used file extension) and a column to hold the next number in sequence for each record-type. In other words, we have a number series for each file type and the number gets incremented by one everytime a number is assigned.
Determine the connection string to connect to the database. The easiest way to do this is with a little trick I picked up from an awesome SQL Server book (name escapes me right now).
1. First you create a new text file and then you change the extension from .txt to .udl
2. Double-click on the file to open it and you will be prompted with a dialog that you can use to test and obtain the connection. It is a completely un-intuitive GUI but it is better than the typing it by hand.
3. Write a macro that connects to the database using the connection string gained from step #2. To get the connection string, you just open the .udl file in notepad and copy out the text in the last row. The macro should obtain an ADO Recordset object from the document numbers table. I used a query as my filter but you there are other ways. The query is the simplest. I designed my query in Access’ query builder GUI and copy/pasted the text from there to the macro.
4. Test the macro and verify that it is retrieving the correct value (i.e. from the correct row and column) and that it is correctly incrementing the value for next time.
5. Once you are correctly accessing the database and obtaining the correct information, write a SolidWorks macro to register for notification of the File, New event. It is officially known as the FileNewNotify2 event. If you don’t know how to do this, then see my post on registering your macro to receive event notifications from SolidWorks.
6. Once your new macro is getting called reliable for the FileNewNotify2 event, copy the code from the first macro (the database macro) into the new macro. Add the database function so that it is called by your FileNewNotify2 event handler. The new macro should then copy the document number returned from the database function to the new document’s title.

© Jeff Cope for Extensible By Design, 2008. | Permalink | 7 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 Database, SolidWorks, SolidWorks API.

How To Destroy References To SolidWorks From Managed Code

Jeff Cope — Thu, 20 Dec 2007 14:48:13 +0000

Memory management in the COM world is a lot more straightforward in the COM world than it is in the .NET world. Destroying COM references from .NET applications typically includes trial and error, calls to mysterious APIs, prayer and in the end, frustration. It always reminds me of tying to kill a vampire, werewolf or some other bloodsucking, mythical creature that just won’t die. It is because of this that my heart warmed with joy when I saw that some kind soul over at SolidWorks wrote a post to once and for all clarify how to destroy references to SolidWorks’ COM objects.

Tech Tip From SolidWorks On Destroying References To Unmanaged (i.e. COM) Components

We have all heard about the promised land of .NET where you don’t have to worry about memory management. The garbage collector handles all of the memory management for you. You just instantiate your objects, use them and then forget them. ~~Santa Clause~~ The .NET Garbage Collector determines when the objects are no longer needed and then destroys them and reallocates the memory. Anyone who does API programming with SolidWorks in .NET either knows or should know that this is not the case for unmanaged (i.e. COM) components (e.g. the SolidWorks class library used for interfacing with SolidWorks). Some CAD systems (e.g. Unigraphics) have implemented a .NET API interface but SolidWorks still uses a COM API interface. This means that SolidWorks API developers using .NET must destroy SolidWorks objects “they d@mn self.”

And remember…

…Even a man who is pure in heart
and says his prayers by night
may become a wolf when the wolfbane blooms
and the autumn moon is bright.

© 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 .NET, SolidWorks API.