[AccessD] Preventing Extra Excel instances SOLVED

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



More information about the AccessD mailing list