Excel COM Sample Program Query

[dannycat]

I am currently usingCOM objects to interact with Excel from a FORTRAN program. Everything works fine except that the EXCEL.EXE process remains in the Windows Task Manager Process list after the program has completed.

I tried running the sample AutoDice program and the same thing happens here.

Previously when using COM objects with Word the WINWORD.EXE does terminate (and disappears from the Task Manager Process list) when the equivalent ofReleaseObjects (See AutoDice) is called.

Cananyone out there help resolve this one?

[Paul_Curtis]

Here is the code I use to close Excel following a shell-out from Fortran:

[cpp]!   release all objects which may have been created
IF (worksheet  /= 0) status = COMRELEASEOBJECT (worksheet)
IF (workbook   /= 0) status = COMRELEASEOBJECT (workbook )
IF (workbooks  /= 0) status = COMRELEASEOBJECT (workbooks)
IF (excelapp   /= 0) status = COMRELEASEOBJECT (excelapp )

CALL COMUNINITIALIZE()
[/cpp]

[dannycat]

Quoting - Paul Curtis

Here is the code I use to close Excel following a shell-out from Fortran:

[cpp]!   release all objects which may have been created
IF (worksheet  /= 0) status = COMRELEASEOBJECT (worksheet)
IF (workbook   /= 0) status = COMRELEASEOBJECT (workbook )
IF (workbooks  /= 0) status = COMRELEASEOBJECT (workbooks)
IF (excelapp   /= 0) status = COMRELEASEOBJECT (excelapp )

CALL COMUNINITIALIZE()
[/cpp]

Hi Paul,

Thanks for the information. However I alreadyuse the same code as you describe. This is the same as in the AutoDice sample program that comes with IVF FORTRAN. When I compile and run the example there is always and EXCEL.EXE running after the program finishes and the excel file remains "open", ie can't be opened without creating a copy.

I also tried adding the calls:
call $Workbook_Close(WorkBook,$STATUS=status)
call Workbooks_Close(Workbooks,$STATUS=status)
call$Application_Quit(ExcelApp,$STATUS=status)

before the ReleaseObject calls but this does not help.

At what point should EXCEL.EXEterminate and disappear off the Process list, ComUnInitialize or ComReleaseObject(Excelapp)?

If I openan excel file after my program has finishedan then close the excel application the EXCEL.EXE does go away which indicates that The new excelrun picks up the existing process which is finally destroyed when I exit.

Does your application tidy up properly or does it leave lots of EXCEL processes lying around. Thismay occur without you noticing as it does not affect the overall functionality of the program.

[Paul_Curtis]

Well, we may be talking about slightly different scenarios. My Fortran code spawns a child Excel window and populates the spreadsheet with data from the Fortran program. This Excel instance is subsequently closed by the user, whereupon the above-posted cleanup code is executed within the Fortran program, mostly to prevent memory leaks. I have never had a problem with residual Excel content, either on the screen or as a running process, but if you are seeking to close out one running process (Excel) from within a separate process (your Fortran program), that could be a different issue entirely.

[anthonyrichards]

Quoting - Paul Curtis

Well, we may be talking about slightly different scenarios. My Fortran code spawns a child Excel window and populates the spreadsheet with data from the Fortran program. This Excel instance is subsequently closed by the user, whereupon the above-posted cleanup code is executed within the Fortran program, mostly to prevent memory leaks. I have never had a problem with residual Excel content, either on the screen or as a running process, but if you are seeking to close out one running process (Excel) from within a separate process (your Fortran program), that could be a different issue entirely.

You could try using the Windows API functions CoInitialize and CoUninitialize instead of ComInitialize and its compliment and see if they produce the correct termination of the COM object. Note that every call to CoInitialize must be balanced by a corresponding call to CoUninitialize. Perhaps somewhere in your code you call ComInitialize more than once?

[dannycat]

Quoting - anthonyrichards

You could try using the Windows API functions CoInitialize and CoUninitialize instead of ComInitialize and its compliment and see if they produce the correct termination of the COM object. Note that every call to CoInitialize must be balanced by a corresponding call to CoUninitialize. Perhaps somewhere in your code you call ComInitialize more than once?

Are the CoInitialze/CoUnInitialise API interfaces defined in modules for FORTRAN?

I use ComInitialze and its complement to spawn a Word process, create and populate a document and then exit and shut down WINWORD.EXE successfully.

[anthonyrichards]

Quoting - dannycat

Are the CoInitialze/CoUnInitialise API interfaces defined in modules for FORTRAN?

I use ComInitialze and its complement to spawn a Word process, create and populate a document and then exit and shut down WINWORD.EXE successfully.

I can't find CoInitialize or its compliment either! But apparently OleInitialize and OleUninitialize do the same thing so try them instead.Note the first is a Function (which must have a singleNULL argument)that returns a value (which you should check), the other is a subroutine with no argumentthat must be Called. The following interfaces were taken from theIFLOGM module. Try

interface
integer function OleInitialize( reserved )
!DEC$ ATTRIBUTES DEFAULT, STDCALL, DECORATE, ALIAS : "OleInitialize" :: OleInitialize
integer, intent(in) :: reserved
!DEC$ ATTRIBUTES VALUE :: reserved
end function OleInitialize
end interface

interface
subroutine OleUninitialize( )
!DEC$ ATTRIBUTES DEFAULT, STDCALL, DECORATE, ALIAS : "OleUninitialize" :: OleUninitialize
end subroutine OleUninitialize
end interface