C# Delegates in Delphi konsumieren

[Elvis]

Zitat von Nic2012:

Jo richtig der Entw. aus http://www.systemwidgets.com/Blog/ta...M-clients.aspx erwähnte auch, dass ihm dieser Wurf nach vielem Probieren erst gelungen ist. Zu dem Thema ist nun im Web auch wenig zu finden, und das liegt bestimmt nicht daran, dass es "trivial" ist.

Trivial ist Interop nie, nicht wenn man es für etwas sinnvolles benutzen will.
Aber die Lösung da ist wirklich nicht schön.

Zitat von Nic2012:

Den Entwurf von Elvis habe ich aber noch nicht ganz verstanden

Hast du versucht es in einer Delphi Console App und mit einer C# classlibrary nachzubauen? Worüber bist du gestolpert? Ich würde erst bei diesem Beispiel bleiben, und erst dann das Gelernte auf dein Projekt anwenden.

Zitat:

Zitat:

Außerdem musst du IDispatch nehmen

Hatte ich das nicht im Interface der Events getan ? Oder meint er statt ClassInterfaceType.AutoDual der Hauptklasse ?

Ja, IDispatch nehmen zu müssen ist einer der Nachteile der Lösung. Nicht nur weil es keine cOmpiler-Prüfungen mehr gibt.
Denn was da passiert ist, dass du da indirekt einen Event als Property misbrauchst, auch wenn er es nicht ist. Das funktioniert hier nur weil es ebenfalls 2 Methoden sind.
Allerdings dürfte dir schon der Getter Ärger machen. Der Setter sollte funktionieren weil die Signatur des set_ einer Property kompatibel zum add_ eines Events ist. Das get_ einer property ehingegen hat kein Gegenstück bei Events. Vllt. hat Microsoft hier einen Workaround eingebaut der das auf irgendeine kranke Art zurechtbiegt. Würde ich aber selbst dann nicht nutzen wollen...

Zitat:

Wird im Entwurf von Elvis noch ein Com-Object erzeugt oder ist das eine Lib ?
In dem Delphi Client spreche ich das Com-Interface an und die exportierte DLL ?

In meinem Entwurf wird ein Post-Build-Task von mir verwendet, der es ermöglicht aus C# heraus Funktionen zu exportieren. (So wie man es mit Delphi-DLLs kann)
Dieser wird autom. für dich eingerichtet, wenn du das Nuget-Package in dein Projekt registrierst.

Ich nutze in dem Beispiel .Nets Fähikeiten um .Net-Typen kompatibel zu native Typen zu machen. Deshalb müssen die Interfaces ComVisible sein, und man braucht auch eine Guid, da darüber Interfaces in Delphi (und andere anderen System) identifiziert werden.
Außerdem muss ich .Net sagen, dass meine Interface einfach nur von IUnknown erben, und dadurch kompatibel zu Delphi sind.

Im Endeffekt nutze ich also all die Vorteile von .Net-COM/Interop aus, ohne dass man eine COM library registrieren muss.

[Nic2012]

Ich kann Dir noch nicht folgen, also eins nach dem anderen, ich fasse zusammen:

1) In VS-2010 wird eine neue Classlibary C#-DLL angelegt, die wird allerdings nicht als COM registriert noch unterstützt sie Com/Interop. also diesen beiden Schalter im Projekt im Gegensatz zum meinem Beispiel ausschalten
2) Dein Codeentwurf so komplett übernehmen
3) Abschließend die DLL exportieren ? Dabei sind mir die Begriffe "Post-Build-Task" und "Nuget-Package" nicht geläufig...
4) Die erzeugte C#-DLL kopiere ich in das Delphi-Projekt ?
5) In Delphi entfällt der Schritt "Typbiliothek importieren..." ???
Wo wird Deine Interface-Deklaration in das Delphi-Projekt übernommen ?
6) Ich übernehme Deine Implementation in die Delphi-Anwendung, warum darf es nicht der Client sein, sondern eine Console ?
Interface und Implementation kommen erstmal in die gleiche Unit ?
Wäre es möglich, dass Du die komplette Delphi Unit als Attachment ranhängst.

[Elvis]

Zitat von Nic2012:

Ich kann Dir noch nicht folgen, also eins nach dem anderen, ich fasse zusammen:
1) In VS-2010 wird eine neue Classlibary C#-DLL angelegt, die wird allerdings nicht als COM registriert noch unterstützt sie Com/Interop. also diesen beiden Schalter im Projekt im Gegensatz zum meinem Beispiel ausschalten

Lass die Einstellungen einfach sie sind/waren.

Zitat:

2) Dein Codeentwurf so komplett übernehmen
3) Abschließend die DLL exportieren ? Dabei sind mir die Begriffe "Post-Build-Task" und "Nuget-Package" nicht geläufig...

Ich habe dir in meinem ersten Beitrag gezeigt, wie man das Nuget-Package in das Projekt bekommt. Da Nuget bei VS2010 noch nicht von Anfang an dabei war, kann es sein, dass du es erst mit dem Extension Manager installieren musst.
Allerdings kompiliert das angehängte Projekt auch ohne Nuget (da das nuget in meinem VS bereits alles eingestellt hat)
VS ohne Nuget ist aber grauenvoll, wenn du Nuget nicht kennst, solltest du das unbedingt nachholen.

Zitat:

4) Die erzeugte C#-DLL kopiere ich in das Delphi-Projekt ?

Wo auch immer du sie haben willst.
In dem angehängten Bespiel habe ich einen gemeinsamen Ausgabeordner für Debug/x86 für Delphi und C#. Dadurch sollten sie sich finden.

Zitat:

5) In Delphi entfällt der Schritt "Typbiliothek importieren..." ???

Ja, man schreibt die Interfaces selbst. Sowohl in Delphi als auch in C#.
Wenn du hierfür für dein eigentliches Projekt Hilfe brauchst, einfach fragen. Dieses Wissen um Interop zahlt sich 1000-fach aus.

Zitat:

Wo wird Deine Interface-Deklaration in das Delphi-Projekt übernommen ?
6) Ich übernehme Deine Implementation in die Delphi-Anwendung, warum darf es nicht der Client sein, sondern eine Console ?
Interface und Implementation kommen erstmal in die gleiche Unit ?
Wäre es möglich, dass Du die komplette Delphi Unit als Attachment ranhängst.

Ich habe ein Archiv angehängt in dem du das C#-projekt und eine Delphi-App findest.
Ich habe in Delphi die Typen, die für das reine Eventhandling nötig sind, in eine eigene Unit gepackt. Die könntest du später enfach übernehmen (haben ja nix mit dem Hund zu tun ).

Ich habe es in und für Delphi 2010 geschrieben. Das einzige, was in älteren Version nicht geht sind die anonymen Methoden.
Wenn du also ein Delphi nutzt, dass älter als D2010 ist, musst du das sagen, dann muss ich es etwas umschreiben.
Ich habe die Solution in VS2012 erzeugt, ich hoffe ich habe alle Stellen gefunden, über die 2010 stoplern würde...

[Nic2012]

Danke, ich habe hier nur Delphi7 und gerade jetzt nur VS2008, ansonsten VS2010, da komme ich jetzt nicht ran. Ich bekomme hier auch Probleme mit dem ISet<INotifyEventHandler> in VS2008.

Was macht Nuget nun wirklich ? Wird ohne N. trotzdem die DLL gebaut ? Oder anders gefragt, wenn ich die Classlib. anpasse, oder gar eine neue DLL schreibe, muss ich das zwingend benutzen, um die o.g. Funktionalität zu bekommen ?

Ist es das hier was ich sonst bräuchte: http://visualstudiogallery.msdn.micr...f-c7cf6bc9970c So wie das sehe gibt es das nur für >= VS 201x.

[Elvis]

Zitat von Nic2012:

Danke, ich habe hier nur Delphi7 und gerade jetzt nur VS2008, ansonsten VS2010, da komme ich jetzt nicht ran. Ich bekomme hier auch Probleme mit dem ISet<INotifyEventHandler> in VS2008.

Was macht Nuget nun wirklich ? Wird ohne N. trotzdem die DLL gebaut ? Oder anders gefragt, wenn ich die Classlib. anpasse, oder gar eine neue DLL schreibe, muss ich das zwingend benutzen, um die o.g. Funktionalität zu bekommen ?

Nuget ist ein Package Manager. D.h. er sorgt dafür, dass alle Abhängigkeiten eines Packages vorhanden sind, und dass Scripts des Packages ausgeführt werden, die zum Beispiel einen Build Task eintragen oder neue Code files einbinden.

VS2008 macht IMO überhaupt keinen Sinn mehr. Dann nimm lieber VS2012 Express. Selbst VS 2008 mit Resharper wird dir kaum soviel Wert bieten wie es VS2012 Express mit Nuget kann.

Wenn du mit dem alten VS _jetzt_ weitermachen willst, nimm die Lösung mit IDispatch.
Mein DllExport untertützt nur noch Nuget und damit VS2010.

Ein TNotifyEventImplementierung für D7 liefer ich nachher nach.