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.
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?
