COM-Anwendungen entwickeln

Nach oben zu Entwickeln von interoperativen Anwendungen mit COM

Delphi stellt Experten und Klassen bereit, mit denen sich Anwendungen, die auf dem Component Object Model (COM) von Microsoft beruhen, einfach implementieren lassen. Mit Hilfe dieser Experten können Sie COM-basierte Klassen und Komponenten zur Verwendung in einer einzelnen Anwendung erstellen oder voll funktionsfähige COM-Clients und Server erzeugen, die COM-Objekte, Automatisierungsserver (einschließlich Active Server Objects), ActiveX-Steuerelemente oder ActiveForm-Objekte implementieren.

In diesem Thema werden folgende Bereiche erläutert:

• Überblick zu COM-Technologien
• COM-Interfaces
• COM-Server
• COM-Clients

Überblick zu COM-Technologien

COM ist ein sprachunabhängiges Software-Komponenten-Modell, das die Interaktion zwischen Software-Komponenten und Windows-Anwendungen ermöglichen soll. Die Bedeutung von COM besteht im Wesentlichen darin, dass dieses Modell durch klar definierte Interfaces (Schnittstellen) die Kommunikation zwischen Komponenten, zwischen Anwendungen und zwischen Clients sowie Servern ermöglicht. Interfaces bieten Clients die Möglichkeit, von einer COM-Komponente Informationen über die zur Laufzeit unterstützten Funktionen abzurufen. Um eine Komponente mit zusätzlichen Features auszustatten, fügen Sie einfach ein weiteres Interface hinzu.

Eine Anwendung kann auf die Interfaces von COM-Komponenten, die sich auf demselben Computer wie die Anwendung oder auf einem anderen in das Netzwerk eingebundenen Computer befinden, zugreifen. Im zweiten Fall geschieht dies über einen Mechanismus, der als Distributed COM oder DCOM bezeichnet wird.

COM stellt sowohl eine Spezifikation als auch eine Implementierung dar. In der COM-Spezifikation werden die Erstellung von Objekten und die Kommunikation zwischen Objekten definiert. Nach Maßgabe dieser Spezifikation können COM-Objekte in unterschiedlichen Sprachen erstellt sowie in unterschiedlichen Prozessräumen und auf unterschiedlichen Plattformen ausgeführt werden. Solange die Objekte spezifikationskonform sind, können sie miteinander kommunizieren. Auf diese Weise kann älterer Quelltext (Legacy-Code) als Komponente mit neuen Komponenten integriert werden, die in objektorientierten Sprachen geschrieben wurden.

Die COM-Implementierung gehört zum Win32-Subsystem, das eine Reihe von zentralen Diensten zur Verfügung stellt, welche die Spezifikation unterstützen. Die COM-Bibliothek enthält eine Reihe von Standard-Interfaces, welche die Hauptfunktionen eines COM-Objekts definieren. In der Bibliothek sind einige API-Funktionen enthalten, mit deren Hilfe COM-Objekte erstellt und verwaltet werden.

Durch die Verwendung von Delphi-Experten und VCL-Objekten in Ihrer Anwendung greifen Sie auf die Delphi-Implementierung der COM-Spezifikation zu. Zusätzlich stellt Delphi noch kapselnde Komponenten (Wrapper) für diejenigen COM-Dienste zur Verfügung, die nicht direkt implementiert werden (wie z.B. Active-Dokumente). Diese Wrapper sind in der Unit ComObj definiert, die API-Definitionen sind in der Unit AxCtrls enthalten.

Anmerkung:  Die Interfaces sowie die Sprache von Delphi sind an der COM-Spezifikation ausgerichtet. Delphi implementiert Objekte entsprechend den COM-Spezifikationen durch eine Anzahl von Klassen, das sog. Delphi ActiveX-Framework (DAX). Diese Klassen sind in den Units AxCtrls, OleCtrls und OleServer enthalten. Das Delphi-Interface für die COM-API befindet sich in ActiveX.pas und ComSvcs.pas.

COM-Interfaces

Die COM-Clients kommunizieren mit den Objekten über COM-Interfaces. Bei den Interfaces handelt es sich um Gruppen von logisch oder semantisch zusammengehörigen Routinen, die die Kommunikation zwischen einem Anbieter eines Dienstes (Server-Objekt) und seinen Clients ermöglichen.

Jedes COM-Objekt muss beispielsweise das grundlegende Interface IUnknown implementieren. Über die Routine QueryInterface in IUnknown können Clients andere vom Server implementierte Interfaces anfordern.

Objekte können mehrere Interfaces aufweisen, von denen jedes eine eigene Funktionalität implementiert. Ein Interface stellt eine Möglichkeit dar, dem Client mitzuteilen, welcher Dienst zur Verfügung gestellt wird, ohne dass Implementierungsdetails darüber geliefert werden, wie und wo das Objekt diesen Dienst zur Verfügung stellt.

Im Folgenden sind die wichtigsten Merkmale von COM-Interfaces beschrieben.

• Nach ihrer Veröffentlichung ändern sich Interfaces nicht mehr. Sie können sich darauf verlassen, dass ein Interface eine bestimmte Gruppe von Funktionen zur Verfügung stellt. Zusätzliche Funktionalität wird durch weitere Interfaces bereitgestellt.
• Vereinbarungsgemäß beginnen die Bezeichner von COM-Interfaces mit dem Großbuchstaben I, auf den ein symbolischer Name folgt, der das Interface definiert, wie z.B. IMalloc oder IPersist.
• Durch Verwendung eines GUID (Globally Unique Identifier) ist gewährleistet, dass Interfaces immer eindeutig identifizierbar sind. Bei einem GUID handelt es sich um eine zufällig generierte 128-Bit-Zahl Interface-GUIDs werden auch IIDs (Interface Identifiers) genannt. Dadurch werden Benennungskonflikte zwischen unterschiedlichen Versionen eines Produkts oder zwischen verschiedenen Produkten vermieden.
• Interfaces sind sprachunabhängig. Sie können ein COM-Interface mit Hilfe jeder beliebigen Sprache implementieren, solange diese Sprache eine Struktur von Zeigern unterstützt und mit ihr entweder implizit oder explizit über einen Zeiger eine Funktion aufgerufen werden kann.
• Interfaces sind selbst keine Objekte, sondern sie stellen eine Möglichkeit zum Zugriff auf Objekte zur Verfügung. Daher greifen Clients nicht direkt, sondern über einen Interface-Zeiger auf Daten zu. Windows 2000 benutzt einen weiteren Umweg (Interceptor), über den es COM+-Features wie Just-In-Time-Aktivierung und Objekt-Pooling bereitstellt.
• Interfaces entstehen immer durch Vererbung vom grundlegenden Interface IUnknown.
• Interfaces können von COM über Proxy-Server so umgeleitet werden, dass Aufrufe der Interface-Methoden zwischen Threads, Prozessen und im Netzwerk laufenden Computern erfolgen können, ohne dass die Client- bzw. Server-Objekte diese Umleitung bemerken.

Das Interface IUnknown

Alle COM-Objekte müssen das grundlegende Interface IUnknown unterstützen, eine Typdefinition (typedef) des Interface-Basistyps IInterface. IUnknown enthält die folgenden Routinen:

• QueryInterface: Stellt Zeiger zu anderen Interfaces zur Verfügung, die das Objekt unterstützt.
• AddRef und Release: Einfache Referenzzählmethoden, die die Lebensdauer eines Objekts verfolgen, sodass ein Objekt sich selbst löschen kann, wenn der Client seinen Dienst nicht mehr benötigt.

Clients erhalten Zeiger auf andere Interfaces über die IUnknown-Methode QueryInterface. QueryInterface kennt alle Interfaces im Server-Objekt und kann einem Client einen Zeiger auf das angeforderte Interface liefern. Der Empfang eines Zeigers auf ein Interface signalisiert dem Client, dass er alle Methoden des Interface aufrufen kann.

Objekte verfolgen ihre eigene Lebensdauer über die IUnknown-Methoden AddRef und Release, bei denen es sich um einfache Referenzzählmethoden handelt. Solange der Referenzzähler für ein Objekt ungleich Null ist, bleibt das Objekt im Speicher geladen. Sobald der Referenzzähler den Wert Null erreicht, kann die Interface-Implementierung das zugrunde liegende Objekt sicher aus dem Speicher entfernen.

COM-Interface-Zeiger

Ein Interface-Zeiger ist ein Zeiger auf eine Objektinstanz, die ihrerseits auf die Implementierung der jeweiligen Methode im Interface zeigt. Auf die Implementierung wird über ein Array von Zeigern zugegriffen, das VTable genannt wird. Diese Tabellen virtueller Funktionen ähneln dem Mechanismus zur Unterstützung virtueller Funktionen in Delphi. Wegen dieser Ähnlichkeit kann der Compiler Aufrufe von Interface-Methoden in gleicher Weise auflösen wie Aufrufe von Methoden von Delphi-Klassen.

Die VTable wird von allen Instanzen einer Objektklasse gemeinsam benutzt, sodass der Objekt-Quelltext jeder Objektinstanz eine zweite Struktur zuweist, die dessen private-Daten enthält. Der Interface-Zeiger des Clients fungiert dann als Zeiger auf den Zeiger zur VTable.

Windows 2000 und seine Nachfolger enthalten für Objekte, die unter COM+ ablaufen, eine zusätzliche Ebene (Interceptor) zwischen dem Interface-Zeiger und dem VTable-Zeiger. Der Interface-Zeiger des Clients zeigt auf den Interceptor, der wiederum auf die VTable zeigt. Dadurch kann COM+ Dienste wie Just-In-Time-Aktivierung anbieten, wobei der Server dynamisch und für den Client undurchlässig deaktiviert und reaktiviert werden kann. Dazu muss COM+ sicherstellen, dass sich der Interceptor wie ein normaler VTable-Zeiger verhält.

COM-Server

Bei einem COM-Server handelt es sich um eine Anwendung oder eine Bibliothek, die einer Client-Anwendung oder Client-Bibliothek Dienste zur Verfügung stellt. Ein COM-Server besteht aus einem oder mehreren COM-Objekten, wobei ein COM-Objekt eine Gruppe von Eigenschaften und Methoden darstellt.

Den Clients ist nicht bekannt, wie ein COM-Objekt seinen Dienst durchführt, die Implementierung des Objekts bleibt verborgen. Ein Objekt stellt seine Dienste über seine Interfaces (siehe oben) zur Verfügung.

Zudem brauchen die Clients nicht zu wissen, wo sich ein COM-Objekt befindet. COM bietet transparenten Zugriff unabhängig vom Standort des Objekts.

Wenn ein Client einen Dienst von einem COM-Objekt anfordert, übergibt er einen Klassenbezeichner (CLSID) an COM. Ein CLSID ist nichts weiter als ein GUID, der ein COM-Objekt bezeichnet. Über diesen CLSID, der in der Registrierungsdatenbank eingetragen ist, sucht COM die entsprechende Server-Implementierung. Nachdem der Server lokalisiert ist, lädt COM den Quelltext in den Speicher und veranlasst den Server, eine Objektinstanz für den Client zu erzeugen. Dieser Vorgang erfolgt indirekt durch ein spezielles (auf Interfaces basierendes) Klassengeneratorobjekt, das auf Anforderung Instanzen von Objekten erzeugt.

Ein COM-Server muss mindestens folgende Schritte ausführen:

• In der Registrierdatenbank Einträge registrieren, die das Server-Modul dem Klassenbezeichner (CLSID) zuordnen.
• Ein Klassengeneratorobjekt implementieren, der ein anderes Objekt mit einer bestimmten CLSID erstellt.
• Den Klassengenerator für COM bereitstellen.
• Einen Mechanismus zur Verfügung stellen, über den ein Server, der gerade keine Clients bedient, aus dem Speicher entfernt werden kann.

COM-Clients

COM-Clients sind Anwendungen, die ein COM-Objekt nutzen, das von einer anderen Anwendung implementiert wurde. Die häufigsten Typen sind Automatisierungs-Controller, die einen Automatisierungsserver steuern, sowie ActiveX-Container, die als Host eines ActiveX-Steuerelements fungieren.

Es gibt zwei Typen von COM-Clients: Controller und Container. Controller starten den Server und kommunizieren mit ihm über sein Interface. Sie fordern Dienste vom COM-Objekt an oder benutzen es als separaten Prozess. Container hingegen enthalten visuelle Steuerelemente oder Objekte, die in der Benutzeroberfläche des Containers sichtbar sind, und verwenden vordefinierte Interfaces, über die sie Einzelheiten der Darstellung mit Server-Objekten aushandeln. Container-Beziehungen über DCOM sind nicht möglich. So müssen z.B. visuelle Steuerelemente, die in der Benutzeroberfläche des Containers angezeigt werden, vor Ort lokalisiert werden. Da von ihnen erwartet wird, dass sie sich selbst zeichnen, müssen sie auf lokale GDI-Ressourcen zugreifen können.

Die Erstellung dieser beiden Arten von COM-Clients ist jedoch sehr ähnlich: Die Client-Anwendung ruft ein Interface für das Server-Objekt ab und verwendet seine Eigenschaften und Methoden. Delphi erleichtert Ihnen die Entwicklung von COM-Clients, denn Sie haben die Möglichkeit, eine Typbibliothek oder ein ActiveX-Steuerelement in eine kapselnde Komponente (Wrapper) zu importieren, sodass Server-Objekte wie andere VCL-Komponenten aussehen. Delphi ermöglicht die Kapselung der Server-CoClass in einer Komponente auf dem Client, die Sie dann sogar in der Komponentenpalette installieren können. Beispiele für solche Komponenten-Wrapper werden auf zwei Registerkarten der Komponentenpalette angezeigt: ActiveX-Wrapper auf der Registerkarte ActiveX und Automatisierungsobjekte auf der Registerkarte Server.

Selbst wenn Sie ein Server-Objekt nicht in einem Komponenten-Wrapper kapseln und in der Komponentenpalette installieren, müssen Sie diese Interface-Definition Ihrer Anwendung zur Verfügung stellen. Dazu können Sie die Typinformationen des Servers importieren.

Clients können immer die Interfaces eines COM-Objekts abfragen, um zu prüfen, welche Fähigkeiten das Objekt besitzt. Alle COM-Objekte erlauben einem Client, bekannte Interfaces abzurufen. Zusätzlich können Clients den Server nach den von dem Interface bereitgestellten Methoden fragen, sofern der Server das Interface IDispatch unterstützt. Den Server-Objekten ist es gleichgültig, welcher Client die Objekte benutzt. Entsprechend gleichgültig ist es den Clients, wie ein Objekt Dienste verfügbar macht; sie vertrauen einfach darauf, dass Server-Objekte die Dienste bereitstellen, die sie in ihren Interfaces beschreiben.

COM-Erweiterungen

Im Laufe seiner Entwicklung wurde das COM-Modell weit über die grundlegenden COM-Dienste hinaus erweitert. COM dient als Basis für andere Technologien wie etwa Automatisierung, ActiveX-Steuerelemente, Active-Dokumente und Active-Verzeichnisse. Für die Arbeit in großen, verteilten Umgebungen stehen zusätzlich Transaktionsobjekte zur Verfügung. In früheren Windows-Versionen waren diese Objekte nicht Teil der COM-Architektur, sondern nur innerhalb der MTS-Umgebung (Microsoft Transaction Server) einsetzbar. Mit Windows 2000 wurde diese Unterstützung in COM+ integriert. Delphi stellt Experten zum schnellen und einfachen Implementieren von Anwendungen zur Verfügung, welche die oben genannten Technologien in der Delphi-Umgebung nutzen.

Automatisierung

Unter Automatisierung wird die Fähigkeit verstanden, Objekte in einer anderen Anwendung über die Programmierung so zu steuern, wie dies ein Makro tut, das in mehreren Anwendungen gleichzeitig arbeiten kann. Das manipulierte Server-Objekt wird Automatisierungsobjekt genannt, der Client eines Automatisierungsobjekts wird als Automatisierungs-Controller bezeichnet. Die Automatisierung kann für In-Process-, Out-of-Process- und externe Server verwendet werden.

Die Automatisierung ist durch zwei Hauptmerkmale gekennzeichnet:

• Das Automatisierungsobjekt definiert eine Reihe von Eigenschaften und Befehlen und beschreibt deren Funktionalität über Typbeschreibungen. Zu diesem Zweck muss eine Möglichkeit vorhanden sein, Informationen über die Interfaces des Automatisierungsobjekt, die Interface-Methoden und die Argumente dieser Methoden zu liefern. In der Regel stehen diese Informationen in einer Typbibliothek zur Verfügung. Der Automatisierungsserver kann Typinformationen auch dynamisch generieren, wenn er dazu über sein IDispatch-Interface aufgefordert wird.
• Automatisierungsobjekte müssen den Zugriff auf diese Methoden anderen Anwendungen ermöglichen. Dazu implementieren sie das Interface IDispatch. Über dieses Interface kann ein Objekt seine gesamten Methoden und Eigenschaften bereitstellen. Durch die Primärmethoden dieses Interface können die Methoden des Objekts aufgerufen werden, nachdem sie zuvor über Typinformationen identifiziert wurden.

Für Entwickler, die nicht-visuelle OLE-Objekte erstellen und verwenden möchten, die in jedem Prozessraum ausgeführt werden können, ist die Automatisierung gut geeignet. Einer der Gründe hierfür liegt darin, dass das Interface IDispatch den Marshaling-Mechanismus automatisiert. Bei der Automatisierung gelten jedoch Einschränkungen bezüglich der verwendbaren Typen.

ActiveX-Steuerelemente

Mit Hilfe der Delphi-Experten können Sie schnell und einfach ActiveX-Steuerelemente erzeugen. ActiveX ist eine Technologie, die COM-Komponenten (insbesondere Steuerelemente) kompakter und effizienter macht. Das ist besonders für Steuerelemente erforderlich, die für die Verwendung im Intranet konzipiert sind und zum Gebrauch von einem Client heruntergeladen werden müssen.

ActiveX-Steuerelemente sind visuelle Komponenten, die nur als In-Process-Server arbeiten. Sie können in eine für ActiveX ausgelegte Container-Anwendung integriert werden. ActiveX-Steuerelemente sind keine eigenständigen Anwendungen, sondern vorgefertigte OLE-Steuerelemente, die in unterschiedlichen Anwendungen eingesetzt werden können. Sie besitzen eine Benutzeroberfläche und verwenden vordefinierte Interfaces, über die sie Einzelheiten der Ein- und Ausgabe sowie der Darstellung mit ihren Host-Containern aushandeln.

ActiveX-Steuerelemente verwenden die Automatisierung zur Bereitstellung ihrer Eigenschaften, Methoden und Ereignisse. Die Funktionalität von ActiveX-Steuerelementen umfasst die Fähigkeit, Ereignisse auszulösen, Bindungen zu Datenquellen herzustellen und die Lizenzierung zu unterstützen.

ActiveX-Steuerelemente werden oft als interaktive Objekte auf Webseiten verwendet. In dieser Funktion hat sich ActiveX zu einem Standard insbesondere für interaktive Inhalte für das World Wide Web entwickelt, was auch die Verwendung von ActiveX-Dokumenten zur Anzeige von nicht im HTML-Format vorliegenden Dokumenten in Web-Browsern mit einschließt. Weitere Informationen über die ActiveX-Technologie finden Sie auf der Microsoft-Website zu ActiveX.

Active-Dokumente

Active-Document-Objekte (früher OLE-Dokumente) sind COM-Dienste, die Verknüpfen und Einbetten, Drag&Drop und visuelles Bearbeiten unterstützen. Active-Dokumente können nahtlos Daten oder Objekte in verschiedenen Formaten aufnehmen, beispielsweise Klangdateien, Kalkulationstabellen, Text und Bitmap-Grafiken.

Sie sind im Gegensatz zu ActiveX-Steuerelementen nicht auf prozessinterne Server beschränkt und können in prozessübergreifenden Anwendungen eingesetzt werden.

Active-Document-Objekte können im Gegensatz zu Automatisierungsobjekten (die fast nie sichtbar sind) auch in einer anderen Anwendung angezeigt werden. Daher werden sie für zwei Arten von Daten verwendet: Präsentationsdaten, die ein Objekt auf einem Bildschirm oder Ausgabegerät darstellen, und native Daten, mit denen ein Objekt bearbeitet wird.

Active-Dokumente können Dokument-Container oder Dokument-Server sein. Delphi stellt zwar keinen Experten zum automatischen Erstellen von Active-Dokumenten zur Verfügung, aber Sie können mit der VCL-Klasse Vcl.OleCtnrs.TOleContainer das Verknüpfen und Einbetten in vorhandenen Active-Dokumenten unterstützen.

Ferner lassen sich Vcl.OleCtnrs.TOleContainer-Objekte als Basis für einen Active-Dokument-Container verwenden. Zum Erstellen von Objekten für Active-Dokument-Server verwenden Sie den Experten für COM-Objekte und implementieren die entsprechenden Interfaces für diesen Objekttyp, je nachdem, welche Dienste das Objekt unterstützen muss. Weitere Informationen zur Erzeugung und Verwendung von Active-Dokument-Servern finden Sie auf der Microsoft-Website zu ActiveX.

Anmerkung:  Während die Spezifikation für Active-Dokumente über eine integrierte Unterstützung für den Marshaling-Mechanismus bei prozessübergreifenden Anwendungen verfügt, können Active-Dokumente nicht auf externen Servern ausgeführt werden, da sie mit spezifischen Typen für ein System auf einem bestimmten Computer arbeiten, beispielsweise mit Fenster-Handles, Menü-Handles usw.

Transaktionsobjekte

In Delphi wird der Begriff "Transaktionsobjekte" für Objekte benutzt, die von den Transaktionsdiensten, der Sicherheit und dem Ressourcenmanagement profitieren, die der Transaktionsserver MTS von Microsoft (bis Windows 2000) oder COM+ (ab Windows 2000) bereitstellt. Diese Objekte sind für die Arbeit in einer großen verteilten Umgebung ausgelegt.

Transaktionsdienste sind so robust, dass Vorgänge entweder immer vollständig ausgeführt oder rückgängig gemacht werden. Der Server führt niemals Teilaufträge aus. Die Sicherheitsdienste erlauben unterschiedliche Unterstützungsebenen für unterschiedliche Klassen von Clients. Das Ressourcenmanagement gestattet einem Objekt die Verwaltung mehrerer Clients durch die Zusammenfassung von Ressourcen oder dadurch, dass Objekte nur dann aktiviert bleiben, wenn sie benutzt werden. Damit das System diese Dienste bereitstellen kann, muss das Objekt das Interface IObjectControl implementieren. Für den Zugriff auf die Dienste benutzen Transaktionsobjekte ein Interface mit der Bezeichnung IObjectContext, das auf ihre Aufforderung hin von MTS oder COM+ erzeugt wird.

Unter MTS muss das Server-Objekt in einer DLL erstellt werden, die dann in der MTS-Laufzeitumgebung installiert wird. Somit ist das Server-Objekt ein In-Process-Server, der im Prozessraum der MTS-Laufzeitumgebung abläuft. Unter COM+ besteht diese Einschränkung nicht, weil alle COM-Aufrufe über einen Interceptor geleitet werden. Für Clients ist der Unterschied zwischen MTS und COM+ nicht von Bedeutung.

MTS oder COM+-Server fassen Transaktionsobjekte zusammen, die im selben Prozessraum ablaufen. Unter MTS wird eine solche Gruppe als MTS-Package bezeichnet, unter COM+ als eine COM+-Anwendung. Auf einem Computer können mehrere unterschiedliche MTS-Packages (oder COM+-Anwendungen) laufen, wobei jede dieser Gruppen einen eigenen Prozessraum besitzt.

Für Clients sind Transaktionsobjekte gewöhnliche COM-Server-Objekte. Ein Client benötigt keine Kenntnisse von Transaktionen, Sicherheit oder Just-In-Time-Aktivierung, solange er nicht selbst Transaktionen initiiert.

Sowohl MTS als auch COM+ enthalten ein separates Tool zur Verwaltung von Transaktionsobjekten. Damit können Sie Objekte in Packages oder COM+-Anwendungen integrieren, die auf dem Computer installierten Packages oder COM+-Anwendungen betrachten, die Attribute der enthaltenen Objekte ansehen oder ändern, Transaktionen überwachen und verwalten, Objekte für Clients verfügbar machen usw. Unter MTS handelt es sich bei diesem Tool um den MTS-Explorer, unter COM+ um den COM+-Komponentenmanager.

Typbibliotheken

Typbibliotheken bieten eine Möglichkeit, weitere Typinformationen zu einem Objekt zu erhalten, als über das Objekt-Interface ermittelt werden können. Die in Typbibliotheken enthaltenen Typinformationen liefern benötigte Informationen über Objekte und deren Interfaces, z.B. die Auskunft, welche Interfaces für welche (anhand der CLSID identifizierten) Objekte vorhanden sind, welche Elementfunktionen für jedes Interface existieren und welche Argumente für diese Funktionen benötigt werden.

Sie können Typinformationen entweder durch Abfragen einer gerade ausgeführten Instanz eines Objekts oder durch Laden und Lesen von Typbibliotheken abrufen. Diese Informationen ermöglichen Ihnen das Implementieren eines Clients, der ein bestimmtes Objekt verwenden soll, wobei Sie im einzelnen wissen, welche Elementfunktionen benötigt werden und was an diese Elementfunktionen übergeben werden muss.

Die Clients von Automatisierungsservern und ActiveX-Steuerelementen erwarten, dass solche Typinformationen zur Verfügung stehen. Alle Delphi-Experten generieren automatisch eine Typbibliothek (nur beim Experten für COM-Objekte ist dies optional). Sie können diese Art von Informationen auch mit dem Typbibliothekseditor anzeigen und ändern.

Siehe auch

• COM-Experten verwenden