Warum hat jede Klasse in VBA eine Application-Eigenschaft?

Question

Ich möchte ein wenig Klarheit darüber, warum jede Klasse (oder fast jede Klasse) in VBA (wenn Sie durch den Objektkatalog blättern) hat eine Application Eigenschaft.

MSDN sagt

Wenn ohne ein Objekt Qualifier verwendet, diese Eigenschaft gibt ein Application-Objekt, das die Microsoft Excel-Anwendung darstellt. Bei Verwendung mit einem Objektqualifizierer gibt diese Eigenschaft ein Anwendungsobjekt zurück, das den Ersteller des angegebenen Objekts darstellt (Sie können diese Eigenschaft mit einem OLE-Automatisierungsobjekt verwenden, um die -Anwendung dieses Objekts zurückzugeben). Schreibgeschützt.

Der erste Satz ist ziemlich klar. Ihre Hosting-Anwendung, die ohne Qualifikationsmerkmal verwendet wird, kann eines der MS Office-Produkte sein, die VBA unterstützen.

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

aber ... der zweite Satz ist mir völlig unklar ... So wie, egal ich denke wo rufen Sie .Application aus wird es immer den Host eines Objekts zurückgeben ...

• Also, was ist der Punkt o f jede Klasse in VBA eine Application Eigenschaft zu haben?

PS. Sie können immer .Parent =>.Parent anrufen, um die Hierarchie hoch zu gehen ... können Sie nicht? Sie können einfach die Application wit kein Qualifier anrufen, um das zu bekommen ...

Ich kann nicht einmal an ein SSCCE OLE-Szenario dafür denken, so tut mir leid, ich gebe kein Beispiel. Die Application Eigenschaft (nicht mit ApplicationKlasse zu verwechseln ist) ist schlecht dokumentiert deshalb frage ich nach jemandem mit mehr Erfahrung, um dies für mich zu klären.

        One (gut, irgendwie) Szenario, aber nicht sicher, es gilt auch hier könnte Interop für Office werden. Wenn Sie beispielsweise eine externe Anwendung haben, die zwei Dateien öffnet (ein Excel und ein Word), können Sie in beiden Fällen Range s zurückerhalten. Sie können dann Microsoft Excel und Microsoft Word zurückgeben. Aber wäre dies für irgendjemanden nützlich? hmm..habe ich das ganze Konzept nicht verstanden?

Answer 1

Es gibt zwei Ebenen. Erstens, der Grund, warum jede Klasse eine Application-Eigenschaft hat, ist, weil jemand dachte, es wäre eine gute Idee, und sie haben eine Basisklasse erstellt, von der jede andere Klasse erbt. So wie die Entscheidung, eine Value-Eigenschaft oder eine Item-Eigenschaft konsistent über Klassen anzuwenden.

Die eigentliche Frage ist, warum jemand dachte, es sei eine gute Idee.Ich weiß es nicht, aber es war wahrscheinlich Spolskys Idee, also sollte er antworten. Ich kann dir sagen, wie ich es benutze.

Wenn ich Outlook aus Excel automatisiere, erstelle ich in der Regel eine olApp-Variable für die Outlook-Anwendung. Aber ich muss nicht. Ich könnte damit beispielsweise eine MailItem- und Referenzanwendung erstellen. Wo verwende ich die Eigenschaft Application ist Debuggen. Ich habe ein MailItem-Objekt instanziiert, und ich erhalte einen Fehler. Ich könnte zum Beispiel sehen, wie viele Elemente im Posteingang sind, obwohl ich keine Anwendungsobjektvariable im Bereich habe. In unmittelbaren Fenstern:

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

kann ich Zeichenfolge ein Bündel von .Parent ruft zusammen, aber ich weiß nicht unbedingt, wie viele ich brauchen würde. Hier kommt der zweite Teil der MSDN-Beschreibung ins Spiel. Wenn ich Anwendung mit nicht Qualifikationsmerkmal verwende (ich bin in Excel), wird standardmäßig Excel.Application verwendet. Aber die Application-Eigenschaft von olMailItem gibt Outlook.Application zurück, da dies an der Spitze der Objekthierarchie steht, die die MailItem-Klasse enthält.

Ich denke, es ist nur eine praktische Abkürzung, die jemand für so praktisch hielt, dass sie es für alle Objekte in die Basisklasse einprogrammierte.