Interop.Excel.ApplicationClass

[MSDN]

1. The MSDN documentation states about the Interop.Excel.ApplicationClass
that:
This class supports the .NET Framework infrastructure and is not intended to
be used directly from your code.
at
http://msdn.microsoft.com/en-us/library/microsoft.office.interop.excel.applicationclass(VS.80).aspx

Why then every workable code example on the internet including two at the
bottom of the same page mentioned above create the Excel instance using
ApplicationClass?

2. Is anything wrong with deriving a class from
Interop.Excel.ApplicationClass? I created an application using this ideea
and it is working just fine. It is like a custom Excel application with a
few extra properties and methods doing some processing.

 

[Cindy M.]

Hi Msdn,

1. The MSDN documentation states about the Interop.Excel.ApplicationClass
that:
This class supports the .NET Framework infrastructure and is not intended to
be used directly from your code.
at
http://msdn.microsoft.com/en-us/library/microsoft.office.interop.excel.applicationclass(VS.80).aspx

Why then every workable code example on the internet including two at the
bottom of the same page mentioned above create the Excel instance using
ApplicationClass?

I see no code samples on the page to which you link... You should use Excel.Application, not
ApplicationClass, in any case.

Andrew Whitechapel writes a bit about this in his book on programming Office with .NET. Here's a
small extract of the discussion "The IAs, including the Office PIAs, include several types with the
same root name, with or without the suffix "Class". You should use only objects that do not end with
the suffix... Confusion can arise because tools such as the Visual Studio Object Broser and ILDASM
show the _Application and AppEvents_Event interfaces, but the only relevant class they show is
ApplicationClass. In fact, there will also be an Application class... The (somewhat invisible)
Application class gives us access to all methods, events, and properties exposed by the "real" Excel
application COM object..."

2. Is anything wrong with deriving a class from
Interop.Excel.ApplicationClass? I created an application using this ideea
and it is working just fine. It is like a custom Excel application with a
few extra properties and methods doing some processing.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
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

 

[Mircea Ion]

The code I was mentioning is posted at the bottom of the page under
Community Content.

It is true is not an official code example from Microsoft but however many ,
many other samples on the internet are using ApplicationClass to declare
their variables which later will be instantiated as Excel objects.
I don't really understand the explanation. To be honest it doesn't even
sound as an explanation as it doesn't tell me why.

However, I rewrote my application using composition so now I have an
....Excel.Aplication as member.
Hopefully by brushing up a few rough edges left I can make it work.

Thank you.

 

[Cindy M.]

Hi Mircea,

The code I was mentioning is posted at the bottom of the page under
Community Content.

I didn't see any code samples, even under "Community Content".

It is true is not an official code example from Microsoft but however many ,
many other samples on the internet are using ApplicationClass to declare
their variables which later will be instantiated as Excel objects.
I don't really understand the explanation. To be honest it doesn't even
sound as an explanation as it doesn't tell me why.

No, he doesn't really go into the "Why" in so many words, but I can't type out
the entire chapter for you. As he's an authority, I recommend you take his word
for it; you might also want to visit his blog and perhaps ask a question of
him. As to the many samples in the Internet: If it's easier for people to
"stumble across" using ApplicationClass than Application, that's what they'll
use. Just as many people use macro recorder code, since they don't know how to
"tweak it" to work correctly with an object model. But that doesn't make it
optimal or correct code, no matter how many code examples are out there.

However, I rewrote my application using composition so now I have an
....Excel.Aplication as member.
Hopefully by brushing up a few rough edges left I can make it work.

It should work, although if you require events that have the same name as a
method (Quit, for example) you'll need to work around that.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
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

 

[McLean Schofield [MSFT]]

Understanding exactly why the <typeName>Class classes exist in the Office
PIAs and why should use the <typeName> interfaces instead requires some
understanding of how COM and the .NET Framework treat types differently. In
most cases, it should be sufficient to stick to the general rule of always
using the interfaces in your code (for example, the
Microsoft.Office.Interop.Excel.Application interface) rather than the classes
(i.e., Microsoft.Office.Interop.Excel.ApplicationClass).

That said, it would be nice if the PIA documentation were clearer about this
in the <typeName>Class topics, and referred the reader to use the
corresponding interface instead. I'll forward this feedback onto the
documentation team in charge of the PIA docs.

If you are curious for a more detailed explanation, I recommend the
following links:
- http://blogs.msdn.com/eric_carter/archive/2004/05/06/127698.aspx (this
also has a nice summary of which types to use in the PIAs, and which to
ignore)
- http://msdn.microsoft.com/en-us/library/ms247302(VS.80).aspx
- http://msdn.microsoft.com/en-us/library/bb612528.aspx

I hope this helps,
McLean Schofield

 

[Mircea Ion]

Thanks man.

Understanding exactly why the <typeName>Class classes exist in the Office
PIAs and why should use the <typeName> interfaces instead requires some
understanding of how COM and the .NET Framework treat types differently.
In
most cases, it should be sufficient to stick to the general rule of always
using the interfaces in your code (for example, the
Microsoft.Office.Interop.Excel.Application interface) rather than the
classes
(i.e., Microsoft.Office.Interop.Excel.ApplicationClass).

That said, it would be nice if the PIA documentation were clearer about
this
in the <typeName>Class topics, and referred the reader to use the
corresponding interface instead. I'll forward this feedback onto the
documentation team in charge of the PIA docs.

If you are curious for a more detailed explanation, I recommend the
following links:
- http://blogs.msdn.com/eric_carter/archive/2004/05/06/127698.aspx (this
also has a nice summary of which types to use in the PIAs, and which to
ignore)
- http://msdn.microsoft.com/en-us/library/ms247302(VS.80).aspx
- http://msdn.microsoft.com/en-us/library/bb612528.aspx

I hope this helps,
McLean Schofield