josh wrote: ↑Wed May 15, 2024 9:59 am
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:
whereas the C# macro has this:
Only one of these will work with Intellisense. The first thing I do every time I create a VBA macro is replace it with:
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.
