By default if you HAVEN'T changed anything yet, the default language is VBA and the macros are saved with .swb file extension. Note it is pretty much the same VBA you would use IF you wrote a macro for excel, word...any of those office programs. The API calls for SolidWorks have just been made available to you a little easier. Because it is the same it's easy to write a SolidWorks macro that interacts with them and open/save those file types and send out emails.
After you record a macro and the Save As dialog appears you can choose what type of macro you want to save it as. The VBA macro is probably the most common because it is the default. But I've recently started to use the VSTA option as the code editor is a little more robust and feature rich. The VSTA macro is written in VB.NET, similar to VBA but more powerful, feature rich from what I've seen.
There is also the option to write it in C#...if that is more familiar to you.
Also the SolidWorks API help online usually has examples written in all three languages, but not always, so trying to follow those examples for certain tasks can be a bit challenging.
There are a few other ways of writing "macros" to interact with SolidWorks but they are a lot more advanced and they are no longer just a little macro. The first being an Add-In, like the Vault for example, or a full fledged stand alone application that can use SolidWorks, but it might be doing it's own thing and just needs SolidWorks for a task.
I recommend starting to learn with VBA and then move up to VB.NET once you have gotten used to writing macros.
If you're new to programming, go for VBA.
It depends on what is your goal in a long run when it comes to learning a programming language. I assume you do not have previous programming experience in either VBA or C#. I am also writing this post as a software developer, first and foremost.
If you go with VBA, it will be slightly easier for you to get into the world of SolidWorks API programming, as some examples from official SolidWorks documentation are written only in VBA. Majority are available in both languages.
However, VBA is less safe than C# if you are not careful. What I mean here is that it's easier for you to introduce bugs if you are a beginner. Furthermore, if you want to expand your knowledge and go beyond writing SolidWorks API, VBA won't get you far. It is an outdated language, used mostly because it is deeply rooted inside engineering applications, and since engineers learn from other engineers, it is there to stay.
If you go with C#, it will be just slightly harder to start off, but there is a ton of resources online to get you on your feet. It is a highly respected language and has a bright future ahead. It is not without its own flaws, but which language is not? Your code will look more clean and more organized. You might find less support from other SolidWorks API developers, though. Most of the API content on these forums is VBA based. This should not concern you much, as it is very easy to take couple of lines from VBA examples and transfer them to C# syntax. These couple of lines of code are all you need, in the end.
SolidWorks is a powerful software and it allows you to access most of its functionality through API. API is designed far from perfectly, but it serves its purpose and you can accomplish so much with it.
About your specific question reagarding which one will become obsolete sooner: in software development circles, VBA is already on a verge of being considered obsolete. C# is far from that.
To emphasize again: choosing any language will not be a mistake.
Beware of documentation!
However, what would be a mistake is to learn from SolidWorks documentation API examples. Do not take them as any serious guidelines if you want to learn to write a proper code. They are badly documented, mostly poorly written and applicable to a very specific user cases. Program loops and branches in those examples showcase very bad programming practices and should be avoided.
I will give you just one example that I just happen to have opened in my tab right now and that made my eyes bleed:
If (swSplineHandle(i).TangentDriving) Then swSplineHandle(i).TangentDriving = False Else swSplineHandle(i).TangentDriving = True End If
Imagine if you could rewrite this as:
swSplineHandle(i).TangentDriving = Not swSplineHandle(i).TangentDriving
Oh wait, you can.
be careful with boolean and Not. I have seen SW API situation where it is not working.
Nikola Malesevic : Take it easy on the SOLIDWORKS API docs . It's where most of us have learnt the API. Granted, I have to admit you're right in some respect. Something I wanted to point out is that in SOLIDWORKS API 2013 and older the api was compiled in CLR 2.0. The examples thus do not make uses of any the cool C# language features. Most of the people who use the API are not software engineer by education. Those are my two cents.
VBA without question.
- It's easier to learn
- It's widely used as a back-end (think MS Office)
- It's got a larger support base
Also, while VB may not be as cool as C#, I have yet to find something done with C# that cannot be done with VB.
I'm not a software engineer but I've made a dozen or so Windows applications using Visual Basic and thousands of VBA scripts and macros over the years.
Yeah VBA is a good way to learn. Now that I use C# on a regular basis, it feels very cumbersome though. That being said, I still use it on a daily basis to whip up a nice macro. It just takes a few more lines to work with arrays and stuff