Re: Cannot Close Excel Automation Process

tomhoo wrote:
Jim, thanks so much for your comments.

I now understand how the TRY FINALLY works, and am going to start
using that because I was attempting to code that functionality myself
which is now unnecessary. (NOTE: While I put the close statements in
the FINALLY, I still have them in the code where they would normally
get executed. The FINALLY is for when something blows and I need to
cleanup, right?

No, any exit from the try finally block will cause the finally code to run. even normal program progression from the try finally block.

the finally code is always run. I mean always run.

you can not code it so that it does not run. What is between finally and end will run.

That is some of the magic of the try finally block. No need to be sure that the finally code is run.

also code the close at only one place. So better coding practice.

I like it because I can no modify the code and not have to be sure that objects are free'd Put other checks in with time, no need to for a call to a common close routine or making sure that if I need to make a change to the close routine that have made the changes everywhere. - - -

So simpler and faster code, and easier code development.

took me a while after knowing about it to give it a try. Figured just more typing and work. - - - Now I do it automatically when every I have a procedure that creates an object - - - setup the try finally and put the code for freeing right then and there.

I believe the code is being executed - especially since I step through
it in the Debugger. (Since the Debugger is a special environment, I
have a small test case and also a sister program which successfully
closes the rogue EXCEL.EXE Process so I think I have that base


Originally, I set up XL to open and close as needed but when making
certain runs, the majority of my execution time (hours) would be taken
up by XL opening. For the life of me, I simply cannot figure out how
to stop it from doing that Virus check. I've turn off all virus
checker Office stuff and still XL just sits there like a blob while
doing the virus check.

My workaround is that I do a SaveAS after each bit of data logging.
This has worked quite well.

I was actually thinking of opening XL at the beginning of the program
and leave it open to the very end. I think I could do this without
incident because the big automation keeps 6 XL files open during the
program. If I worked with an intermittent 7th file, there really
shouldn't be any real difference.


However, I don't like the idea of an XL session that might be 5 days
long - I don't know for sure, but I would guess that XL has memory
leaks like most other MS programs, although I could be completely
I know the feeling. but as long as it is saved - - - - -


My latest investigation is watching just what system and assembly code
is executed when I close XL in the good, sister program, and this bad
one. There is definitely a different path taken for the same closing
statements, but it is so complicated, that I have to figure out a way
to log it. (I'm thinking of cutting and pasting the code shown in the
debugger into a text file and then annotating it for each of the
programs. Obviously, some variable will have a different value and
force a different logic path. Even with that, the mystery may still

have you tried the internal debug system - - I can never remember the call - - something like Debugmessage. This is sent to a scrolling window that can be 1000 lines or longer. Great for capturing what is happening and Review. Almost like logging to a file. (and I believe it can be saved to file.)

Also looking into the Unit tree structure and the ordering of EXCEL97,
COMOBJ, OLESERV in the USES section.

Thank you so very much for your suggestions

you are welcome.