Looking for Suggestions and Feedback
-
- Posts: 1
- Joined: Mon Mar 08, 2021 4:05 pm
- x 2
Looking for Suggestions and Feedback
Years ago, Mike Puckett was bugging me to write a book on Solidworks. I told him that I thought there were already plenty of Solidworks books out there and if I WERE going to write a book on Solidworks it would be about how to write Solidworks APIs because I didn't see any good books on that topic. So, now I am looking at starting writing a book on how to write APIs for Solidworks.
I am interested in feedback from users on the following:
what language do you use to write APIs or would you use if you decided to try it? I am thinking VBA, but maybe I am wrong, so I want to know what you are using or would want to use
what types of APIs are you most interested in? when do you think - darn, Solidworks won't do what I want, so I am going to try to write my own add-in.
I am not a big fan of the macro recorder. I find it more trouble than it is worth. But maybe that is just me, so I wanted to hear what you think - when you are looking to automate a task, do you use the macro recorder to create your starting point or skip directly to writing code?
Thanks in advance for your input. I will be acknowledging responders on my acknowledgements page in my text.
I am interested in feedback from users on the following:
what language do you use to write APIs or would you use if you decided to try it? I am thinking VBA, but maybe I am wrong, so I want to know what you are using or would want to use
what types of APIs are you most interested in? when do you think - darn, Solidworks won't do what I want, so I am going to try to write my own add-in.
I am not a big fan of the macro recorder. I find it more trouble than it is worth. But maybe that is just me, so I wanted to hear what you think - when you are looking to automate a task, do you use the macro recorder to create your starting point or skip directly to writing code?
Thanks in advance for your input. I will be acknowledging responders on my acknowledgements page in my text.
- AlexLachance
- Posts: 2174
- Joined: Thu Mar 11, 2021 8:14 am
- Location: Quebec
- x 2353
- x 2008
Re: Looking for Suggestions and Feedback
I would priviledge whatever is concidered to be the most efficient coding to use for SolidWorks. I have used VBA a little in the past so I would tend to go that way, but honestly I know so little about VBA that I'd have just as much to learn of it then any other language.
Never took class for programming or anything, but I created a website or two when I was younger for teams I had joined in games, so the background I have is like fixing little issues and adding little things here and there, not starting from scratch.
The programmers who have built macros for us have used the macro recorder to get an idea of the jist when needed. If not needed then they just go and built it from scratch.
Never took class for programming or anything, but I created a website or two when I was younger for teams I had joined in games, so the background I have is like fixing little issues and adding little things here and there, not starting from scratch.
The programmers who have built macros for us have used the macro recorder to get an idea of the jist when needed. If not needed then they just go and built it from scratch.
Re: Looking for Suggestions and Feedback
Check out Mike Spems book on the topic.
You might consider what you think the future of SW Desktop looks like.
Best of luck!
You might consider what you think the future of SW Desktop looks like.
Best of luck!
Blog: http://dezignstuff.com
Re: Looking for Suggestions and Feedback
For something small which will not require lots of maintenance VBA macros are good (still good), although the VB6 language is pretty much dead. But still plenty of examples available in VBA. You should consider macro as a script, not applications. Scripts are still widely used, thus macros as well. Huge benefits are macro are trusted and easy to deploy (usually may not require admin authorization), which application will most likely require approval in the organization.what language do you use to write APIs or would you use if you decided to try it? I am thinking VBA, but maybe I am wrong, so I want to know what you are using or would want to use
But if you think that your macro can grow I would definitely go with add-ins or stand-alone applications with more sophisticated languages (C#, C++ or VB.NET). You can implement lots of extra features here such as automated unit tests, continuous deployment etc. There are few macros I developed which have started as simple scripts although grown so maintenance become an issue, and this is where I regret starting this as a macro and will be (or have) redeveloped that as an add-in.
Neither do I. Macro recorders may guide users in the wrong direction in terms of the development approach, in particular where it relates to selections. But macro recorder is still good if you want to find a certain API. So my rule of thumb - it is OK to use macro recorded as long as you are not going to use the recorded macro rather for the reference or copy line or two to paste into your bigger macro.I am not a big fan of the macro recorder. I find it more trouble than it is worth. But maybe that is just me, so I wanted to hear what you think - when you are looking to automate a task, do you use the macro recorder to create your starting point or skip directly to writing code?
Thanks,
Artem
xarial.com - making your CAD better
codestack.net - SOLIDWORKS API macros and tutorials
Artem
xarial.com - making your CAD better
codestack.net - SOLIDWORKS API macros and tutorials
Re: Looking for Suggestions and Feedback
I would prefer VBA as still lot of users (I mean new users mainly) prefer to use/learn thru VBA since examples are readily available, one can use macro recorder and also editing a macro is easy. But if you looking for a different one then I would prefer/suggest VB.NET as this is close to VBA
Deepak Gupta
SOLIDWORKS Consultant/Blogger
SOLIDWORKS Consultant/Blogger
- Ömür Tokman
- Posts: 359
- Joined: Sat Mar 13, 2021 3:49 am
- Location: İstanbul-Türkiye
- x 993
- x 345
- Contact:
Re: Looking for Suggestions and Feedback
Hello, first of all I would like to mention, I am not a software developer.
A few simple macros for excel with vba and a few desktop applications with C #, totally unprofessional but fulfilling my need.
I have never tried macros for Solid but if I tried I would start with VBA, there are too many resources, if I thought of a plugin I would think C #, it has a lot of resources and a solid background.
And I wonder what Rob, who writes his own macros and plugins, thinks.
A few simple macros for excel with vba and a few desktop applications with C #, totally unprofessional but fulfilling my need.
I have never tried macros for Solid but if I tried I would start with VBA, there are too many resources, if I thought of a plugin I would think C #, it has a lot of resources and a solid background.
And I wonder what Rob, who writes his own macros and plugins, thinks.
You ˹alone˺ we worship and You ˹alone˺ we ask for help.
Re: Looking for Suggestions and Feedback
The built in editor and VBA macros are extremely useful in situations where repetition can be automated.
"I wish I didn't have to select this folder and file format every time I want to export a PDF"
"It'd be nice to hide all the visible sketches in this document without having to click on each one-by-one"
"Is there a better way to export each configuration of this part as its own STL without having to activate and save each one manually?"
(The number of "I need a macro to save [file format] in this [file location]" topics in the old Solidworks api forum was astounding)
However, more complex tasks are typically automated outside of the built in VBA editor using VB.NET or c# to build a stand-alone or and add-in application in my experience. The built-in VBA editor can do a lot, however it lacks in debugging capability which is much more developer friendly in Visual Studio and other development focused applications.
"I wish I didn't have to select this folder and file format every time I want to export a PDF"
"It'd be nice to hide all the visible sketches in this document without having to click on each one-by-one"
"Is there a better way to export each configuration of this part as its own STL without having to activate and save each one manually?"
(The number of "I need a macro to save [file format] in this [file location]" topics in the old Solidworks api forum was astounding)
However, more complex tasks are typically automated outside of the built in VBA editor using VB.NET or c# to build a stand-alone or and add-in application in my experience. The built-in VBA editor can do a lot, however it lacks in debugging capability which is much more developer friendly in Visual Studio and other development focused applications.
Re: Looking for Suggestions and Feedback
Just some of my thoughts, probably not common or worth that much but hey, you asked.
- Don't leave out PDM API if possible. In my very brief experience many PDM Add-in actions need SW to do something. Going the other way, if PDM is used any stand alone Solidworks API will likely need to at least check out and check in files.
- I like C# but my background in programming is maybe different than many Mechanical Engineers.
- Are you targeting users that have never used an IDE or people with background in programming concepts? I wonder if I would be able to do any API work if I didn't already have some training in Object Oriented Programming. I worry as it is about lurking unknows biting me, I cannot imagine how to get a toe hold in the APIs if I have never seen an IDE or even an awareness of managed vs unmanaged. Can someone with no concept of Data Types or Data encapsulation do more than just copy, paste and hope? Maybe so, I don't know. How much background or foundation of non SW stuff do you lay down before getting to ISldWorks? What's an Interop again?
- Don't leave out PDM API if possible. In my very brief experience many PDM Add-in actions need SW to do something. Going the other way, if PDM is used any stand alone Solidworks API will likely need to at least check out and check in files.
- I like C# but my background in programming is maybe different than many Mechanical Engineers.
- Are you targeting users that have never used an IDE or people with background in programming concepts? I wonder if I would be able to do any API work if I didn't already have some training in Object Oriented Programming. I worry as it is about lurking unknows biting me, I cannot imagine how to get a toe hold in the APIs if I have never seen an IDE or even an awareness of managed vs unmanaged. Can someone with no concept of Data Types or Data encapsulation do more than just copy, paste and hope? Maybe so, I don't know. How much background or foundation of non SW stuff do you lay down before getting to ISldWorks? What's an Interop again?
- Frederick_Law
- Posts: 1944
- Joined: Mon Mar 08, 2021 1:09 pm
- Location: Toronto
- x 1634
- x 1466
Re: Looking for Suggestions and Feedback
I want to program in C#. Learn something I can use in the future.
I started program with AppleSoft, BASIC in Apple ][+. Assembly langrage. Pascal.
I started VBA in Inventor API.
VBA was dead, they brought it back to life. Don't know when it'll die again.
And its a "sloppy" langrage allowing new programmers to make all those nasty mistakes.
I started program with AppleSoft, BASIC in Apple ][+. Assembly langrage. Pascal.
I started VBA in Inventor API.
VBA was dead, they brought it back to life. Don't know when it'll die again.
And its a "sloppy" langrage allowing new programmers to make all those nasty mistakes.