Ken Ismert
KIsmert at texassystems.com
Thu Oct 27 11:40:01 CDT 2005
>>Even though the program will run correctly without >>them being qualified, they are not cleaned up properly >>when used this way. Exactly what is happening >>internally wiser heads than I may want to comment. Jim: Well, I'm not claiming to be a wiser head (usually the other end of me is called wise), but what I think might be going on is this: 1) You create an instance of Excel via automation, and call it appXcel. 2) When you implicitly reference the Excel application (use ActiveCell unqualified), VBA actually creates another object reference to the Excel application under the hood (in other words, a clone of appXcel). VBA compiles an unqualified ActiveCell reference into [_Xcel].ActiveCell, where [_Xcel] is a hidden object variable retrieved using GetObject(), which hopefully finds your EXCEL.EXE automation instance, also pointed to by appXcel. What happens if you have other instances of Excel open is anyone's guess. 3) When you try to shut down your instance, this extra reference prevents it from terminating, because the rules of object scope in COM state that an object lives as long as there is at least one reference is pointing to it. So, this might be a "by-design" feature of VBA, where it is trying to be too clever in interpreting your code, and inadvertantly causing problems later. But your advice is sound: Always qualify all calls to an automation application using the application reference you have created. In this example, always use appXcel.ActiveCell, or With appXcel, when working with that application's object model. Good work. -Ken