Hacker News new | ask | show | jobs
by wtallis 4103 days ago
And yet it still manages to be the ugliest kludge in my workflow. Just getting it to rebuild and reexport an updated model requires at least a full minute of it popping up windows all over the place—one each for every part, assembly, and spreadsheet holding the parameters—and I have to structure the rest of my code around the limitation that I can only have one SolidWorks instance running at a time while everything else is highly parallel. There's a problem when the CAD program is a noticeable bottleneck in a process that also runs multi-GB FEM simulations.
1 comments
kanzure 4103 days ago
> Just getting it to rebuild and reexport an updated model requires at least a full minute of it popping up windows all over the place

Huh, are you sure Solidworks has to be running for that workflow? Can't you just load the DLL?

link
wtallis 4102 days ago
I'm not sure; I didn't write that component and I don't think it's been rewritten in probably a decade, just linked against newer versions of SolidWorks. It's ugly but it works, so we only start looking at the internals of SolidWorks when they introduce a new bug that affects us, which hasn't happened in several years.

I'm not optimistic, though. Even in normal interactive use, SolidWorks cannot manage to read updated values from a linked Excel spreadsheet upon opening a part (or writing while saving the part) without the embedded Excel window flashing up briefly. Getting SolidWorks and it's Excel child process to both stay in the background isn't really worth much effort to us at the moment, and I do occasionally get the benefit of spotting something breaking when the model flashes up on screen, instead of discovering it much later.

It's really something that shouldn't even require COM/OLE style stuff, just some basic command line functionality. But why would a Windows-only app support that method of interaction?

link