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( ).
Dim swapp As SldWorks.ModelDoc2
Set swapp = GetObject(, “SldWorks.Application”)
Dim swDoc As SldWorks.SldWorks
Set swDoc = GetObject(“C:\MyFiles\myPart.SLDPRT”)
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.
If you enjoyed this post, make sure you subscribe to my RSS feed!