COM-Objekt - Klasse nicht registriert ...

[paule32.jk]

Hallo,
ich habe soeben mein erstes COM-Objekt mittels Delphi erstellt und kompilieren können.
Das COM-Objekt wird auch irgendwie registriert, da es in der Komponenten-Palette auch
erscheint (als TypeLibrary import glaube ich... ?)

Wenn ich dieses Objekt (Komponente) auf ein Formular platzieren möchte,
dann kommt der Fehler: "Klasse ist nicht registiert.".

Aber ich dachte, durch den Import wird es registriert...
weil: in der Type-Library-Liste steht mein erstelltes Objekt (samt Pfad).

Nach Neustart von Delphi wird es auch nicht aus der Komponenten-Palette gelöscht - es
ist immer noch da.

Nun die Frage:
Wie installiert man eine "dummy" COM-Klasse ?

hier die folgenden Schritte, die ich bereits unternommen habe:
1. neues Anwendungsprojekt (VCL) erstellt
2. COM-Objekt erstellt, mit Interface TTestAuto
3. Kompiliert
4. der TLB Liste hinzugefügt

[skybibo]

Hallo Paule,

COM Objecte können nicht wie normale Klassen verwendet werden. Zur Verwendung musst du das registrierte COM Object CraeteComObject oder CreateOleObject dynamisch einbinden.

Der Vorteil ist, das ein Programm nicht wissen muss, wo das COM Object auf dem PC abgelegt ist. Dies steht nach erfolgter Registrierung in der Registry.

Weiterhin können COM Objecte auch von anderen Programmiersprachen und Scriptsprachen (z.B. VBScript) verwendet werden.

Eine Einbindung wie eine Komponente funktioniert nicht. Es sei denn du erstellst eine ActiveX Komponente, dies ist eine Sonderform eines COM Objects.

Ein passendes Tutorial habe ich leider nicht gefunden. Fündig wirst du eventuell wenn du nach „delphi CreateOleObject“ suchst

Gruß Bernd

[BerndS]

Deine com Klasse muss noch registriert werden.
https://support.microsoft.com/de-de/...a-3f4e0cb543e5

[jaenicke]

Es gibt auch andere Möglichkeiten...
Du kannst z.B. die von einer solchen DLL exportierte Funktion DllGetClassObject selbst aufrufen, dann muss das nicht über das Betriebssystem und die dort registrierte DLL laufen.
Man kann auch eine solche DLL über das Manifest der Anwendung einbinden. Dann ist keine Registrierung notwendig.

Die Frage ist, was du benötigst, sprich was du damit machen möchtest. Wenn du die Klasse für ein vorhandenes System bereitstellen möchtest, musst du es natürlich so machen, wie es dort benötigt wird.

[paule32.jk]

nun, ich schreibe an einen etwas größeren Projekt.
Dazu möchte ich gerne, das der Benutzer, ähnlich Delphi Components, die Möglichkeit
hat, das Programm zu erweiterm.

Im Moment benötige ich eigentlich nur:
- ein Item, als String
- ein Bildchen zu jeden Item
- und eine interne Funktion zu jeden Item

ich habe auf dem git account mit DLL hantiert, was wohl am einfachsten ist.
Allerdings habe ich da im Moment noch paar Problemchen.

[jaenicke]

Für den Zweck ist COM die am wenigsten geeignete Technik.

Du kannst eine Funktion aus der DLL exportieren, die ein Interface mit der gewünschten Funktionalität liefert.

Oder du schreibst mein Projekt für Delphi 7 um, dann kannst du das Interface einfach registrieren und im Host abrufen.

Oder du nimmst doch eine neue Delphiversion und nutzt mein Projekt direkt. Denn wenn du das veröffentlichen möchtest, bringt dir Delphi 7 ohnehin wenig, da potentielle Nutzer eher neuere Versionen nutzen dürften und Generics usw. erwarten dürften. Sprich etwas mehr Komfort.

[himitsu]

LongsStrings (AnsiString/UnicodeString) auch nur wenn SharedMemory
oder eben mit Laufzeitpackages.

Delphi-Klassen/Objekte sollen, ohne Laufteitpackages, sowieso nicht genutzt werden.
Als Windows-Objekt/Interfaces oder als einfacher Bytepuffer, gibt kaum Probleme.

Selbst ein Delphi-Byte-Array ist nicht immer kompatibel, zwischen ALLEN Delphi-Versionen,
ebenso wie die LongStrings, wo über die vielen Jahre schon ein paar Mal was an den Interna rumgepfuscht wurde.

[paule32.jk]

sodele ...

ich glaube, ich habsch geschafft ein Interface anzusprechen.
Auf meinen git Account habe ich eine test3 und eine demo3 Version veröffentlicht, die auf der einen Seite ein Interface bereit stellt, und aud der anderen Seite das Interface durch eine TypeLibrary TLB importiert (demo3).

Jetzt bräuchte ich nur noch was, wo das ganze laden, und entladen protokoliert wird,
um bei Bedarf Funktionen hinzuzufügen.

Das mit den TGUID hat mich ganz schön dahstehen lassen ...
durch einen Tipp von "shmia" von diesen Thread hat mir auch sehr viel geholfen.

naja, und ein wenig selbstrumpobbeln ...

Für weitere Anregungen stehe ich für Feedback gerne zur Verfügung

Anmerkung:
Die Interface Sachen müssen registriert werden, okay.
Wie finde ich mit Delphi heraus, ob meine Interfaces. die ich nutzen möchte auch installiert wurden.
Gibt es da einen automatischen Prozess - oder muss ich da selbst einen regsrv32.exe Prozess ansteuern ?

Anmerkung 2:
Hab jetzt den Code ein wenig leserlicher gemacht (von test3 und demo3).

Anmerkung 3:
Für das Installieren der COM Objekte wird auf dieser Seite empfohlen, die Registrierung während
des Setup-Prozesses zu verarbeiten, da Delphi Versionen < 2007 die Informationen in den tiefen der
globalen Windows-Registry verwusseln.

[jaenicke]

Zitat:

Zitat von paule32.jk (Beitrag 1526135)

Die Interface Sachen müssen registriert werden, okay.
Wie finde ich mit Delphi heraus, ob meine Interfaces. die ich nutzen möchte auch installiert wurden.
Gibt es da einen automatischen Prozess - oder muss ich da selbst einen regsrv32.exe Prozess ansteuern ?

Ich habe dir drei Wege geschrieben wie es ohne Registrierung geht (1. einfache DLL, der einfachste Weg, 2. registration free COM, ein vorgesehener Weg, 3. direkte Nutzung der COM-Funktion, nicht vorgesehener Weg). Wenn du diese nicht nutzen möchtest, musst du die Registrierung durchführen, das ist richtig. Dafür brauchst du aber normalerweise Adminrechte.

Allerdings fehlt da noch einiges mehr an Logik. Denn logischerweise kannst du das gleiche Interface unter dem gleichen Namen nicht mehrfach registrieren...
Willst du also mehr als ein Plugin nutzen, kannst du nicht einfach zure Nutzung die Klasse so erstellen, wie du es aktuell machst.

Was hast du denn gegen die Nutzung normaler DLLs als Plugins? Da wärst du doch längst fertig.

[paule32.jk]

[QUOTE=jaenicke;1526139]

Zitat:

Zitat von paule32.jk (Beitrag 1526135)

Was hast du denn gegen die Nutzung normaler DLLs als Plugins? Da wärst du doch längst fertig.

ja eigentlich habe ich nichts dagegen, DLL einzusetzen.
Allerdings habe ich dann bei COM+ alles unter einen Hut, und muss dann bei der Implementierung
zwei Versionen anfertigen, wenn ich C++ Builder einsetzen möchte.

Es ist nämlich so:
- Momentan arbeite ich an einen Compiler
- das grafische mache ich mit Delphi
- was das Parsen anbelangt, so verwende ich C Code, den ich mit den C++ Builder übersetze

Nun lassen sich die Welten C++ und Delphi ja nicht so ohne weiteres verkoppeln.

Ich habe bei der Implementierung auch schon daran gedacht, da ja Interfaces "globale" Funktionen
zur Verfügung stellen, sowas wie Mangeling zu machen - in etwa so (als String/DLL-Funktion):

MeinKlasse__AMethode_Parameter1Parameter2

C++ verwendet doch sowas, nur das ich das dann irgendwie mit einer Map-Klasse zu hinfrimmel, das
aus den String ein Objekt wird.
Unter Delphi und C++ Builder gibts ja die Klassen TClass, ClassName ...

Wie schon geschrieben, ich bin da noch ziemlich neu drinn, und für Feedback sehr empfänglich.

[jaenicke]

Zitat:

Zitat von paule32.jk (Beitrag 1526142)

ja eigentlich habe ich nichts dagegen, DLL einzusetzen.
Allerdings habe ich dann bei COM+ alles unter einen Hut, und muss dann bei der Implementierung
zwei Versionen anfertigen, wenn ich C++ Builder einsetzen möchte.

COM-basierte Interfaces funktionieren überall gleich, egal ob unter Delphi oder C++. Im Gegenteil ist genau das mit allem kompatibel, ohne etwas zu registrieren oder ähnliche Verrenkungen.

Du exportierst einfach eine Funktion in der DLL, die das Interface zurück liefert, rufst diese Funktion aus der Hostanwendung auf und schon kannst du mit dem Inteface arbeiten. Dabei ist es egal, welchen Teil du in Delphi, C++ oder anderen nativen Sprachen schreibst. FÜr die Nutzung mit C# muss man noch ein wenig mehr beachten, das siehst du in meinem Projekt, aber dann geht sogar das.

Für Strings kannst du PChar oder WideString/BSTR nutzen.

[paule32.jk]

Ja, Danke für Deine Tipps !

Die Neue Fragen sind nun,

- wie kann ich eine Liste über Plugins in meiner Anwendung führen ?
- wie kann ich eine Funktion bereitstellen, die in meiner Anwendung ein Bild zur Verfügung stellt
(also erstmal alles nur ein Bildchen, das je nach Plugin dynamisch ladbar ist.

aber ich sehe gerade ... Du hast schon einen Post abgesetzt ...

[paule32.jk]

okay, ich habe es auf DLL und WideString umgestellt...
geht nun prima.

Danke für die Tipps.

[jaenicke]

Eine Liste der Plugins kannst du leicht erstellen, indem du alle DLLs in einem vorgegebenen Plugin-Verzeichnis versuchst zu laden. Die müssen dann eine bestimmte Funktion exportieren, die dir Informationen über das Plugin als Interface liefert. Gibt es diese Funktion nicht, ist es kein gültiges Plugin.

Ein großer Vorteil von Interfaces:
Du kannst neue Versionen des Interfaces anbieten und mit Supports prüfen, ob das zurückgelieferte Interface diese auch unterstützt.

[himitsu]

Zitat:

Zitat von paule32.jk (Beitrag 1526142)

Nun lassen sich die Welten C++ und Delphi ja nicht so ohne weiteres verkoppeln.

Leider doch, aber besch*** Weise ausschließlich falschrum.
Delphi-Units (vorkompilierte DCU? direct die PAS ins C++Projekt :shock:) lassen sich im C++Builder nutzen,

dabei wäre es andersrum wesentlich sinnvoller, damit man die Unmasse an C++Codes/Komponenten im Delphi nutzen könnte.
Wie gesagt, https://www.delphipraxis.net/213572-...von-gnu-c.html :freak:



[add]
https://blogs.embarcadero.com/mixing-delphi-and-c/
https://www.youtube.com/watch?v=6f5UBL0bQ9U

https://learncplusplus.org/what-you-...-in-c-builder/
https://docwiki.embarcadero.com/RADS...ics_in_C%2B%2B

http://rvelthuis.de/articles/articles-cppobjs.html
https://stackoverflow.com/questions/...sses-in-delphi

[paule32.jk]

grüner Daumen an Dich !!!
könnte ein Feature "gefällt mir" geben - oder übersehe ich das hier ?