Mike_R

Hmmm... the link that you are quoting seems to be here: Creating, Saving, Opening, and Closing Workbook Objects. I have never seen such behaviour exhibited and kicking it around now, I cannot reproduce this... And yet you are having this very problem! The do provide the solution, however: What they are saying is that you should use code similar to the following when you save your workbook:MyWB.Windows(1).Visible = True MyWB.Save Or use .SaveAs or whatever you want, but make sure that your Workbook is not hidden when it is saved. As for making the Excel.Application itself Visible, this is not necessary. :)

Ok, I'll answer my own post, I guess... I gave this a lot of thought (and did a good deal of testing) and although Marshal.ReleaseCOMObject(oExcelObject) oExcelObject = Nothing is good, I actually have found it better to use oExcelObject = Nothing GC.Collect()There are caveates abound when it comes to realeasing COM Objects, but I wrote up my findings as best I could in a tutorial that can be found here, if anyone is interested... (You can skip to the "Cleanup" section.)

Hi guys, in MSKB 317109, MSFT shows a way of releasing a COM Object using the following code: Sub NAR(ByVal o As Object) ' This sub cleanly releases the COM Automation Object. ' Source: [url]http://support.microsoft.com/?kbid=317109[/url] Try System.Runtime.InteropServices.Marshal.ReleaseComObject(o) Catch Finally o = Nothing End Try End SubThe interesting thing is that since 'o' is declared ByVal, the Finally line, setting o = Nothing, really does not do anything. Chaning 'o' to be ByRef would seem to be the correct way to go, however under Option Strict this implicit coercion is not permitted. The solutions to this seem onerous: (1) Use Overloading for every possible Excel Object type imaginable. (2) Use 'Option Strict Off' (3) Kill the o = Nothing line within the NAR() routine and simply call NAR(oExcelObject) oExcelObject = Nothing I suppose that #3 is best, but the whole point of the NAR() routine is to encapsulate the process of Releasing a Com Object in one call... Any ideas on how this might be handled better? Thanks in advance :), Mike

Does anyone know what is the .Net command to test for the Automation Server being "Busy"? In short, I'm looking for what in VB 6.0 would be VB.App.OleServerBusyRaiseError and VB.App.OleServerBusyTimeOut. It's used in Automation to force a run-time error if the User currently has a DialogBox (or the like) open that prevents one's code from running. Using OleServerBusyRaiseError, one's Automation code can know that the Server is occupied and choose to do something else instead of just "hang" waiting... Any thoughts on how to do this in .Net? Thanks in advance! :) , Mike

It is my understanding that C# and VB have been made essentially 98% compatible, maybe 100% compatible with each other... But one issue sticks out with me... If a Boolean value or expression returning 'True' coerces to -1 in VB and +1 in C#, how does this work?? I've tested VB.Net and confirmed that MessageBox.Show(CLng(True).ToString) returns -1, as it did in VB 6.0... But I don't have VS.Net, so I can't test it in C... Can someone let me know how C#.Net handles this? And how any discrepancy is rectified?? Thanks in advance :), Mike

So is Dispose() called by Finalize()? If I put my cleanup code in Dispose(), when is it called? (Or do I have to call it explicitly by whatever container is controlling/holding the object? -- Mike

And is CType() that which replaces CStr(), or is there something else I should be aware of? Thanks in advance... -- Mike

Oh genius, MORE letters not less. Ugh. Wouldn't Msg() Have made more sense? Oh well... whatcha gunna do?? Thank you very much for the Info though. :), Mike

Yes you seem to be right, I've been doing some reading since I posted this... VB6-stlye MyObj = Nothing is no longer required really and doesn't even do much, although it can speed up the process of deallocating resources somewhat. Really not needed. From what I've been reading, Finalize() actually seems to be the proceedure to use, generally, but if you wish to expose a Method that 'cleans up' datastructures that the Object is referencing before deallocation (or at any point) then .Dispose is the way to go. This call results in immediate cleanup, but the Object in question is still present... Anyway, thank you for your help, and to everyone in this Forum... :), Mike

I'm a complete .Net newbie here, so I apolgize for this question... But what are the newer .Net equivalents for MsgBox() and Cstr()? I guess for Cstr() the new version is CType(), or is there something else as well? And what is the new version of MsgBox()? Thanks in advance! -- Mike

I'm a bit unclear on the distinction between the Finalize() Sub and the Dispose() Sub in a Form. What is the difference between the two? Should I be setting my Class-Level references = Nothing and other cleanup in Finalize() or within Dispose()? Thanks in advance! -- Mike

Ok, thanks... still seems odd to me. If the xlBook is declared As Excel.Workbook and Workbooks.Add() can only create one type of Object (an Excel.Workbook), I don't see the need for CType(), but then I see it thrown around everywhere by everyone, so I guess it is necessary... Thanks :), Mike

Ok, thanks... still seems odd to me. If the xlBook is declared As Excel.Workbook and Workbooks.Add() can only create one type of Object (an Excel.Workbook), I don't see the need for CType(), but then I see it thrown around everywhere by everyone, so I guess it is necessary... Thanks :), Mike

Wow, that looks like some good code... a mini-tutorial, really :) But I wonder, is the explicit use of CType() everywhere really necessary, such as here: xlBook = CType(xlApp.Workbooks.Add, Excel.Workbook) I'm completely new to VB.Net, so I really am asking... Is this actually needed here, or were you just being 100% safe? -- Mike

I'm brand new to VB.Net... just two nebie questions regarding the Base that various objects are in .Net: (1) Arrays are always Base 0 in VB.Net and 'Option Base 1' type stuff is now gone, right? (2) Are Collections still Base 1? Or has that become Base 0? Thanks in advance... -- Mike

The xlApp.Quit routine calls xlApp.Workbooks.Close behind the scenes. If any are unsaved, then you get the alert displayed. But, yes, it can be turned off. In the following, I'll assume that your Excel.Application reference is called 'xlApp' and that your Excel.Workbook reference is called 'xlWB'. You kind of have four choices here. Either: (1) The easiest is simply to turn DisplayAlerts off: xlApp.DisplayAlerts = False xlApp.Quit xlApp = Nothing (2) Close your Workbook without saving changes: xlWB.Close(False) ' SaveChanges:= False xlApp.Quit xlApp = Nothing (3) "Trick" XL into thinking that your WB is already saved, without saving it at all! xlWB.Saved = True xlApp.Quit ' No alert will happen here, XL thinks xlWB is saved. xlApp = Nothing (4) Save your workbook... which you said you didn't want, but for completeness: xlWB.SaveAs("C:\My Documents\Book1.xls") xlApp.Quit xlApp = Nothing Hope this helps... :), Mike