.NET

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.  continue

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

 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

  continue

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

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.

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!