In message <F1D24A8C-A7DD-48C4-A177-9013E348F0E5@microsoft.com>
at 12:00:02 on Fri, 14 Sep 2007, Norra <Norra@discussions.microsoft.com>
wrote
>My original posts mentioned that I am using Office 2003 so that should tell
>you what version.
Have you patched it to SP2 at all?

Signature
Mike News
Norra - 14 Sep 2007 20:56 GMT
Mike,
Did you read all the posts? My original post clearly states "I have updated
Office to SP2 and all the latest security patches with great antcipation that
it would solve the problem. Didn't happen!!!"
Therefore, the answer to your question is found there and just in case you
need it again, YES!!!
> In message <F1D24A8C-A7DD-48C4-A177-9013E348F0E5@microsoft.com>
> at 12:00:02 on Fri, 14 Sep 2007, Norra <Norra@discussions.microsoft.com>
[quoted text clipped - 3 lines]
> >
> Have you patched it to SP2 at all?
Comments in line -
"Norra" <Norra@discussions.microsoft.com> wrote in message
> My original posts mentioned that I am using Office 2003 so that should tell
> you what version.
Indeed you did. Two posts later I had forgotten and instead referred to your
code where you cater for multiple versions.
> It appears to be overkill but if you researced the history
> of appXL.Quit you will find that in VS2003 when referencing the Excel 11.0
> Object Library Quit does not actually do that every time som I am forcing it
> to Quit in instances where Quit does not actually kill the EXCEL.EXE process
> in taskmanager.
You missed my point or perhaps I didn't explain clearly, namely -
You have appXL Quit followed by appXL.Hwnd (or appXL.Caption).
Normally that would throw an error trying to reference the now non existent
app.
If I'm right about a potential error there, speculating, does code pass to
an error handler in the calling routine thereby missing -
System.Runtime.InteropServices.Marshal.ReleaseComObject(appXL)
appXL = Nothing
Suggest assign the handle (or caption) to an apppropriate variable before
doing appXL.quit.
> The caption I gave it is unique, that is why I gave it a caption to make
> sure that is the one that is killed.
OK, you hadn't said hence the suggestion.
> As I said in my previous post and reiterate here, I ABSOLUTELY am sure there
> are no other objects.
That may well be the case but somethimes object references are not obvious.
FWIW roughly 50% I suggest double checking it proves worthwhile.
> My application quits properly if there are no Excel memory errors, i.e., on
> normal occassions. But when I get the memory error I have to force the
> process to be killed before I can restart my machine or the machine won't
> restart.
> Excel may not be the problem but it is an obvious Excel Error that is
> causing the problem so therefore I assume it is an Excel problem.
Did you try my suggestion to make the Excel visible before quitting, say
until the problem is sorted.
> L8r G8r
> Tom
Regards,
Peter T
> > Your code appears to clear the objects, but if anything overkill !
> > Why PostMessage WM_QUIT or proc.Kill() when you have already done
[quoted text clipped - 19 lines]
> > Regards,
> > Peter T
Norra - 17 Sep 2007 01:58 GMT
I cater for multiple versions because it allows me to run my application on
multiple platforms without having to rewrite code. Better safe than sorry
later.
You have a point in regards to the order of precident here and that is
changed now, but that is not what is causing the error.
Double checked, triple checked and quadruple checked but still the same
result.
Did not try your suggestion to make the Excel visible before quitting but I
will try to sneak that in on the next version output.
L8r G8r
Tom