COM-Objekt - Klasse nicht registriert ...

[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 von paule32.jk:

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 von paule32.jk:

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 von paule32.jk:

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.

[himitsu]

Zitat von paule32.jk:

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 ) 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



[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 ?