Thanks Stephen, your explanation is right on the money.

Here's how I'm solving this for now, which also addresses the issue of
regression caused by a user making configuration changes, after my
application has taken a snapshot of the configuration settings:

CloseWindow m_hWndExcel, SRSWinClose.Kill

Instead of closing Excel politely, I'm just killing the @#%# thing via
WinAPI. This prevents any of my changes from getting saved to the Registry.

Note to Microsoft: I think your Office products are terrific, and I'm
impressed by the way these products can be used programmatically as
automation servers as well as interactively as user applications. I suggest
that it would be a valuable feature to be able to isolate an automation
server so as not to impact the user's interactive environment. Perhaps a
property such as Application.Isolate = True would do the trick.

Thanks!

- Joe Geretz -

"Stephen Bullen" wrote in message
...
Hi Joseph,

Without resorting to the hack, the problem can be corrected with the
following code modification:

Set m_AppExcel = New Excel.Application
m_AppExcel.Caption = "MyExcelViewer"
m_AppExcel.IgnoreRemoteRequests = False

If I change the third statement to assign False, run my program, and then
exit my program, proper Excel shell functionality is restored. What's
going
on here?

The IgnoreRemoteRequests setting is retained by Excel after your
application
finishes - unless you set it back. In the Excel UI, it's on the Tools
Options General tab. The general approach to your issue is to take a
snapshot of the Excel settings you're likely to change, make the changes,
do
your stuff, then set them all back to how they were before you started. As
Excel updates the registry entries when it closes, the only issue that
remains
is if someone changes some settings in a different instance of Excel while
yours is running. The choices that get saved will depend on which one gets
closed last.

Regards

Stephen Bullen
Microsoft MVP - Excel
www.oaltd.co.uk