Have you looked at Excel itself. IIRC, Excel had a problem closing its' process if
the Activate method was used rather than Select. I might not be contributing anything
to this but XL.WorkBooks.Sheet.Range("A1").Activate would cause another instance of
Excel. XL.WorkBooks.Sheet.Range("A1").Select was the workaround and then when you
closed the app and checked for XL= Nothing it was true. Using Activate left
XL=Nothing false.
Hope this isn't OT but I haven't followed the entire thread. Aplogies if I've wasted
your time.
Bob
-------Original Message-------
From: Ryan <[EMAIL PROTECTED]>
Sent: 02/05/03 08:40 AM
To: [EMAIL PROTECTED]
Subject: [ADVANCED-DOTNET] OleMainThreadWndName error when automating Excel
using COM Interop
>
> I have been spending some time working on an automation server for Excel
spreadsheets using C# and COM Interop. The basic idea of what I
am doing is (from .NET code):
1) Launch a new instance of Excel using COM interop
2) Add a new worksheet
3) Modify some of the fields in the new worksheet
4) Then release my references to the Excel objects by calling
ReleaseComObject() on both the Excel.workbook and Excel.Application objects.
After releasing my references to the Excel objects, Excel remains open and
ready for direct user interaction (the basic idea is that the user then
modifies the worksheet and saves and closes it when they choose to). The
problem I am seeing is that once every few times the user closes
Excel (after I have released my references), a dialog box pops up saying
(something on the lines of) "OleMainThreadWndName -- Excel.exe
Error" and the body is "The application at 0x######## reference memory at
0x######## . . . .). Now I have only seen reports of this problem
occuring on Windows NT (not XP), but thats not to say it doesn't also
occur on XP.
A couple of notes:
1) The application creating the Excel objects runs as its own process and
of course, Excel is running as an out of process COM server here.
I believe that OleMainThreadWndName is an object that synchronizes
requests into Excel since its running as an STA. My best guess is that on
Windows NT, there might have been issues with COM where an out of process
COM server had to be created and destroyed on the same thread
(but that is just a wild guess).
Thanks for any help or insight you can offer.
Ryan
===================================
This list is hosted by DevelopMentor® http://www.develop.com
You may be interested in this chat on Microsoft Windows Embedded platforms
6 Feb 2003, 9:30am PST Chat Room:
http://communities2.microsoft.com/home/chatroom.aspx?siteid=34000070
View archives and manage your subscription(s) at
http://discuss.develop.com
>
===================================
This list is hosted by DevelopMentor� http://www.develop.com
You may be interested in this chat on Microsoft Windows Embedded platforms
6 Feb 2003, 9:30am PST Chat Room:
http://communities2.microsoft.com/home/chatroom.aspx?siteid=34000070
View archives and manage your subscription(s) at http://discuss.develop.com
