Announcement

**Bernhard Geyer** · 24.11.2003, 13:54

Als Klasse nicht.

Aber wenn Du dir ein Funktionsinterface daf�r erstellst und diese DLL-Funktionen entsprechend C#-Syntax einbindest schon.
F�r jede Methode die du von der Klasse verwenden willst lege ein DLL-Funktion an. Wenn du die Klasse in mehreren Instanzen verwenden willst mu�t Du als ersten Parameter noch einen Handle-parameter definieren der die Instanz der Klasse bestimmt.

Die 2te M�glichkeit w�re �ber COM zu gehen. Erstellen eine COM-Wrapper und binde diesen dann in C# ein.

Ich w�rde die erste Methode bevorzugen, da dur die COM-Probleme (Registrierung, Versionsproblem) sparst

**J�rgen Wollenberg** · 24.11.2003, 18:22

Hallo Bernhard, danke f�r deine schnelle Antwort, h�ttest Du vielleicht ein kleines Code-Beispiel auf Lager? Die erste Idee scheint mir auch die Bbessere zu sein. Ich w�rde das ganze Spektum einer Klasse nutzen wollen (Eigenschaften, Methoden und ganz wichtig Ereignisse). W�re nett, wenn du mir auch dort helfen k�nntest. Danke in Voraus! MfG J�rge

**Bernhard Geyer** · 25.11.2003, 09:33

Hallo J�rgen,

leider hab ich daf�r kein Code-Beispiel auf Lager. Das Prinzip kenn ich nur aus einem C++-Programm aus meiner alten Arbeitsstelle. Und das ist auch schon ca 4 Jahre her ..

**Andreas Kosch** · 25.11.2003, 13:36

Hallo,

wenn die "alte" DLL-Schnittstelle �ber P/Invoke bedient werden soll, muss die eigene Delphi-DLL f�r jede Funktion eine so genannten Schnittstellenprozedur (siehe Delphi-Hilfe) deklarieren und exportieren. Allerdings kann auf diesem Weg keine Klasseninstanz �bertragen werden.

Der einzige "saubere" Weg besteht darin, die Delphi-Klasse �ber ein Automation-Objekt (COM) zu verpacken, und von .NET aus diese Umverpackung �ber COM Interop zu nutzen. Nur so lassen sich auch Ereignisse (Events) in Richtung .NET transportieren. Eine Schnittstellen-Prozedur (reine DLL-Schnittstelle ohne COM) kann so etwas nicht leisten.

In einem praktischen Beispiel sieht das dann so aus (ein C#-Client greift auf ein Delphi 6-Automationobjekt zu, das Events ausl�st). Die eigene Hilfsklasse AdressverwaltungEventsHelperClass implementiert das Interface IAutObjEvents des Automation-Objekts, um dort gleich 2 Aufgaben zu erf�llen: 
1. Nutzfunktion der Events von IAutObjEvents 
2. Kontrollieren der Lebensdauer der Interface-Zeiger

<pre>
using System;
using System.Runtime.InteropServices;
using System.Windows.Forms;

namespace AdressverwaltungCSClient
{
/// <summary>
/// Hilfsklasse kapselt die Events der Adressverwaltung ein
/// </summary>
public class AdressverwaltungEventsHelperClass: Adressverwaltung.IAutObjEvents
{
private Form1 aMainForm;
private UCOMIConnectionPoint icp;
private UCOMIConnectionPointContainer icpc;
private int cookie;

/// <summary>
/// Default-Konstruktor (ohne eigene Funktion)
/// </summary>
public AdressverwaltungEventsHelperClass()
{
}

/// <summary>
/// �berladener Konstruktor legt Verweis auf das Hauptformular in einem
/// eigenen Objektfeld (aMainForm) ab und baut dann die Verbindung zur
/// ConnectionPoint-Schnittstelle von COM auf.
/// </summary>
/// <param name="aForm"></param>
public AdressverwaltungEventsHelperClass(Form1 aForm)
{
aMainForm = aForm;
icpc = (UCOMIConnectionPointContainer)aMainForm.aObj;
Guid IID_IMyEvents = typeof(Adressverwaltung.IAutObjEvents).GUID;
icpc.FindConnectionPoint(ref IID_IMyEvents,out icp);
icp.Advise(this,out cookie);
}

/// <summary>
/// Der Anwender hat in der Adressverwaltung auf den Button �Weiter� geklickt,
/// die Kundendaten liegen somit vor, die Verbindung zur Adressverwaltung 
/// kann abgebaut werden. Dazu ruft das Programm die Interface-Methode �pQuit�
/// des Automations-Objekts (nicht des Events-Objekts!) auf.
/// </summary>
/// <param name="vAdrId"> <description>Adress-ID des Kunden </description></param>
/// <param name="vAdrAend"></param>
/// <param name="vVersNr"></param>
public void OnNext(object vAdrId, object vAdrAend, object vVersNr)
{
aMainForm.DoSetData(vAdrId.ToString(), vAdrAend.ToString());
aMainForm.aObj.pQuit();
}

/// <summary>
/// Benutzer hat den Abbrechen-Button in der Adressverwaltung angeklickt, damit 
/// das Programmfenster der Adressverwaltung ohne Warnhinweis verschwindet, muss
/// der "offizielle" Weg des Verbindungsabbaus beschritten werden. Das eigene
/// Programm ruft dazu die Interface-Methode �pQuit� des Automations-Objekts auf. 
/// </summary>
public void OnAbort()
{
aMainForm.aObj.pQuit();
}

/// <summary>
/// Das Event-Objekt der Adressverwaltung k�ndigt das Programmende an, das eigene
/// Programm muss alle aktiven Interface-Zeiger freigeben, damit Windows f�r die
/// Adressverwaltung nicht den Warnhinweis f�r die noch offenen COM-Verbindungen
/// anzeigt. 
/// </summary>
public void OnQuit()
{
icp.Unadvise(cookie);
// 1. Interface 
while (Marshal.ReleaseComObject(icp) > 0)
;
icp = null;
// 2. Interface
while (Marshal.ReleaseComObject(icpc) > 0)
;
icpc = null;
}
}
}
</pre>
Aufruf im C#-Programm:
<pre>
public Adressverwaltung.AutObjClass aObj;
public void DoSetData(string sAdr_id, string sDatum)
{
label1.Text = sDatum;
label2.Text = sAdr_id;
}
private void buttonStartSinkContainer_Click(object sender, System.EventArgs e)
{
aObj = new Adressverwaltung.AutObjClass();
AdressverwaltungEventsHelperClass aSinkHelper = new AdressverwaltungEventsHelperClass(this);
aObj.fStart(0,null);
}
</pre&gt

**J�rgen Wollenberg** · 25.11.2003, 17:26

Hallo, Allen erstmal vielen Dank, ich werde mich jetzt hinsetzen um die Sachen auszuprobieren. MfG J�rge

Announcement

Delphi4.0-Klassen in C# nutzen

Delphi4.0-Klassen in C# nutzen

Comment

Comment

Comment

Comment

Comment