Author Archive

Every developer has a set of tools, books and websites that they rely upon for help in their quest to build quality software.  I thought there might be some folks out there doing SolidWorks API programming/development that would appreciate finding out tools other developers are using.  Hence, this post.

Below is a partial list of some of the tools that I rely on.  I hope you find something that is useful to you.  You may also have some tools that you rely upon that might benefit the rest of us.  If so, then let us know with a comment.  I will be posting a list of books and websites that I use also.

continue

If you enjoyed this post, make sure you subscribe to my RSS feed!

If I had a Dollar for every time I wrote a few lines of code to change a file extension on a path (e.g. MyPart.slddrw to MyPart.pdf) or to build a filepath from a folderpath and a filename then I would probably have a few thousand dollars.  In other words, enough to buy a loaf of bread in any developed country outside the US.  (Note to self:  Stay on topic and don’t get distracted by a rant on the pathetic state of the dollar)

 Anyways, my colleague Evan Basalik showed me a very easy way to do this with minimal code.  Even though I thought I had been all over the System.IO namespace, I never checked out the System.IO.Path section.  Here are some of the cool functions you will find in there:

continue

If you enjoyed this post, make sure you subscribe to my RSS feed!

Because so many SolidWorks API users appear to use either VBA or Visual Basic 6.0 as their primary development environment, I thought a post about upgrading to .NET might be in order.  There are endless possibilities for a topic even within that category but I feel that there are so many misconceptions about Visual Basic.NET amongst SolidWorks API users that it makes the most sense to use my little bit of time and real estate here to undo some of those misconceptions.  Those who do SolidWorks API development for their actual job should already know these but individuals who perform SolidWorks customization through the API as their “secondary job” or as a hobby might benefit from the post.

  continue

If you enjoyed this post, make sure you subscribe to my RSS feed!

What Does This Addin Do?

 This Addin “listens” for Command Button events to be “fired” from data cards in PDMWorks Enterprise.  This could be File Cards (i.e. for existing files or folders) or Input Cards (i.e. for new files or folders).  If the command string of the Command Button matches our criteria, then the Addin will pull the next Serial Number from a Serial Number sequence in the vault.  The best thing about the Addin is that the Serial Number sequence name is specified as part of the command string.  This means that the Addin can be configured very easily by a non-programmer to run on any number of different Serial Number sequences.  In other words, our Addin is Extensible (sorry, I couldn’t resist). 

 Why Do I Need A Custom PDMWorks Enterprise Addin For Handling Document Numbers When PDMWorks Enterprise Already Has “Serial Numbers” Functionality That Handles This?

 PDMWorks Enterprise is a great tool and the Serial Numbers functionality is very useful.  However, as implemented in PDMWorks Enterprise, the Serial Numbers are kind of wired directly in to the system and don’t allow much flexibility in terms of when and how they are used.  You either set your part number to be populated from the Serial Number sequence or you don’t.  There is no “let’s do it this way for this case and another way for this other case.”  By writing a very simple Addin, continue

If you enjoyed this post, make sure you subscribe to my RSS feed!

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 continue

If you enjoyed this post, make sure you subscribe to my RSS feed!