solidworks-api
solidworks-api copied to clipboard
angelsix
Error when getting mass
I'm seeing many errors in the logging for my product about failing to get the model mass. SolidDna wraps these errors nicely, which also means I have no idea where they come from. The argument doNotThrowOnError is always true, so there something unexpected must be going wrong.
Is anyone else seeing these errors as well? I'm trying to find a model or open mode to reproduce it, but I haven't been able so far.
Remove reference to the NuGet package of SoliDNA and reference source project directly, turn on Ctrl + Alt + E checkbox for common runtime exceptions, run your add-in and debug it, it will break into code on an error throwing so you can see
Will do. The main issue is that I never get these mass errors myself. I now log the open mode (quick view, resolved etc) and I just released a new version, so maybe that will give me a hint when the error occurs.
I found out the reason for this error. When opening a drawing for an assembly, the assembly fires a Rebuilt event. Since Model wasn't updated, we hadn't received a ModelInfoChanged event but SolidWorks was already opening the drawing, this caused an error.
I don't think it's a SolidDna problem, I needed to unhook my events sooner. So I'll close this one.
I still see 200 mass errors in my product log for the past week, so it's still not fixed completely. It only seems to happen for parts and only when the part rebuilds. I have still not been able to reproduce it. Logging the calling member name and line number of the SolidDnaException has not proven to be useful because we always use the helper method SolidDnaErrors.CreateError to create a new exception.
There is a null reference exception, that much I know. I think SolidWorks may return null for the mass properties, without setting an error code. I will try this in my product and open a PR if it works.
More logging in my product showed that SwModel.Extension.GetMassProperties2 does indeed return null, but it also returns a status code of -1. That's not a valid status code according to the docs and we set it to -1 before calling the method. That means they forget to set it.
I'll create a PR to work around this and I have reported the bug to SolidWorks.