Application Quit does not work at all

[Landon]

Hi I use MFC Visual C++ 4.2.

I am automating Excel from my application.

My problem is I cannot quit the Excel after the automation process finished!

I checked it still exists on the Process lists and the most DANGEROUS is
everytime the automation function run, it create other Excel and so on. So it
must be out of memory soon.

I have used the app.Quit() method like all the people used but it DOES NOT
work.

What should I do?

Thank you.

 

[Peter T]

Maybe you have not released other Excel objects (workbook, sheet etc) that
you may have set earlier, or thought you had but not in the right order
which should normally be done in reverse order as to how you set them.

Regards,
Peter T

 

[Peter T]

You might also need to destroy your "app" reference after doing app.Quit
unless it is due to fall out of scope naturally.

Peter T

 

[Landon]

I have release the range and sheet like this:
　　　　　　　　// Release dispatch pointers.
range.ReleaseDispatch();
sheet.ReleaseDispatch();

book.Close( covTrue, covOptional, covOptional );
app.Quit();

1. Is this not enough? What should I add?
2. "You might also need to destroy your "app" reference after doing app.Quit "
How to do this? I think I haven't done the destroy step because I don't
know how and everybody just use the Quit().

Thank you.

 

[Peter T]

I'm guessing about the syntax but based on how you released your other
objects maybe something like this -

book.Close( covTrue, covOptional, covOptional );
book.ReleaseDispatch();
app.Quit();
app.ReleaseDispatch();

BTW, is it OK to use a name like "app" in C++ to refer to the Excel object.
In say VB6 it would cause confusion as "app" is a keyword that refers
directly to the host dll or exe.

Regards,
Peter T

 

[Landon]

Pete, I have tried the steps you gave me but it did not changed anything.

It's ok in MFC to use app.

How to destroy the app reference according to your previous post? I think it
will solve my problem.

Thank you.

 

[Peter T]

Maybe I got the syntax wrong or are you completely sure there are no other
references hanging on to the Excel instance.

Apart from releasing "app", if anything I would be more suspicious about
that "book" reference.

Why not ask in an MFC group about how to destroy all the ref's. If you get a
solution post it back here for the archives.

Regards,
Peter T

 

[Landon]

Yes, I am sure. What else? Book, books, sheets, sheet?

What inside my mind: this is like you open 2 or 3 documents on Excel then
you close it one by one and the last one is the Excel application itself.

I think I have all the documents closed, and the application failed to be
closed.

I have asked, but I haven't got the answer yet.

Any other idea?

Thanks.

 

[Peter T]

A potential problem is holding on to a reference to any workbook after it
has been closed, and similarly any sheet reference (which should be
destroyed before the book reference).

Another thought, before quit make the app visible. Maybe some user dialog is
being displayed which would certainly prevent the app from closing.

Regards,
Peter T

 

[Joel]

I discovered something earlier today when opening an application. OI used
this macro from Access

sub OpenExcel

set obj = getobject("c:\TEMP\BOOK1.XLS")
obj.application.visible = true
obj.close
end sub

Using this code left excel opened on the screen with the workbook closed.

I then made one small modification

sub OpenExcel

set obj = getobject("c:\TEMP\BOOK1.XLS")
obj.application.visible = true
obj.application.visible = false
obj.close
end sub

This close excel. To verify that excel really did close I check the Task
Manager and excel was left open in the first case and excel stopped in the
2nd case.

 

[Peter T]

That would be as expected but I don't follow how those examples apply to
your other code. In the case where you did effectively did app.visible =
false indeed the instance would close in that scenario. But instead you
could have done



That's not quite equivalent to what the OP is doing but all is working as
would be anticipated. In your demos when automating a new Excel instance
from Access (or Word) the instance either quits or remains open depending on
whether the app was visible or not when all references to it are released.
However this behaviour can vary depending on the app that is controlling the
automation.

Regards,
Peter T

 

[Hardik Soni]

Hi I use MFC Visual C++ 4.2.

I am automating Excel from my application.

My problem is I cannot quit the Excel after the automation process
finished!

I checked it still exists on the Process lists and the most DANGEROUS is
everytime the automation function run, it create other Excel and so on.
So it
must be out of memory soon.

I have used the app.Quit() method like all the people used but it DOES
NOT
work.

What should I do?

Even I try to use the kill process but still no benifit

 

[Peter T]

Ensure you release all references in the order created before, eg to
worksheet, workbook etc, then the release application reference after doing
..Quit

Another reason the instance may remain open is if any user dialogs are open
pending a response, eg "do you want to save...". Until you have sorted
things out make the instance visible before closing it. If you can't then
close it manually that'll confirm you still have a reference attached.

Regards,
Peter T