My standalone C# app checks out files from, rebuilds them, and checks them back in. Occasionally, Microsoft Excel opens on its own. I close it only for it to open again. How is Excel connected to the SolidWorks API? Is there a way to prevent Excel from opening?
Josh,
I do have the source code for the app. When Excel opens, it's seldom on the same file(s) each time. It's usually a precursor to SolidWorks not responding.
You mentioned that this may be caused by older file versions. Is there a way to see which version a file is on?
Thanks for your help.
Eric Drake wrote:
Josh,
I do have the source code for the app. When Excel opens, it's seldom on the same file(s) each time. It's usually a precursor to SolidWorks not responding.
You mentioned that this may be caused by older file versions. Is there a way to see which version a file is on?
Thanks for your help.
2018 SOLIDWORKS API Help - VersionHistory Method (ISldWorks) will tell you what releases the file as been saved in.
But I said Excel-based BOMs, not old files. Excel-based BOMs can still be created, they're just not as good to use (in most situations) as the regular SW native BOM.
Other than that or possibly design tables or some type of OLE object, I don't see any reason for Excel to be opening. Hard to say more without the code.
My apologies for the misunderstanding. The files in question are SLDPRT files and their corresponding SLDDRW files. Would a single part have a BOM? If so, how can I tell if it's Excel-based?
It could be design table.
You said "My standalone C# app..." Does that mean you wrote it, or you just have it? Do you have the source code to debug it? You need to figure out which SW files are causing Excel to open during a rebuild.
My first guess would be an Excel-based BOM (which have been legacy functionality since about 2004 and probably should not be used). Excel is used for a couple more things, but I think the BOM would need to hit up Excel during a rebuild.