Difference between Quit in Word and Excel

[mjwills]

All,

As background to my issue, I have noticed that .Quit in MS Word (97 /
XP) and .Quit in Excel (97 / XP) seem to have quite different
behaviours. In particular, .Quit results in the Word process unloading
from memory, while .Quit in Excel allows Excel to be unloaded from
memory only if there are no references to objects within the Excel
process.

My question is to identify whether *MS has stated that the behaviour I
am seeing (see below) is documented and reliable* (ie will always
happen).

As an example, see the below VB 6 code:

For Word:
Option Explicit

Private app As Word.Application

Private Sub cmdRunWord_Click()

Dim doc As Word.Document

Set app = New Word.Application

Set doc = app.Documents.Add

doc.Application.Visible = True

app.Quit

End Sub

For Excel:

Option Explicit

Private app As Excel.Application

Private Sub cmdExcel_Click()

Dim wks As Excel.Workbook

Set app = New Excel.Application

Set wks = app.Workbooks.Add

wks.Application.Visible = True

app.Quit

End Sub

Private Sub cmdSetToNothing_Click()

Set app = Nothing

End Sub

Note that if you open your Task Manager (to see what processes are
running), you can see when you run the Word code that WINWORD.EXE is no
longer in memory, even though app has not been set to Nothing. But if
you run the Excel code, EXCEL.EXE does not unload from memory until all
objects are Nothing (ie until you click cmdSetToNothing).

The difference in behaviour is significant (I won't go into the
details, but they are related to VB.NET / COM Interop) so I am looking
for an *official MS statement* (a blog entry from a MS staffer would be
fine) that the difference in behaviour between Word and Excel is by
design and particularly that app.Quit can be relied upon to close the
WINWORD.EXE process reliably.

Is anyone aware of such information? Note again that I am not looking
for anecdotal or practical evidence (I have that already) - instead I
am hoping for documentation from MS in some form.

Thanks
Matthew

 

[Howard Kaikow]

Read the Help for Quit in the Object Browser in Word and Excel.

In effect, the behavior of Word and Excel are the same.
At least it is in Office 2003.

Don't feel like booting to Office 97 now to check there.

 

[Karl E. Peterson]

Hi Matthew --

The difference in behaviour is significant (I won't go into the
details, but they are related to VB.NET / COM Interop) so I am looking
for an *official MS statement* (a blog entry from a MS staffer would
be fine) that the difference in behaviour between Word and Excel is by
design and particularly that app.Quit can be relied upon to close the
WINWORD.EXE process reliably.

Is anyone aware of such information? Note again that I am not looking
for anecdotal or practical evidence (I have that already) - instead I
am hoping for documentation from MS in some form.

I don't have an answer for you, but maybe I can help you with your expectations.
Microsoft doesn't support Office 97 anymore. The current trend is to *remove*
documentation on unsupported products, rather than to produce it (on blogs, or
otherwise), I'm afraid. They are apparently under the mistaken assumption that
knowledge becomes obsolete over time. Anyway, here's the Office product lifetime
info:

http://support.microsoft.com/gp/lifeofficefam

(I hope you'll consider signing the petition asking them to continue support of
long-term customers - see link below my sig.)

Sorry... Karl

 

[mjwills]

Karl,

Thanks for your response. The issue is not specific to Office 97, as
stated in my original post. It affects both Office 97 and XP.

Even if I can't find the answer I am needing (read entire original post
for more details) for Office 97, if anyone has it for Office XP that
would be great.

Thanks
Matthew

 

[Karl E. Peterson]

Thanks for your response. The issue is not specific to Office 97, as
stated in my original post. It affects both Office 97 and XP.

Ah, I took that to mean "Office 97 *on* [Windows] XP." Sorry for glazing over that.

Even if I can't find the answer I am needing (read entire original
post for more details) for Office 97, if anyone has it for Office XP
that would be great.

Well, I run Office 2000 (on Windows 2000! <g>), so I guess that leaves me out. But,
if you'd like to email me the DOC/XLS files, I'll let you know what they do here.

 

[Matthew]

Karl,

There are no doc / xls files. All you need to reproduce the issue is
in my original post.

Seeya
Matthew

Thanks for your response. The issue is not specific to Office 97, as
stated in my original post. It affects both Office 97 and XP.

Ah, I took that to mean "Office 97 *on* [Windows] XP." Sorry for glazing over that.

Even if I can't find the answer I am needing (read entire original
post for more details) for Office 97, if anyone has it for Office XP
that would be great.

Well, I run Office 2000 (on Windows 2000! <g>), so I guess that leaves me out. But,
if you'd like to email me the DOC/XLS files, I'll let you know what they do here.

 

[Karl E. Peterson]

Where are you putting the code? What's the execution trigger? Doesn't look to me
like your original post contains full repro info, unless you expect folks to guess a
lot, not to mention spend more time than might otherwise be necessary, to help you.
--
Working Without a .NET?
http://classicvb.org/petition

Karl,

There are no doc / xls files. All you need to reproduce the issue is
in my original post.

Seeya
Matthew

Thanks for your response. The issue is not specific to Office 97, as
stated in my original post. It affects both Office 97 and XP.

Ah, I took that to mean "Office 97 *on* [Windows] XP." Sorry for
glazing over that.

Even if I can't find the answer I am needing (read entire original
post for more details) for Office 97, if anyone has it for Office XP
that would be great.

Well, I run Office 2000 (on Windows 2000! <g>), so I guess that
leaves me out. But, if you'd like to email me the DOC/XLS files,
I'll let you know what they do here.

 

[mjwills]

Karl,

I am surprised by your response. I think there is enough information
(the names of the methods would seem to indicate a CommandButton is
involved).

But just in case - I will spell out repro steps in agonising detail:

a) Create a standard blank, new project (with standard included blank
Form1). Add two buttons to it called cmdExcel and cmdSetToNothing.
b) Delete all code in the form and paste in my first code sample (for
Word).
c) Open Task Manager.
d) Run the project and click the first button. Note that WINWORD.EXE is
not running once button code finishes.
e) Delete all code in the form and paste in my second code sample (for
Excel).
f) Open Task Manager.
g) Run the project and click the first button. Note that EXCEL.EXE is
running once button code finishes.
h) Click the second button. Note that EXCEL.EXE is not running once
button code finishes.

Then reread my original post and see if you can address my question.

Thanks
Matthew

 

[Matthew]

Karl,

Also note that the behaviour we are seeing has now been reproduced on
Office 97, 2000, XP, 2003 - on Windows NT 4, 2000 and XP.

So you should be able to repro it yourself on Office 2000 on Windows
2000. See my previous post for detailed repro steps.

Thanks
Matthew

Thanks for your response. The issue is not specific to Office 97, as
stated in my original post. It affects both Office 97 and XP.

Ah, I took that to mean "Office 97 *on* [Windows] XP." Sorry for glazing over that.

Even if I can't find the answer I am needing (read entire original
post for more details) for Office 97, if anyone has it for Office XP
that would be great.

Well, I run Office 2000 (on Windows 2000! <g>), so I guess that leaves me out. But,
if you'd like to email me the DOC/XLS files, I'll let you know what they do here.

 

[Howard Kaikow]

http://www.standards.com/; See Howard Kaikow's web site.

Where are you putting the code? What's the execution trigger? Doesn't look to me
like your original post contains full repro info, unless you expect folks to guess a
lot, not to mention spend more time than might otherwise be necessary, to

help you.

The behavior he sees is due to his not setting the application object =
Nothing after he Quits the app, and he recognizes this in his original
posting.

THere are a number of areas in which Escel does things differently than
Word.
If one sets the application object = Nothing, then this is a non-issue.

He does not say what issues he is encountering in VB .NET, I expect that he
is encountering a difference due to garbage collection in .NET. But he
should still be setting the application object = Nothing, even more
important in VB.NET.

 

[mjwills]

Howard,

Thanks for the response.

Essentially, my question is this. Can I *RELY* on the fact that
app.Quit will close down the Word process? The reason I ask is that I
*CANNOT* rely on this fact when dealing with Excel (as shown with the
code provided in the original posting).

As an aside - the issue becomes especially pertinent with VB.NET, where
setting to Nothing does not automatically decrement the COM reference
count as it did in VB 6. This means that with Excel, for example, you
have to be very careful to ReleaseCOMObject everything (or rely on the
garbage collector - which by its nature cannot be 'relied' upon since
it is non-deterministic). Otherwise it will not close the Excel process
(as shown in my VB 6 sample, where Excel did not close down since the
reference count of the Application object was 1). But this is all an
aside - the problem is not *specific* to VB.NET - my original post
shows the behaviour in VB 6.

(Note that if someone reads the above paragraph and wants to reply
'just use GC.Collect and .WaitForPendingFinalizers' please don't
bother, or at best email me personally (although I check email
sporadically, so don't expect an instant reply). It doesn't address the
underlying issue here, is an unreliable solution, and (IMHO) shows a
lack of understanding of COM Interop and the interaction of COM
reference counting and .NET garbage collection - especially with regard
to Excel. But, lets get back on topic...)

So, knowing what I know about Excel (ie that any object with reference
count >= 1 will keep the EXCEL.EXE process from 'unloading'), I was
surprised to deal with Word and find that app.Quit seemed to reliably
close Word, while it didn't with Excel (see my original posting for
example to show this). But I don't want to *RELY* on the behaviour I am
seeing in Word unless it is documented - or, in other words,
reliable...

The issue is important since we are doing some new VB.NET development
which will involve alot of interaction with Word. So I want to make
sure we don't have lots of phantom WINWORD.EXE processes lying about...

Note that I didn't mention this information in the original post so as
not to cloud the issue, or have people blame it on COM Interop (or say
GC.Collect or the usual pat answers). I was trying to make clear the
issue was a Word vs Excel issue rather than a COM vs .NET issue.

Any light you can shed on the matter would be greatly appreciated.

Thanks
Matthew

 

[Howard Kaikow]

All you can do is set the object variables to nothing and use garbage
collection.

The reliability is dependent on the implementation of Excel/Word and whether
3rd party apps/macros interfere.

For example, a few months ago, I decided to move the Word 2003 variation of
the macros for my Normal and global templates to Word 97, Word 2000 and Word
2003.

The code in Word 2003 is in a DLL, but in the others it is raw source.

Of course, I had to comment out things that do not work in earlier versions.
In effect, all 4 versions of Word are using the same code, but, in Word
2000, I find the following behavior.

If I use File Exit to exit Word, things go as expected, however, if I use
the X button, an instance of WinWord.EXE remains.

This happens only in Word 2000.

I'll have to look at the code, but the likely cause is some 3rd party
AutoClose.

Back in July 2004, I ran into an analogous problem in Word 2003 after
installing OmniPage Pro 14 Office. I found the cause was a badly coded
AutoClose macro in OmniPage. Took a while to track that down.

Bottom line is that there may be no way to assure that an Office app is not
left running due to 3rd party apps, user macros, or whatnot.

All you can do is set the object variables to nothing and use garbage
collection.
If you find specific cases, it is sometimes possible to overcome their
efects, but it can be tricky.

 

[mjwills]

Howard,

I think we are talking in circles.

If you read my original post, my point is that it appears setting
object variables to Nothing is *not* required in Microsoft Word. It is
important my original post is read in detail - if you skim read it, you
will probably miss the thrust of my question or the details of my Word
vs Excel comparison...

In short, my question is simply this:

"Can I rely on this?" (by this I mean that app.Quit will always close
the WINWORD.EXE process, which I think is the case)

If you could show me an instance in which I can't rely on it, that
would be helpful (ie prove I can't rely on it). Otherwise, a statement
by MS saying whether I could or couldn't rely on it would be great.

Seeya
Matthew

 

[Howard Kaikow]

Howard,

I think we are talking in circles.

If you read my original post, my point is that it appears setting
object variables to Nothing is *not* required in Microsoft Word. It is
important my original post is read in detail - if you skim read it, you
will probably miss the thrust of my question or the details of my Word
vs Excel comparison...

The documented behavior is that an object must be set to Nothing to assure
that the object goes away.
Relying on any undocumented behavior, you are on your own.
It makes no sense to not set an app object variable to Nothing after
quitting the app.

 

[mjwills]

Howard,

Relying on any undocumented behavior, you are on your own.

I agree completely. That is why I am looking for a statement somewhere
that what I am seeing in MS Word *is* documented or reliable (that was
my request in my first post).

Possibly, no such statement exists. But if anyone knows that such a
statement *DOES* exist - they are the people I am hoping are following
this thread (and will hopefully shed some light).

Thanks
Matthew

 

[Cindy M -WordMVP-]

Hi Mjwills,

Yes, they behave differently. Another anamoly I seem to recall coming
across is that, if you have an object variable set to an instance of
Excel, and set it to Nothing, that will usually close Excel. But that's
not the case with Word. Word will let you set the object variable to
nothing, yet remain open for the user to continue work.

But I'm sorry, no, I don't know of any place where these differences are
documented.

As background to my issue, I have noticed that .Quit in MS Word (97 /
XP) and .Quit in Excel (97 / XP) seem to have quite different
behaviours. In particular, .Quit results in the Word process unloading
from memory, while .Quit in Excel allows Excel to be unloaded from
memory only if there are no references to objects within the Excel
process.

My question is to identify whether *MS has stated that the behaviour I
am seeing (see below) is documented and reliable* (ie will always
happen).

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question
or reply in the newsgroup and not by e-mail