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 : )
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
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!
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) :
If you enjoyed this post, make sure you subscribe to my RSS feed!
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 continue
If you enjoyed this post, make sure you subscribe to my RSS feed!
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, continue
If you enjoyed this post, make sure you subscribe to my RSS feed!