Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / C# / May 2008

Tip: Looking for answers? Try searching our database.

How to determine whether an object is a VALID COM object

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
abhimanyu - 16 May 2008 12:07 GMT
I have a method Marshal.IsComObject(...) that returns TRUE if an
object is a COM object.
I have an object of Excel.Worksheet that I released using
Marshal.ReleaseComObject(...). I want to iterate over a collection of
Excel.Worksheet and find out which is disposed.
Currently the workaround for me (bad one) is

try
{
   string name = worksheet.Name;
}
catch(Exception e)
{
   // this one was release as I cannot access it
   worksheet = null;
}

Is there any other method through which I can check for a VALID(not
released) COM object?

Regards,
Jeroen Mostert - 16 May 2008 13:07 GMT
> I have a method Marshal.IsComObject(...) that returns TRUE if an
> object is a COM object.
> I have an object of Excel.Worksheet that I released using
> Marshal.ReleaseComObject(...). I want to iterate over a collection of
> Excel.Worksheet and find out which is disposed.

There's no way to determine whether an object is disposed other than using
it and getting an ObjectDisposedException. And that's actually the *good*
scenario. If you were working with pure COM, you'd have no way at all of
knowing whether an interface pointer was valid, and you'd likely just get a
crash if you use an invalid one.

You must keep track of when an object was disposed yourself. In general, do
not dispose objects until you're certain (or have made certain) that nobody
will use them anymore, then you can omit keeping track.

> Currently the workaround for me (bad one) is
>
[quoted text clipped - 3 lines]
> }
> catch(Exception e)

Catch specific exception types, not Exception. The call to worksheet.Name
could fail for multiple reasons, not all of which should simply be silently
discarded.

> {
>     // this one was release as I cannot access it
[quoted text clipped - 3 lines]
> Is there any other method through which I can check for a VALID(not
> released) COM object?

If you know you released the object, why do you need to check for it here?
Somewhere inbetween you discarded information or failed to propagate it.

Why don't you set the reference to null when you release it, rather than
when you find out it was released? If the worksheet is in a collection, why
don't you remove it from the collection?

Signature

J.
http://symbolsprose.blogspot.com

abhimanyu - 16 May 2008 20:55 GMT
Actually, If I am keeping a collections of Sheets in a Dictionary<T>.
If I delete a Excel worksheet manually in Excel, the reference remains
in my Dictionary and when I try to use it, it throws and exception.

There may be other workaround to this problem by following a certain
pattern, But what I wanted to know was whether there is a method that
can avoid that throw.

Regards,
Jeroen Mostert - 17 May 2008 00:58 GMT
> Actually, If I am keeping a collections of Sheets in a Dictionary<T>.
> If I delete a Excel worksheet manually in Excel, the reference remains
> in my Dictionary and when I try to use it, it throws and exception.

I don't know the details of the Excel automation model, but I'd be surprised
if there was no way to detect that the sheet was deleted. There is probably
an event handler for that.

> There may be other workaround to this problem by following a certain
> pattern, But what I wanted to know was whether there is a method that
> can avoid that throw.

To the best of my knowledge, there is not, and even relying on an exception
being generated here is iffy. Using an object when you're not sure if it's
still valid is a bad approach, because you're relying on the COM server to
detect the error for you.

A better way would be to *not* keep the collection of Sheets yourself, but
rely on Excel's collections instead, in combination with some unique sheet
identifier if necessary for maintaining your own data. Do not use a Sheet
without looking up if it still exists.

Signature

J.
http://symbolsprose.blogspot.com


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.