First line is a static variable set in macro. You can only use it within SolidWorks macro while Create/GetObject is VB6 function you can use it in any VB6 compatible projects.
Regards, Artem Taturevych | Snr. Developer | IC3D ANZ
IC3DSteel – New Steel Solution for SolidWorks
In addition to what Artem has mentioned,
Application.SldWorks gives you current running instance of SolidWorks whereas CreateObject("SldWorks.Application") gets and creates an instance of the default version from the registry, if you search for HKEY_CLASSES_ROOT\SldWorks.Application\CLSID you can find which version is "Solidworks.Application" using by default.
This might lead to issues if multiple versions are installed on the machine, for instance if you are running SW 2014, when you use CreateObject("SldWorks.Application") it creates an instance of SW 2013 if that is the default version in registry.
If you want to use CreateObject or GetObject then include the version that you want to use, in the class string.
for SW 2012
for SW 2013
for SW 2014
Thanks Santosh for this detailed information.
Where can I find these things, in the help section ?
This information is actually generic information which I presented in SolidWorks context, the same goes for other apps as well e.g. Excel
The difference is that the first the compiler binds the variables' type/method calls at compile time. This basically is like replacing method names with memory addresses for the compiler. The compiler has knowledge of which types/methods to bind thanks to the libs you have set from your Tools > References. The downside of this is that if you mess up your references, then your code will not compile. You are not the compiler anything to bind to!
Consequently, your code can compile without setting any references. Here, you are giving the compiler the task of doing the binding during the runtime of the macro. The problem is here is all of your variables during compile time must be defined as objects (since you have no references set). The good thing about late binding is that excellent for resolving version conflicts.
Unless you memorize the solidworks api method calls by heart for every version, you're probably better off using early/static binding.
SolidWorks API Training & Services
If you want to get the running SolidWorks session use
Set swApp = GetObject(, "SldWorks.Application")