Here I have seen many posting link SWX with C# programming language. Therefore I am thinking to learn C# as well. Could you tell me please how it is useful to SWX? Because I haven’t seen any YouTube tutorial that links SWX with C#.
I really suggest you start learning C#, it's so much better than VBA to develop for. It feels more robust and there are way more (professional) libraries available.
Luke Malpass has many videos, on C#, on SolidWorks and on the combination I've learned a lot from him.
He also develops SolidDna, a wrapper for the SolidWorks API to simplify the process of talking to SolidWorks. It's on Github, so you can add you own improvements and he might add them to SolidDna. I've added a few small ones myself.
Peter Brinkhuis wrote: I really suggest you start learning C#, it's so much better than VBA to develop for. It feels more robust and there are way more (professional) libraries available. Luke Malpass has many videos, on C#, on SolidWorks and on the combination I've learned a lot from him.https://www.youtube.com/channel/UCJ3AxeCHGPZkMi3kRfCuiHw He also develops SolidDna, a wrapper for the SolidWorks API to simplify the process of talking to SolidWorks. It's on Github, so you can add you own improvements and he might add them to SolidDna. I've added a few small ones myself.
Peter Brinkhuis wrote:
I was going to recommend Luke's videos as well since they helped me greatly with creating the Add-In that I use. SolidDna is a fantastic tool to help users get started. The version that I got when I wrote the add-in didn't have all of the API commands I wanted but it wasn't terribly difficult to expose them the same way that Luke did with the rest of it. The major benefit is that Luke's code automatically handles a lot of the object disposal for you.
Edit: To contribute, I learned Java before I learned C# so I'm used to the syntax and object oriented nature of those languages. I can read VB.NET fine but I have a hard time coding in it due to the odd (to me) syntax.
I have the same intention as you and have just bought these two books.
C# 7.0 in a Nutshell: Amazon.co.uk: Joseph Albahari, Ben Albahari: 9781491987650: Books
I haven't finished them yet, but I really like what I have read so far.
In my opinion they are very thorough, clear and nicely paced
Peter Thanks for the links, I will take a look
The problem is to what extent C# is useful to SWX. If it a small fraction or you can do SWX without C#. There is no point of learning C#.
It all depends on you Maha
Why don't you just have a little go at some of the examples with VBA and see if you get excited by the potential.
These days the world is such an amazing place, there are so many opportunities, the hardest part is choosing what you want to do.
edit: just look at all these ideas that are flooding the forum at the moment, with a bit of programming magic you could help make them happen
There is no specific thing I do with SWX. As usual like others, I use SWX for designing purpose only. Further I was not taught C# link with SWX in college.
Maha Nadarasa wrote: The problem is to what extent C# is useful to SWX. If it a small fraction or you can do SWX without C#. There is no point of learning C#.
Maha Nadarasa wrote:
There is a big potential in learning a language and utilizing that with SOLIDWORKS for making lot of automation programs. The possibility has no limit except if there are no codes to do a certain thing. I'm a beginner in learning the API for SOLIDWORKS but have made many small small programs/macros that take away the repetitive task and reduce the time from hours to few minutes.
I understand that you are saying it is only helpful in CAM.
By automation programs I mean related to design. For e.g. exporting lot of files as PDF, DXF, etc.; updating file properties; creating new files based on master files and other inputs and similarly lot of similar tasks.
1-5N2K8J6 wrote: The problem is to what extent C# is useful to SWX. If it a small fraction or you can do SWX without C#. There is no point of learning C#.
You don't have to if you don't want to !
SW software is not designed for any specific industry use so API is provided so you can customize to what your needs
Please view the clip and tell me how long it would take you to put a number on each dim for inspection? with a simple code, I can do all with just a click
Christian Chu wrote: Please view the clip and tell me how long it would take you to put a number on each dim for inspection? with a simple code, I can do all with just a click
Christian Chu wrote:
Now I can partially understand how important programming language is with SWX. If you could attach the full work I can click and learn the differences.
I mean example can help to see complete usage of program in SWX.
I don't think it's a way to learn the language
You need to start with a very simple macro first. However, before that, you need to get some knowledge of the VB. Go to local library and get a VB book. Then you can go to SW API site and download samples and start from there
Just curious, did you add the inspection dim number to the dimension text or is it a separate note object that is grouped to it? If you edited the text, how did you get the bubble around just that portion? Sorry to derail things a bit.
Actually, I customized the gtol file to include all the symbols (number with box around it) and run the program to add them to the dim
I used the fist number for the view # and the second number of the dim #
EDIT: see the att. clip - which I can add or remove the inspection numbers
If you are in a CAD admin position or close to it then learning any automation tools is extremely important.
You can use it to export data to erp/mrp, find files in a 30,000 part library, create drawings and the list goes on and on.
Doing any of those tasks manually to 30,000 parts would take a life time for 1 person.
A few years ago I would of said the opposite, back then I used 5% of solidworks since all I really did was CNC programming.
if you are satisfied with VBA macro then there is no reason to learn something else. It depends what you want to accomplish with SWX automation. Do you need to do something that can not be done with macro? C# or VB.NET has more controls which you can use on userform. Selecting and sorting data is easier. Source code is saved as text and when you use sourcecontrol, you can compare history of your coding. Within macro you can’t protect your code to be read and modified by anyone else.
In my opinion, it is very important to learn at least one programming language nowadays. Whether it is C# or VB.NET is a matter of taste. With each of them, you are able to create programmes and add-ins. It is important to have a very good knowledge of the language before starting API programming with other programmes. Be aware that programmes can be very dangerous if they don't do what they are designed to do. If you are proficient in the language, you will probably experience daily situations in which you can think about optimizations through self-programming. It is only a question of cost-benefit whether the implementation is worthwhile.
You should also not underestimate VBA. In combination with the WinAPI almost everything is possible in a very short time. The countless macros in SolidWorks or Excel can be cited as an example.
In short, if you can programme, you can automate almost everything that users need to do by hand to save money and time.
At the begining, I suggest Solidworks VBA. Visual basic is very simple language and I learnt very fast although my profession is mechanical engineer. You can find a lot of example easily. Maybe later you prefer C#. Sometimes, you need to other understand programming language. So if you learn visual basic, you can use this information while using C#. In addition I am still using Vb.Net. I can create standalone or add-ins easily. Yep, C# is better than Vb.net. But it is enough for me now. But If I read c# code, I can understand. Maybe one day, I will pass C#. But the day is not today
why is C# better than vb.net? Can you explain it?
I came to know many shortcomings in vb.net eliminated in C#.
My friend knows both C# and VB. If I can remember correctly he told me that C# is attune with real world scenario that mean only child can inherit form parent and a parent can have many children. This is maintained in the C# not in the VB.
In VB other way a parent can inherit form child and a child can have many parents.
Both programming languages use INHERITANCE word but with above differences.
yes, you heard something .... But what is better? Compiled code is exactly the same, SWX API is exactly the same.
Agreed with Ivana. I'm not a hardcore programmer so I might not see the advance of the C# comparing to VB.NET.
To me, VB.NET syntax is more similar to VBA, and C# is something dff.
But basically, the compiled code is 100% same. There are all kind of apps (Free) which you can use to convert from VB.NET to C#
Ivana Kolin wrote: why is C# better than vb.net? Can you explain it?
Ivana Kolin wrote:
If you use SolidWorks Api. It is not difference between Vb.Net and C# . Vb.net makes something automaticallly instead of you. So you don't think about backround scenario. But if you use C#, you have to define everything. If you don't know how to define or backround scenario, it is hard to write code. I am happy with Vb.net. What I want, I can create easily. I suggtest Vb.net. Because at the end your code converts computer language. Doesn't matter which language use it.
In addition, if you want to make a new project except Solidworks api, you can try C#. Some tools are better than Vb.net But you don't need them while using Solidworks Api.
I use both, depends on the customer. There is not much difference, I hoped that Maha Nadarasa would do more research. To finish this, the question is not what to learn, but which one will you learn first. In combination with SW and VBA I would recommend VB.NET. Than is the step not so high. Of course, when company prefers C# than C#.
I agree with you.
As the name itself, "language", you can use it to communicate with the SW thru API. in the other words, you can use it to tell SW to perform tasks for you
Retrieving data ...