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 prop

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.