Why does every class in VBA have an Application property?

Question

I would like a bit of clarification about why each class (or nearly each class) in VBA (when you scroll through Object Browser) has an Application property.

MSDN says

When used without an object qualifier, this property returns an Application object that represents the Microsoft Excel application. When used with an object qualifier, this property returns an Application object that represents the creator of the specified object (you can use this property with an OLE Automation object to return the application of that object). Read-only.

The first sentence is pretty clear. Your hosting application used without a qualifier can be one of the MS Office products supporting VBA.

In Excel Debug.Print Application = Microsoft Excel
In Word Debug.Print Application = Microsoft Word
etc...

but...the second sentence is totally unclear to me... So I am thinking like no matter where you call .Application from it will always return the host of an object...

• So, what is the point of each class in VBA to have an Application property?

PS. you can always call .Parent => .Parent to go up the hierarchy... can't you? You can just call the Application wit no qualifier to get that...

I can't even think of one SSCCE OLE scenario for this so I am sorry I am not providing an example. The Application property (not to be confused with Application class) is poorly documented this is why I am asking for someone with more experience to clarify this for me.

    One (well, sort of) scenario, but not sure it even applies here could be using Interop for Office. Like, when you have an external application that opens two files ( one Excel, and one Word ) then by getting references to Ranges in both, you may be able to return Microsoft Excel and Microsoft Word.. but would this be even useful to anyone? hmm..Am I not understanding this entire concept?

Answer 1

There are two levels to this. First, the reason every class has an Application property is because somebody thought it would be a good idea and they made a base class from which every other class inherits. Kind of like the decision to have a Value property or an Item property consistently applied through classes.

The real question is why somebody thought it was a good idea. I don't know, but it was probably Spolsky's idea, so he should answer. I can tell you how I use it.

If I'm automating Outlook from Excel, I'll generally create an olApp variable to hold the Outlook Application. But I don't have to. I could just create, say, a MailItem and reference Application via that. Where I do use the Application property is debugging. I have a MailItem object instantiated and I'm getting an error. I could, for instance, see how many items are in the inbox even though I don't have an application object variable in scope. In the immediate window:

?olMailItem.Application.GetDefaultFolder(1).Items.Count

I could string a bunch of .Parent calls together, but I don't necessarily know how many I would need. Here's where the second part of the MSDN description comes into play. If I use Application with not qualifier (I'm in Excel), it defaults to Excel.Application. But the Application property of olMailItem returns Outlook.Application because that's what's at the top of the object hierarchy that includes the MailItem class.

I think it's just a handy shortcut that somebody thought was so handy they coded it into the base class for all objects.