[fftw_ayi]

Please tell me if I'm doing anything wrong/bad as far as handling the openning and closing of Excel.

The following code is work in progress, but for now, it simply gets a list of excel files in a certain directory, loops thru those files and does a save as to another directory. The code works, but when I open the Windows Task Manager and monitor the Processes tab, I notice the following which concerns me.

As the code runs, I see that EXCEL.EXE opens and closes, but when the code finishes sometimes there are several instances of EXCEL.EXE process still lingering around. And thy never finish until I manually kill them. So that makes me think I'm not doing something properly to completely close out everything.

I hope you can understand what I am doing below and what my concern is. Thank you.

Imports System
Imports Microsoft.Office.Interop

Module Module1

	Sub Main(ByVal Args() As String)

		Dim MthYr As String = Args(0)
		Dim SubDir As String = Args(1)

		Dim FileList As String() = System.IO.Directory.GetFiles("C:\InsightExposures\" & MthYr & "\OriginalFormat\" & SubDir, "*.xls")
		Dim FileName As String
		Dim objExcel As Excel.Application
		Dim objBook As Excel.Workbook
		'Dim objSheet As Excel.Worksheet

		Dim i As Integer

		For i = LBound(FileList) To UBound(FileList)

			FileName = Mid(FileList(i), FileList(i).LastIndexOf("\") + 2, Len(FileList(i)))
			'MsgBox(FileList(i) & vbNewLine & FileName)
			objExcel = New Excel.Application
			objBook = CType(objExcel.Workbooks.Open(Filename:=FileList(i), ReadOnly:=True), Excel.Workbook)
			objBook.SaveAs(Filename:="C:\InsightExposures\" & MthYr & "\ConvertedFormat\" & SubDir & "\" & FileName, FileFormat:=-4143)

			objExcel.Quit()

		Next i

	End Sub

End Module

[Dylan]

Heh, I noticed this exact same problem with a recent project I was working on. Calling Quit() should end the instance of EXCEL.exe. If you would like, you can always loop through the running processes and kill anything named 'EXCEL.exe'.

[VisualMelon]

I have this prob with some Applications, I usually kill the thread when I want it to close, seems to work, but I am not sure if this is potencially hazardous.

I assume this prevents Settings form saving, but I slways sve them immediatly anyway.

Not sure how this could be done in VBA, but I would be interested to know weather it can cause unwanted effets.

[EyEBaLL]

I always use this to kill excel / word. Generally i create a class called ProcessMgmt or something and then just call Processmgmt.KillExcel or KillWord from wherever.

Sub KillExcel()
		'---Kill excel
		Dim procs As Process() = Process.GetProcessesByName("EXCEL")
		Dim proc As Process
		For Each proc In procs
			If proc.Responding Then
				If proc.MainWindowTitle = "" Then
					proc.Kill()
				End If
			Else
				proc.Kill()
			End If
		Next proc
		'----kill excel
	End Sub

Hope this helps you

[programmer-in-training]

What if someone has an Excel window open on a separate project?

[EyEBaLL]

It wont affect running instances since they have a window title (even if it is just untitled or whatever).
What i found was that when i was launching excel and word from .net the process would carry on running even after i closed them and i ended up with hundreds of excel.exe processes running at once. This was the best way i found to search for those rogue processes and kill them.
It works very well and AFAIK there are no issues with it interfering with other windows and i have tested it a lot to be sure.

Thanks

[kowalsky]

EyEBaLL, on 25 April 2009 - 06:14 PM, said:

It wont affect running instances since they have a window title (even if it is just untitled or whatever).
What i found was that when i was launching excel and word from .net the process would carry on running even after i closed them and i ended up with hundreds of excel.exe processes running at once. This was the best way i found to search for those rogue processes and kill them.
It works very well and AFAIK there are no issues with it interfering with other windows and i have tested it a lot to be sure.

Thanks

please take a look here http://devcity.net/A.../1/article.aspx
In principle, you are supposed to build a list of Excel processes BEFORE you launch your own - so, before you create the Interop.Excel objects you take an inventory of Excel processes already running and you store their ids into some array; when you shut down the process that you were working with it is going to be that id that is NOT in the initial list.
However, from my personal experience, the fact that you need to kill the EXCEL process means that you already operate in a shady area (most of the time it is the case of some unmanaged environment, e.g.: you are trying to work with the Interop objects from some server that has EXCEL installed on it - Microsoft has a disclaimer that tells explicitely that this use of the Interop objects is not supported leading to unexpected behavior). Again, from my experience, when you work on a client with the Excel instance from that client with one user at a time, then the objApp.Quit() closes Excel gracefully with no problems, not sure about the next statement but I think I saw Excel cosing by itself even without the Quit() method called - must be the GC or something ... On the other hand, the method involving Excel process killing will lead to all kinds of nefarious problems, many of which I don't think they have solutions - the nasty one I experienced was the fact that after the kill, Excel can't be made to skip the recovery info creation. Therefore, your app is OK, Excel will close nicely (forced, but you will be very pleased seeing how it goes away from the Task Manager) only to open Excel on the server a while later and see the accumulated documents that wait for you to decide which version should be kept - in time Excel will not even open given the hundreds and hundreds of copies maintained in that list.
You could also try the OOXML, nevertheless that could turn into a nightmare very quickly pending on the complexity of your app,
HTH,
kowalsky