MikeDraper

COM Interoperability and Windows Forms I've found that the Excel application object is bound to the main application thread when used in a windows form. This is not the case in a command prompt thread. You'll notice that the close & quit code *works* in a command prompt application, but in a windows form, it sticks around until the window closes. //This code, flat out.. does not work. It doesn't quit the Excel object in a windows form. writeExcel(); workbook.Close(true, Environment.CurrentDirectory + "exc" + DateTime.Now.Ticks.ToString() + ".xls", false); exc.Quit(); Marshal.ReleaseComObject(exc); //This is supposed to trash the object. It Lies! /* I've tried with and without this. GC.WaitForPendingFinalizers(); */ GC.Collect(); // This *should* force the GC to clean up.. thus not requiring the 10 minute wait. Since this fires, exc must not be getting trashed. So I stuffed writeExcel() into its own thread.. If I call txlThread.Abort() on the thread, it works.. but jesus isn't that kind of messy? :\ Also, this would necessitate me setting up an event for when writeExcel() is through.. Otherwise you can kill the thread before its done it's job. There Has to be a more graceful way to do this. Also .. Did anyone notice that when you define the excel Application object, you get an Ambiguous reference? I have to use Excel.ApplicationClass Excel.WorkbookClass etc... I'm wondering if there is a scope issue here at work behind the scenes that isn't getting handled well.