Excel left open

[crabgrass]

Not sure if this is the best forum for this question. Let me know if I should post it somewhere else.

I have a DLL called from ASP that creates an Excel file. After file creation the ASP page redirects to the excel file which opens a dialog giving the user the option of saving the file to disk or opening the file. If he opts to open the file, it will open in the browser whereupon he can view/edit etc. If he then clicks the browser back button to return to the asp page, it will do so as expected. However, I have found that Excel is left running in the background in an invisible state. Whihc of course clutters things up.

So, what is the proper way to handle this situation so excel will not be left hanging?
Thanks

 

[Sheco]

Did you try putting your DLL into a COM+ package by going to:
Control Panel -> Administrative Tools -> Component Services

 

[crabgrass]

Ah . . . no. The DLL is a single threaded COM written in Foxpro. It creates the file and then exits so I think its out of the picture. However I poke around there at your suggestion and it wasn't clear how to create a new app with the dll. The VFP compile routine registers the dll and I've never had to include this step before. (Although I've never had this problem before.

 

[Sheco]

I assume that the DLL is calling the app.close method of the excel app.

Anyway, my idea is that if the DLL is loaded and unloaded by a COM+ application instead of IIS/ASP then perhaps it won't get left hanging on a page transition. It might be a long shot but it should be pretty easy to set up and see what happens.

Another way to detach the Excel file creation from ASP might be to insert a row into a database table and then have a little process running on the server the polls for new rows, makes the Excel file, then updates the row... or without a database just write a text file and have a service the polls for a new file, creates the excel, and then moves the text file to the \done folder.

 

[crabgrass]

Ah . . . I see where you are coming from. The dll is not automating Excel and Excel is not involved in the file creation. Creating the Excel file is a native foxpro function:
COPY TO newfile TYPE XLS

So there is no hook to Excel at this point. Excel doesn't become involved until after we exit the DLL and redirect the ASP page to the excel file. So it is the browser that is opening Excel and not closing it when we exit the page.

 

[Sheco]

Oh I totally thought you were talking about a server-side problem with ASP because you can manipulate Excel from inside ASP using COM objects but it has a nasty habit of leaving an orphan Excel process running on the server.

So this is happening on the client when you open an excel file in the browser?

 

[crabgrass]

Well at this point in time the server and client are in the same box so I can't really tell for sure. But I presume you are correct and it is left running on the client.

 

[Sheco]

Well you should use another compuer as a client and double check because having Excel running in the task list on the server is a known problem with using the office automation objects in ASP. Do you know for certain that the DLL does not create an instance of an excel thread?

Perhaps a way to half-test this without a second computer would be to make a VBS file that creates and calls the DLL in the same way that your ASP does and then watch the task list to see if Excel pops up.

 

[noodles1]

I too have experienced orphaned Excel and Word processes when using office automation objects in ASP. Could not find anything wrong with the use of the office objects in the ASP code.

I had to resort to developing a background housekeeping process that would run as a Scheduled Task on the web server. This process would clean up the orphaned processes based on their name and process creation time (e.g created some reasonable period of time ago).