Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 Other Forums
 Other Topics
 Excel VBA - Application.Quit does not kill process

Author  Topic 

timmy
Master Smack Fu Yak Hacker

1242 Posts

Posted - 2006-08-03 : 20:30:39
Hi all,

I have a frustrating problem in one of my apps. I'm interacting with Excel from one of my .NET (framework 2) apps. The problem is that I can't seem to kill the Excel process after I've finished. There is a method (Application.Quit) that is meant to do it. It certainly kills the window, but the process is still visible in Task Manager.
Has anyone else encountered this?

TIA,

Tim

MichaelP
Jedi Yak

2489 Posts

Posted - 2006-08-03 : 20:56:11
Can you post the code you use to "call" Excel? Maybe we can work backwards from that.

Michael

<Yoda>Use the Search page you must. Find the answer you will. Cursors, path to the Dark Side they are. Avoid them, you must. Use Order By NewID() to get a random record you will.</Yoda>

Opinions expressed in this post are not necessarily those of TeleVox Software, inc. All information is provided "AS IS" with no warranties and confers no rights.
Go to Top of Page

timmy
Master Smack Fu Yak Hacker

1242 Posts

Posted - 2006-08-03 : 21:39:25
Michael,

Here is the code:


object missing = Type.Missing;
Microsoft.Office.Interop.Excel.Application xlApp = new Microsoft.Office.Interop.Excel.Application();
Workbook xlWbk = null;
try
{
xlWbk = xlApp.Workbooks.Open(schemaPath, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing);
xlApp.Run("CreateScripts", true, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing);
object ret = (object)"";
ret = xlApp.Run("GetLog", missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing);
xlApp.DisplayAlerts = false;
xlWbk.Close(false, missing, missing);
}
catch (System.Exception ex)
{
MessageBox.Show("An error occurred updating the config file:" + ex.Message);
return false;
}
finally
{
xlApp.Quit();
xlWbk = null;
xlApp = null;
}


What the code is basically doing is:
- opening a spreadsheet.
- executing one of the VBA macros stored within
- calling another VBA function to return the log information created from the previous call
- closing/exiting.

Cheers,

Tim
Go to Top of Page

SwePeso
Patron Saint of Lost Yaks

30421 Posts

Posted - 2006-08-17 : 07:16:07
xlApp.ActiveWorkbook.Close False
xlApp.Quit

Must have both (Close and Quit)!


Peter Larsson
Helsingborg, Sweden
Go to Top of Page

SwePeso
Patron Saint of Lost Yaks

30421 Posts

Posted - 2006-08-17 : 07:16:52
And don't forget to do SET xlApp = Nothing, to relase handle from VB application.

Peter Larsson
Helsingborg, Sweden
Go to Top of Page

timmy
Master Smack Fu Yak Hacker

1242 Posts

Posted - 2006-08-21 : 20:57:50
Peter,
Those commands you suggested are already in the code. The 'set xlApp = Nothing' is taken care of by xlApp = null because it's C# not VB.
Even with these commands added it still does not kill the application every time.

Tim
Go to Top of Page

SwePeso
Patron Saint of Lost Yaks

30421 Posts

Posted - 2006-08-22 : 01:06:13
But it closes sometimes?

What does CreateScripts and GetLog do? Do they start a new Excel instance?

Peter Larsson
Helsingborg, Sweden
Go to Top of Page

timmy
Master Smack Fu Yak Hacker

1242 Posts

Posted - 2006-08-22 : 02:08:40
quote:
Originally posted by Peso

But it closes sometimes?



That's right. I have a feeling it may be a bug with the interop libraries.

The CreateScripts and GetLog do not create new instances. All they do is act on the currently open workbook by referencing the Application.ActiveWorkbook object.

I'm not losing any sleep over it. It seemed to only be a problem on my local machine - the app is running on our integration server and I can't see any stray Excel.exe processes left behind.

Cheers,

Tim
Go to Top of Page
   

- Advertisement -