Resolved: Suppressing Multiple spawned processes

[Spiff59]

I've been searching the forums, and experimenting with different approaches, but am still having trouble with what I'm sure has been discussed before.

Basically, I have an AutoIt program that receives a "Patient ID" parameter when executed and does something like this pseudo-code:

Main {
<Read DB2 tables....>
<Process Various things...>
<Update_Spreadsheet(); when a button is pressed >
Exit
}

Func Update_Spreadsheet()
    $oExcel = Objget("","Excel.Application) 
    <automatically update some cells in the invisible spreadsheet>
    $oExcel.Quit
EndFunc

My problem is that after a while some users are ending up with multiple (like 10+ by the end of the day) "excel.exe" processes running.

I've noticed when my script is ran, no "excel.exe" exists until the first time the "Update_Spreadsheet" paragraph is called.

Then, even though the "$oExcel.Quit" has taken place, the excel.exe process remains. If the user selects to run the Update_Spreadsheet routine again, THEN a second excel.exe is spawned, but a moment later the prior excel process quits, and I'm back to one running excel.exe. If the user manually exits the AutoIt program, then that lingering excel process closes. All is well, so far.

The problem comes when the user launches the AutoIt program a second time. I want only one instance of my program running at a time. I was trying:

If _Singleton (@ScriptName, 1) = 0 Then
    ProcessClose(@ScriptName)
EndIf

That kills the older instance of my program, allowing the newly-launched script to process the newly-passed parameter, but the ProcessClose leaves that one persistent excel.exe out there, starts a new one, and the processes start to pile up.

Letting "_Singleton" automatically kill the new process loses the new command-line parameter that I need.

What is the best route to go about this?

Can I force the excel.exe process to terminate right after the $oExcel.Quit?

Is there a friendlier way than "ProcessClose" to kill off the prior script?

Can I modify the _Singleton test to close the prior script AND kill the excel.exe it spawned?

Any advice?

(I'm remiss to try something as brute-force and kludgy as to store the prior excel.exe's PID in an .ini file and have the second scripts _Singleton test kill it).

I do have to be concerned about not zapping any excel processes the user may be running that are unrelated to my script.

A million thanks to all.

Edited August 6, 2008 by Spiff59

[Spiff59]

It's always the last thing you try...

Just swapping in WinClose (and pointing it at my script, not excel) in place of ProcessClose seems to have done the trick.

It apparently does a kinder-and-gentler shutdown.

It did throw part of my exit routine off, the part that stores the current window coordinates in a user-specific .ini, so that the program would start in the same screen position the next time it was executed. My guess is that ProcessClose just blows an application out of the water, so no exit routines are run. With WinClose, WinGetPos was reading the active window, which was the calling program, not the script. Specifying a window title in the WinGetPos call corrected that.

Edited August 6, 2008 by Spiff59

[Confuzzled]

It's always the last thing you try...

Just swapping in WinClose (and pointing it at my script, not excel) in place of ProcessClose seems to have done the trick.

It apparently does a kinder-and-gentler shutdown.

It did throw part of my exit routine off, the part that stores the current window coordinates in a user-specific .ini, so that the program would start in the same screen position the next time it was executed. My guess is that ProcessClose just blows an application out of the water, so no exit routines are run. With WinClose, WinGetPos was reading the active window, which was the calling program, not the script. Specifying a window title in the WinGetPos call corrected that.

Maybe Excel is prompting for a save before close and you are not allowing that to happen, hence it isn't shutting down gracefully. Allow a slight pause in your script for the Excel shutdown process to complete may be in order as well.