What kind of improvements should we make?

[brinkdinges]

As you mentioned in #72 , what kind of improvements are you planning to do in the near future? I probably won't be able to help with the architecture since you're 10 levels above me, but still.

There are things that I can move from my add-in to SolidDna though. I'm working with bodies, persistent IDs, features, views, sheets, tables, annotations. I was able to improve my app's stability by creating more objects (Persistent ID, ModelTitle, Angle, FilePath/DrawingPath/AssemblyPath) and fewer strings and arrays.

What kind of features do you want in SolidDna, and which kind of features would you like to keep out of it?

[angelsix]

My plan was to bring the entire API of SolidWorks into SolidDNA and I still will. I got so busy the last 12 months this just totally stopped. I'm more free now again so I will start dedicating at least a day a week (well, a night) to doing this.

I will start making BatchProcess 3, and that will drive more requirements into SolidDNA as the features it uses I will then make in SolidDNA.

Really I just need the demand from people saying what part of the API they would like adding, and a way to make an example tutorial using it so I can show it and test it that way.

Any suggestions on what you would like adding next and I'll try and do it tomorrow.

[brinkdinges]

Great to hear that you'll be working on it again.

I've been thinking about this for a few hours. Here are a few suggestions:

• I'd love to have parts, assemblies and drawings in there, because right now you have to use the unsafe object for most of the type-specific actions. I still have 100+ references to the unsafe model types.
• I'm working with drawings mostly for my own product, so I'd love to simplify working with sheets, views, their coordinate transformations.
• Their MathUtility can also use some improvements, although it is easier to work with in C# because arrays work better than in VBA. Every time a VBA test macro reaches needs a math action, I don't ever bother continuing.
• Any method that returns an object or null, but is in fact an array or a more complex structure, and any method that takes over three arguments is ready for a wrapper in my opinion. Examples:
  • ISheet.SetProperties2 (8 arguments)
  • IDrawingDoc.NewSheet4 (16 arguments)
  • IView.GetPolyLines6 (horrible structure returned, v7 is sometimes slow. Don't think many people will need this one)
• I like the way features and components have been added and that you can perform an action on all of them. Would like to see more of that.
• Above all, it would be great if we could add tests. I use Moq and sometimes I can mock ISldWorks, but I couldn't completely mock my DrawingView object because then I'd have to mock multiple SolidDna objects first.

[angelsix]

I've exposed the Part, Drawing and Assembly now. We can expand those classes to include safe calls. I've added a few as examples, should be easy to add more now for what you want f447da3

[angelsix]

Added all drawing methods up to AutoBalloon now... man that AutoBalloon needed a LOT of supporting classes. That will do for now. I'll carry on later next week.

[brinkdinges]

Great start. It's gonna take a lot of work to do the entire API this way, but maybe others will be tempted to add more, now that they see you're making relatively small changes. I'm glad we can finally use lists, objects and enums.

I'll add some drawing methods as well. I'll start somewhere in the middle of the method list so we don't do the same work. It's a busy week, but I'll try to find some time.

[Link-IT-Developer]

Hey guys and awesome work from both.

I'm just starting with new project and until now i have used my own SW API wrapper. After doing some research I have found this awesome project and i just love it. So my idea is to move all my existing SW API wrapper code to this project.

@brinkdinges if you need any help with Drawings, Views, Geometry just give me a beep.

[brinkdinges]

Great to have you on board. What kind of software have you built for SolidWorks?

I'll remember the offer, thanks :)

[Tyronnosaurus]

Hey guys, in my case I'm studying how to programmatically move components inside a subassembly, so that I can visualize the way a machine moves. Kind of an integrated digital twin, which would remove the need to export CAD to an actual digital twin application.

For now I'm just getting acquainted but in the future I'd like to contribute by either:

• Integrating IComponent2::Transform2 into SolidDNA
• Or adding a simple way to edit dimensions in real time (to control a skeleton 3D sketch).

[brinkdinges]

The whole transforms side of SOLIDWORKS could use a refresh, that is true. Every time I have to work with them, I have forgotten how to do it. So I collected all of my knowledge in one article:
https://cadbooster.com/complete-overview-of-matrix-transformations-in-the-solidworks-api/

I would suggest using SOLIDWORKS motion to do those studies. I created about a thousand studies from software once. You cannot do everything from the API, setting motion points in the timeline is not possible for example, but you can create basic studies.

[Tyronnosaurus]

Hey, thanks for that. Coincidentally I had it open already in another tab.

In my case it's less 'visualizing preprogrammed sequences' and more 'synchronizing to an external industrial controller simulation'. Basically, I would move machine axes within Solidworks with buttons on another program.

Any useful advances I make in this repo, I'll try to add them to SolidDNA:
https://github.com/Tyronnosaurus/SolidWorks-OPC-UA-Digital-Twin

[brinkdinges]

Ah right, cool :) I like the concept and I understand how SOLIDWORKS could do this because parts have existing relations. I'm just wondering how suitable it is to do these kinds of (nearly realtime) visualizations.