8 Replies Latest reply on May 24, 2017 4:47 PM by Peter Brinkhuis

    Which API language to learn?

    Gordon Rigg

      Obviously I am a newbie to this and I don't yet know what I'm talking about...

      I'm a little confused, because there seems to be a choice of API language.

      When I record a macro, is there some sort of setting that decides what that macro is recorded in?

      Or is it that the macro can be opened and edited in a choice of languages? C# VBA etc?

      how come the macros I've looked at, recorded, and received from others, all seem to be written in a similar way when they might be different programming languages?

      If I am going to figure out have to write this stuff, which one is least likely to become obsolete?

        • Re: Which API language to learn?
          Chris Mackedanz

          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.

          • Re: Which API language to learn?
            Amen Allah Jlili

            If you're new to programming, go for VBA.

            • Re: Which API language to learn?
              Nikola Malesevic

              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
                swSplineHandle(i).TangentDriving = True
              End If


              Imagine if you could rewrite this as:


              swSplineHandle(i).TangentDriving = Not swSplineHandle(i).TangentDriving


              Oh wait, you can.

              • Re: Which API language to learn?
                Matt Finley

                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.