Programming in SolidWorks, how important is it?

[AlexLachance]

Hey guys,

I wanted to start a little conversation about programming in SolidWorks because I'm always looking for new tools to add to my toolset and figured programming might be a good one concidering that you can develop your own macros and other tools of that nature to help simplify processes, but I have little to no programming experience.

I have done some HTML and C++ in my younger days when playing Starcraft and building websites but I was doing it from something already existing, adding to it, not creating. What I mean by that is that I understand programming better then most people who've never played around with it but I have not dwelved enough into it to actually be able to build something from scratch or to fix simple issues that the macro recorder will add in a recorded macro.

I was wondering, why would someone need to program in SolidWorks and what it could bring forward and what to watch out for while also wondering what would be the best avenue to learn programming for SolidWorks.

[AlexB]

There are two categories of SW programming. The first group is macros programmed in VBA (this is not the same as VB.net). Some support for c# was added for macro creation but I could never get that to work well. The second group is add-ins and external standalone programs. These require being written in a language supporting the .net framework (c# and VB.net).

The language with the most support right now is c#, however VB.net is just about the same functionality with a very different syntax.

Macros are relatively limited compared to what programming an external tool can offer.

The reason a lot of people get into programming is to automate. If you do the same thing hundreds of times a week and it can be done faster and more accurately with an automated script, why not try your hand at creating a macro or external tool to help you save time?

The best way to start is to begin googling. SW has a very detailed help page online for all of the API functions along with an example for a lot of them too.

[TTevolve]

Programming can be a huge time saver for repetitive task like Alex said. I have a bunch of macros that do certain things when I run them. My favorite is one that creates a list of custom properties in a model or assembly with default entries. This is much faster then having to enter each one by typing it in by hand, and eliminates typos. I use this on imported parts or old parts to get them up to our current list of properties (we have 24 standard properties per part that have to be added).

I have another that will fill in a certain property with a specified value for all parts in an assembly. This is a huge saver for when I do a pack and go and want to update a property on all the parts to a new value. like changing them all to the current date. I have not done much of the script programing since I am really rusty with coding, but they can be big time savers as well. It kind of has to be for a repetitive task though as the time to make a macro/program has to be considered, if you only got to do something once it's usually faster just to do it.

[SPerman]

Over the years I've become somewhat proficient in a couple of languages by finding examples and tweaking to my needs. I wouldn't let a lack of formal training stop you from trying to write your own macros add-ins.

[Frederick_Law]

The basic: programming is to do what you can do repetitively.
Need to do a set of different commands, program it.
Need to repeat it 1000 times, program it.

Next step, save time.
Set it up so it can run at night. You got extra 12 hours work that your boss not gonna pay LOL.

Next, new function.
Create or enhance function in the software.

Now the "problem" with programming for another software is API.
You need to learn the syntax and rule of the API.
Basic and good structure programing knowledge will help a lot.
VB really doesn't help new programmer trying to do API.
It's like learning French and translate it to Chinese at the same time.
Also you're limited by API on what you can do.

Macro is great for simple program.
Addin is for bigger more complex program. Event driven is better in addin.

Visual Studio Community is free. It can be used to code addin.

[AlexLachance]

Programming can be a huge time saver for repetitive task like Alex said. I have a bunch of macros that do certain things when I run them. My favorite is one that creates a list of custom properties in a model or assembly with default entries. This is much faster then having to enter each one by typing it in by hand, and eliminates typos. I use this on imported parts or old parts to get them up to our current list of properties (we have 24 standard properties per part that have to be added).

I have another that will fill in a certain property with a specified value for all parts in an assembly. This is a huge saver for when I do a pack and go and want to update a property on all the parts to a new value. like changing them all to the current date. I have not done much of the script programing since I am really rusty with coding, but they can be big time savers as well. It kind of has to be for a repetitive task though as the time to make a macro/program has to be considered, if you only got to do something once it's usually faster just to do it.

Why not have the properties in your default template...?

Most of our properties are driven by CustomTools so in that sense programatically it wouldn't really be a necessity but it could certainly be an option to concider "replace CustomTools with a home-made solution", but I doubt we'd go this venue since we are still a relatively small company.

[bnemec]

Why not have the properties in your default template...?

Most of our properties are driven by CustomTools so in that sense programatically it wouldn't really be a necessity but it could certainly be an option to concider "replace CustomTools with a home-made solution", but I doubt we'd go this venue since we are still a relatively small company.

Nothing against Custom Tools at all. I'd like to test the premise that home-made solution is not practical for small companies. I don't know that there's a correlation between company size and whether or not they should make their own tools. I feel it has more to do with how well their needs fit with what's available in the market. While most professional solutions will offer to customize their product for you, we've found that option puts the cost out of range for a relatively small company. I feels like it's either we contort our process to fit what's available, just do without the tool or make our own.

When I've been tempted to write a "quick" app or add-in I try to honestly answer myself, "will this take more time to develop than what it will save me/us in a year?" If the answer is yet, then I grudgingly keep doing the manual route.

Last note, don't forget about consistency. Users introduce variation, often random variation on what should be an identical process each time. If the unexpected inputs are properly handled, the automated solution will add consistency and predictability back into the system. Unraveling what users did when they encountered an unexpected input can be the most challenging/entertaining part of Admin job. Those users have taught me much about how my apps/add-ins should not handle exceptions.

[JSculley]

Using the API is more of a 'want' than a 'need'. Open source software guru Eric Raymond once said this:

"Every good work of software starts by scratching a developer's personal itch."

If you want to be a programmer, you have to have a problem (itch) that you want to solve (scratch). For me with SOLIDWORKS there are two interlinked areas: automation and error prevention. What tasks are repetitive, have a lot of steps or take a lot of time. What tasks are prone to user error. Automating these will typically make them faster and eliminate user errors.

If you have an itch you want to scratch, I would recommend starting with C#. VBA is a dead end and VB.NET is just C# made to look like VB. There's a good C# tutorial at w3schools.com. Use Visual Studio Community to learn, and when you have something you want to actually use at work to improve the productivity of SW users, get your company to purchase a Visual Studio Pro subscription for you ($45/month).

[AlexLachance]

Nothing against Custom Tools at all. I'd like to test the premise that home-made solution is not practical for small companies. I don't know that there's a correlation between company size and whether or not they should make their own tools. I feel it has more to do with how well their needs fit with what's available in the market. While most professional solutions will offer to customize their product for you, we've found that option puts the cost out of range for a relatively small company. I feels like it's either we contort our process to fit what's available, just do without the tool or make our own.

I don't think it's a question of it being pratical, I believe it is a question if initial investment. People are rather hesitant to give a large ammount of money for something they aren't quite sure will do what they desire.

The subscription alternative was most likely made to adress this. I know when we made the switch to SolidWorks, the price of the licences made everyone jump, but nobody even blinked on the reccurring cost every year which is pretty equivalent.

Sort of like on a personal level, when you want to get into something such as working out in a gym, it's very costy to get into it by yourself but if you go the subscription way, then you avoid the costs of the hardware and somewhat ensure the maintenance of the equipment. Most people won't build a gym in their house because it is a significant investment but will pay a monthly fee to go to the gym that would most likely end up surpassing the cost of having your own gym.

[Tapani Sjöman]

Here is my first macro that rotates a view in a model isometric to left down. I needed it to get isometric views to my drawings. After finding how macros work, I was able to make some more complicated ones.
------
Option Explicit

Dim swApp As SldWorks.SldWorks
Dim model As SldWorks.ModelDoc2
Dim view As SldWorks.ModelView


Sub main()

Set swApp = Application.SldWorks
Set model = swApp.ActiveDoc
Set view = model.ActiveView

view.RotateAboutCenter 0.6154797086799, -0.7853981633974

model.ViewZoomtofit

End Sub

[TTevolve]

Why not have the properties in your default template...?

Most of our properties are driven by CustomTools so in that sense programatically it wouldn't really be a necessity but it could certainly be an option to concider "replace CustomTools with a home-made solution", but I doubt we'd go this venue since we are still a relatively small company.

The custom properties are in our default templates, we use the macro to add the same custom properties to imported models or old models that were made before our current templates were put in use, any model/assembly that dose not have the custom properties can have them added. This is just an example of one of the ones that I have done to make my job easier.

The point is, like was said above that you need to do a quick cost/benefit analysis. Making a macro takes some time, and the more complex the more time it usually takes, but if it's repetitive task and you have to do it multiple times a week/month/year then it's usually worth the cost in time and effort to make the macros.

[josh]

If you have an itch you want to scratch, I would recommend starting with C#. VBA is a dead end and VB.NET is just C# made to look like VB. There's a good C# tutorial at w3schools.com. Use Visual Studio Community to learn, and when you have something you want to actually use at work to improve the productivity of SW users, get your company to purchase a Visual Studio Pro subscription for you ($45/month).

Any specific reason you're calling VBA a "dead end"? It's easier to learn, easier to understand, easier to debug, has more tutorial/sample code available, more concise, easier to share, easier to deploy.....

I would 100% agree that C# is more powerful, more flexible, and at some point, you can get to things that you can't do with VBA that are possible with C#. There are also built-in libraries for C# that make some things easier, especially related to file I/O, networking, higher-complexity UserForms, certain OS functions, etc.

This is just my current understanding/opinion and I’m definitely open to being educated but…

I think the likelihood is very low that someone whose main job is NOT programming will go from “hey, should I start learning this macro stuff?” to bumping into the limitations of VBA is very low. A useful macro that can save a bunch of time does not have to be complicated or high-powered. If you save 3 clicks, but save those 3 clicks multiple times a day across 10 users, you can make the time back pretty quickly. I have a lot of useful macros that are like one page of code. I’ve also written macros that are thousands of lines that work just fine. Some have been in use for over 15 years. So far I can’t think of anything that I needed to do that VBA couldn’t but C# could have.

I think the biggest functional advantage to C# would be for applications where you want the code to run every time SW starts, and you are wanting to monitor events. For this, add-ins are definitely superior because you can set up SW to run them every time it starts. You can’t really do that with VBA macros. You can create a shortcut that will start SW and immediately run a macro, but it won’t run if you start SW by double-clicking a file in Windows.

I feel like telling someone they shouldn’t bother with VBA and they need to go straight to C# is like telling the dude that wants to go get a couple loads of mulch on the weekend and haul his trash to the dump that he needs to buy a lifted F350 Duramax dually.

[JSculley]

Any specific reason you're calling VBA a "dead end"? It's easier to learn, easier to understand, easier to debug, has more tutorial/sample code available, more concise, easier to share, easier to deploy.....

Easier to learn? Not really. Especially in a macro context where the underlying program structure is created automatically for you. Program logic is program logic. You have the same hurdles starting with VBA vs. C#. Once your over the hurdles, C# is infinitely more useful.

And actually, SW throws some unnecessary VBA hurdles at you. For example, when you create a new VBA macro, SW generates this statement:

Code: Select all

Dim swApp As Object

whereas the C# macro has this:

Code: Select all

public SldWorks swApp;

Only one of these will work with Intellisense. The first thing I do every time I create a VBA macro is replace it with:

Code: Select all

Dim swApp As SldWorks.SldWorks

Easier to understand? Not really.

Code: Select all

Dim mDoc as ModelDoc2
Set mDoc = swApp.ActiveDoc
Dim x as Integer
Set x = 1 'ERROR

vs.

Code: Select all

ModelDoc mDoc = swApp.ActiveDoc as ModelDoc;
int x = 1;

VBA is inherently inconsistent. Another great example is calling methods (subroutines):

Code: Select all

mDoc.ForceRebuild3 True 'OK
mDoc.ForceRebuild3(True) 'OK
retval = mDoc.ForceRebuild3(True) 'OK
retval = mDoc.ForceRebuild3 True 'Not OK

VBA methods themselves are annoyingly split into subroutines and functions.

Easier to debug? How about this example:

Code: Select all

Sub main()
    Set swApp = Application.SldWorks
    Dim v1 As String
    v1 = "Hello"
    Dim result As Double
    result = AddTwoValues(v1, swApp)
End Sub

Function AddTwoValues(value1, value2)
    AddTwoValues = value1 + value2
End Function

It compiles without complaint, but when run, gives you an error.

In C# this stuff is caught at compile time, which is always better.

More tutorial/sample code? For a beginner, nearly every example in the API help has both VBA and C#. By the time you move past the beginner stage and have general language questions, I'll take the 1.6 million Stack Overflow search results for C# over the 200k results for VBA.

More concise? Every variable in VBA has to be declared on a line separate from its first use. This most basic programming task is always 2x the line count. And again, once you get past the beginner stage, the conciseness gap widens significantly in favor of C#.

Easier to share/deploy? C# source files are text. VBA is binary. To share the compiled macro is a matter of copying six or so files in one directory for C# vs. a single file for VBA. Not a significant difference.

I would 100% agree that C# is more powerful, more flexible, and at some point, you can get to things that you can't do with VBA that are possible with C#. There are also built-in libraries for C# that make some things easier, especially related to file I/O, networking, higher-complexity UserForms, certain OS functions, etc.

Text search/processing/manipulation, graphics, collections, generics, logging, globalization, database access.....

This is just my current understanding/opinion and I’m definitely open to being educated but…

I think the likelihood is very low that someone whose main job is NOT programming will go from “hey, should I start learning this macro stuff?” to bumping into the limitations of VBA is very low. A useful macro that can save a bunch of time does not have to be complicated or high-powered.

My point is that the code for a C# macro and a VBA macro to do something simple are practically identical. Why not use a language that is more consistent, safe, modern and useful outside the world of macros?

I have a lot of useful macros that are like one page of code. I’ve also written macros that are thousands of lines that work just fine. Some have been in use for over 15 years. So far I can’t think of anything that I needed to do that VBA couldn’t but C# could have.

I would wager that any of those complex VBA macros rewritten in C# would be shorter and more elegant.

I think the biggest functional advantage to C# would be for applications where you want the code to run every time SW starts, and you are wanting to monitor events. For this, add-ins are definitely superior because you can set up SW to run them every time it starts. You can’t really do that with VBA macros. You can create a shortcut that will start SW and immediately run a macro, but it won’t run if you start SW by double-clicking a file in Windows.

Macros vs add-ins are a whole separate topic, but if you are using C# from the start, you can transition from macro to add-in to application without much work.

I feel like telling someone they shouldn’t bother with VBA and they need to go straight to C# is like telling the dude that wants to go get a couple loads of mulch on the weekend and haul his trash to the dump that he needs to buy a lifted F350 Duramax dually.

To me, VBA is a cramped Yugo with a broken AM radio. C# is a spacious SUV with Bluetooth and a Sirius XM subscription that can seat six adults OR haul mulch/trash. It's a matter of perspective. No one using C# is wishing they could work with VBA. Lots of people stuck using VBA wish they could use C#. That's why I consider it a dead end.

[SPerman]

When I first started programming macros, I tried to go the C# route, but I never could figure out all of the hoops to jump through to make it work. Based on this thread, I don't think things have improved.
https://www.cadforum.net/viewtopic.php?t=3113

I wrote a lot of code in VB6 back in the day, so I am familiar with the language. My biggest complaint with writing in VB6 is that the editor hasn't been updated in 25 years, and is missing a bunch of features available in modern editors. I assumed intellisense didn't work, but jsculley has pointed out that I'm not using the proper syntax.

[Frederick_Law]

Any specific reason you're calling VBA a "dead end"? It's easier to learn, easier to understand, easier to debug, has more tutorial/sample code available, more concise, easier to share, easier to deploy.....

It is easy because it's sloppy.

Dim, dim, dim, dim dim dim, dim dim all the way.
A DIM can and will wipe out old variable and cause unexcepted result and crash.
Like "DIM i as integer", later "DIM i as double", then "DIM i as string". Have fun try to debug those.

Add Infer to that and "DIM i = 1", "DIM i = 0.5", "DIM i = "1"".

The "powerful" late binding break intelisense. So new user can create imaginary method/class that sometimes work.
It's great when it works and when you know what you're doing. Simple object conversion.

And they're the usual programming error that allow security breach.
They also make it difficult to transfer to other programming language.

VBA is ok if programmer already have programming knowledge and discipline.

In the hands of wanna be macro writer, it's truly disruptive.

Add ChatGPT and it's truly AI disruptive innovation.

First 3 lines of my VB code:
Option Explicit On
Option Strict On
Option Infer Off

[Frederick_Law]

I assumed intellisense didn't work, but jsculley has pointed out that I'm not using the proper syntax.

Not syntax.
It's not declaring with proper type.
object is base type for everything.
VB could figure it out at runtime but not at build/compile. Hence all those compiled programs that won't run.

Yes, it's easy for new programmer because they don't need to know all the object name.
It's also hard because you have no idea what went wrong.
The line that doesn't work could be because of the first declare.

[CarrieIves]

Most of the SolidWorks macros you could find online to copy when I started were in VBA. You can also use this language to program Excel macros.

I don't have very many macros because there aren't that many things that we have that are repetitive, but we do save PDFs and STEPs with revision information from our properties in the filenames. Having a macro that does it is so helpful. I even got tired of putting dates at the end of our STL files and modified my STEP macro (which asks if you want to add any text into the filename) so that was consistent.

It's worth at least taking some time to try to figure out what you can do.

We also have many people at our company that can write python scripts. We have a Python script that takes a SolidWorks indented BOM output (text) and converts it to a nice Excel file.

Look at repetitive tasks or tasks that need to be done just so. Those are ones I would focus on.

[dave.laban]

Macrofeatures seem to be another way of achieving remarkable results if you know what you're doing with programming. When I first saw this it blew my mind as to what would be possible. https://r1132100503382-eu1-3dswym.3dexp ... cnLotrElUg

[AlexB]

Macrofeatures seem to be another way of achieving remarkable results if you know what you're doing with programming. When I first saw this it blew my mind as to what would be possible. https://r1132100503382-eu1-3dswym.3dexp ... cnLotrElUg

That's an impressive project you linked. I've worked a bit with macro features but that is on a whole other level