Klassen in DLL

[RWarnecke]

Hallo zusammen,

ich habe vor verschiedenste Klassen, die ich programmiert habe, in eine DLL zu packen. Ich habe schon ein bisschen im I-Net recherchiert. So einfach wie die Unit einbinden ist es ja nicht. Die Grundstruktur zum Einbinden habe ich hier schon im Entwicklerforum gefunden.

Dazu meine Frage, wenn ich jetzt mich an die Beschreibung halte, gibt es da irgendwelche größeren Stolpersteine ? Oder sollte ich besser Funktionen schreiben, die mir die einzelnen Werte von den Klassen zurückgeben ?

[sirius]

Und warum dann nicht gleich über Interfaces, wenn man schon über rein abstrakte Klassen nachdenkt?

[RWarnecke]

Zitat:

Zitat von sirius

Und warum dann nicht gleich über Interfaces, wenn man schon über rein abstrakte Klassen nachdenkt?

Was ist der Vorteil und Nachteil Interfaces vs. abstrakte Klassen ? Mit Interfaces habe ich noch nicht gearbeitet. Hast Du da zufällig Links mit Tutorials zur Hand, wo ich mich einlesen kann ?

[Assertor]

Guten Morgen Rolf,

ich bin zwar nicht Sirius, aber hier ist eine kleine Anfänger-Einführung in Interfaces zu finden:

http://mwcs.de/tutinterfaces.html

Gruß Assertor

[RWarnecke]

Zitat:

Zitat von Assertor

Guten Morgen Rolf,

ich bin zwar nicht Sirius, aber hier ist eine kleine Anfänger-Einführung in Interfaces zu finden:

http://mwcs.de/tutinterfaces.html

Gruß Assertor

Danke Assertor, werde das mal durcharbeiten. Wenn jemand noch weitere Tutorials kennt, bitte melden, damit ich so viel Info wie möglich bekomme.

[sirius]

Eine mögliche Vorgehensweise (noch ohne COM):

Delphi-Quellcode:

//Unit mit Interface-Deklaration für beide Programmteile:
type ImyInterface=interface
       ['{C55C5E2B-CC7D-4B8F-97BC-AB2A66EAAA33}'] //erstellen mittels [strg]+[shift]+[g]
       procedure doSomething;
       
       procedure setx(value:Integer);
       function getx:Integer;
       property x:Integer read getx write setx;
     end;

Delphi-Quellcode:

Nur in der DLL dann eine Klasse dazu implementieren:
type TmyInterfaceClass=class(TInterfacedObject,ImyInterface)
       //Hier jetzt die (3) Methoden von oben implementieren
       //zusätzlich können noch weitere Methoden und Felder in der Klasse sein,
     end;
     //du kannst jetzt auch weitere Klassen über dasselbe Interface implementieren

//und eine Funktion schreiben, welche das Interface liefert:
function getIntf:IUnknown;
begin
  result:=TmyInterfaceClass.create;
end;

Delphi-Quellcode:

//in der Exe bekommst du die Klasse dann mittels:
var intf:ImyInterface;
begin
  intf:=getIntf as ImyInterface;

[EWeiss]

Zitat:

Eine mögliche Vorgehensweise (noch ohne COM):

Frage mich warum das in Delphi so kompliziert ist ein Klasse für den zugriff von außen zu instanzieren.
In VB erstelle ich ein öffentliche Klasse ganz einfach.. ohne mich mit Interface-Deklaration rumzuschlagen.
Dll 'GenInterface' erstellen dort alle funktionen die ich in anderen Projekten verwenden will öffentlich machen.

Beispiel:

Delphi-Quellcode:

Public Property Get EQVisible() As Boolean
//
End Property

Public Property Let EQVisible(ByVal sEQVisible As Boolean)
//
End Property

Public Sub Execute(ByVal lngHwnd As Long)
//
End Sub

Public Function GetPlaylistBColor(ByVal mColor As OLE_COLOR) As OLE_COLOR
//
End Function

Public Function GetPlaylistFColor(ByVal mColor As OLE_COLOR) As OLE_COLOR
//
End Function

Das wars dann schon..
Nachher muss ich diese DLL als Interfacebrücke nur noch in meine Anwendung als Verweis einbinden.
Die Plugins welche dann mit meiner Anwendung kommunizieren sollen
müssen dann nur eine MasterClass besitzen bsp .. clsMain
Dort implementiere ich das Interface natürlich auch in der Anwendung.

Delphi-Quellcode:

Implements GenInterface.IPluginGen

Dort werden dann alle Funktionen (vererbungen des GenInterface) erneute deklariert.
Und dann kann man zwischen 'Anwendung <GenInterface > Plugin' kommunizieren

Delphi-Quellcode:

Private Property Get IPluginGen_EQVisible() As Boolean
    IPluginGen_EQVisible = EQVis
End Property

Private Property Let IPluginGen_EQVisible(ByVal sEQVisible As Boolean)
    EQVis = sEQVisible
End Property

Private Sub IPluginGen_Execute(ByVal lngHwnd As Long)
    Load frmBrowser
End Sub

Private Function IPluginGen_GetPlaylistBColor(ByVal mColor As stdole.OLE_COLOR) As stdole.OLE_COLOR
    mBackColor = mColor
    getColor = True    
End Function

Private Function IPluginGen_GetPlaylistFColor(ByVal mColor As stdole.OLE_COLOR) As stdole.OLE_COLOR
    mForeColor = mColor
End Function

Also warum ist das in Delphi so kompliziert?

EDIT:
Jede Anwendung die nun über die clsMain verfügt und das GenInterface als
Verweis einbindet kann nun mit meiner Anendung kommunizieren ohne
das sie die Interface-Bezeichnung (['{C55C5E2B-CC7D-4B8F-97BC-AB2A66EAAA33}']) kennen muss

gruss Emil

[SirThornberry]

Du kannst auch mit Packages arbeiten dann ist es ebenfalls so einfach. Wenn du allerdings DLLs verwendest und nicht das vorgefertigte musst du alles von Hand machen.
Warum ist das nicht so einfach: Weil die DLL und die Hauptanwendung im Normallfall ihre eigene Speicherverwaltung haben. Wenn du also mit Strings etc. hantierst muss man immer bedenken das reservierter Speicher dort frei gegeben wird wo er angefordert wurde etc.

[sirius]

(Add zu Sir)
Außerdem kann man in Delphi auch alles über COM machen. Da wird man von der IDE in allem unterstützt.

Abgesehen davon habe ich jetzt nicht verstanden, wo genau die Vereinfachung in VB liegt :gruebel:

[EWeiss]

Zitat:

Zitat von sirius

(Add zu Sir)
Außerdem kann man in Delphi auch alles über COM machen. Da wird man von der IDE in allem unterstützt.

Abgesehen davon habe ich jetzt nicht verstanden, wo genau die Vereinfachung in VB liegt :gruebel:

Ganz einfach das die GenInterface.dll als Brücke zwichen Anwenung .. und Plugin sprich anderer ExeAnwendung fungiert
Was versteht man da nicht :gruebel:

Brauche keine Com keine Interface Deklaration oder ähnliches.
Und muss auch nicht das Interface als solches kennen.

Zitat:

(['{C55C5E2B-CC7D-4B8F-97BC-AB2A66EAAA33}'])

Edit:
Sobald das Interface implementiert ist
kenne ich alle Funktionen Propertys proceduren ohne das ich mich weiter in die API
des Interface einarbeiten muss.
Und zwar in jeder Anwendung Dll oder Exe spielt dabei keine rolle.

gruss Emil

[sirius]

Und was mache ich, wenn ich die DLL aus VB in meinem Delphi einbinden will?

[EWeiss]

Zitat:

Zitat von sirius

Und was mache ich, wenn ich die DLL aus VB in meinem Delphi einbinden will?

Dann bindest du sie als verweis ein und fertig
Das geht mit C mit NET warum nicht auch mit Delphi
Notfalls mit LoadLibrary ;)

gruss Emil

[Bernhard Geyer]

Zitat:

Zitat von EWeiss

Frage mich warum das in Delphi so kompliziert ist ein Klasse für den zugriff von außen zu instanzieren.

Mir runtimepackages hat man ähnliche einfachheit. Bei VB läuft alles über COM mit der bekannt/berüchtigten DLL/COM-Hölle. Seit XP ist das zwar einfacher da man per Side-By-Side Registrierung arbeiten kann, aber das Grundübel besteht immer noch.

[EWeiss]

Dann zeig mal ein Beispiel...
Nur Interesse halber hier ist meins ..
Extra klein ;) VB mit Delphi formatiert hehhehehe...
"Form Main"

Delphi-Quellcode:

Option Explicit

Dim objPerson As IPerson

Private Sub Create_Click()    
    On Error Resume Next

    objPerson = Nothing   
    Set objPerson = CreatePerson(cmbPerson.ListIndex)
    objPerson.GebDatum = CDate(Text1.Text)
    objPerson.Name = Text2.Text

    objPerson.Sprich   
End Sub

Private Sub Form_Load()
    cmbPerson.AddItem "Baby"
    cmbPerson.AddItem "Student"
    cmbPerson.ListIndex = 0   
End Sub

Private Sub Form_Unload(Cancel As Integer)
    Set objPerson = Nothing
End Sub

"Bas"

Delphi-Quellcode:

Option Explicit

Public Enum PersonType
   Baby = 0
   Student = 1
End Enum

Public Function CreatePerson(ByVal ptPerson As PersonType) As IPerson
                                 
    Select Case ptPerson
        Case Baby
            Dim objBaby As cBaby
            Set objBaby = New cBaby
            objBaby.WindelVoll
            Set CreatePerson = objBaby
        Case Student
            Dim objStudent As cStudent
            Set objStudent = New cStudent
            objStudent.Betrunken
            Set CreatePerson = objStudent
    End Select
    
End Function

Exe Fertig !

Die Interface Schnittstelle person ..
"Class"

Delphi-Quellcode:

Option Explicit

Public Property Let GebDatum(ByVal dNew As Date)
End Property

Public Property Get GebDatum() As Date
End Property

Public Property Let Name(ByVal sNew As String)
End Property

Public Property Get Name() As String
End Property

Public Function Sprich() As String
End Function

fertig.
Nun das Baby

Delphi-Quellcode:

Option Explicit

Implements IPerson

Private md_GebDate As Date
Private ms_Name    As String

Private Sub Class_Initialize()
    MsgBox "Baby geboren"
End Sub

Private Sub Class_Terminate()
    MsgBox "Baby 'zerstört' ;)"
End Sub

Private Property Get IPerson_GebDatum() As Date
    IPerson_GebDatum = md_GebDate
End Property

Private Property Let IPerson_GebDatum(ByVal RHS As Date)
    md_GebDate = RHS
End Property

Private Property Let IPerson_Name(ByVal RHS As String)
    ms_Name = RHS
End Property

Private Property Get IPerson_Name() As String
    IPerson_Name = ms_Name
End Property

Private Function IPerson_Sprich() As String
    MsgBox "Ich heisse " & ms_Name & " und bin am " & md_GebDate & " geboren worden"
End Function

//zur Demonstration, das diese Klasse die Vererbten Methoden und Attribute
//beinhaltet, aber auch spezifische Sachen, nur die Klasse betreffend
Public Function WindelVoll()
    MsgBox "Meine Windel is voll. Bitte einmal wechseln"
End Function

Baby als Plugin fertig
Student

Delphi-Quellcode:

Option Explicit

Implements IPerson

Private md_GebDate As Date
Private ms_Name    As String

Private Sub Class_Initialize()
    MsgBox "An der Uni eingeschrieben"
End Sub

Private Sub Class_Terminate()
    MsgBox "Verdammt. Schon wieder rausgeflogen"
End Sub

Private Property Get IPerson_GebDatum() As Date
    IPerson_GebDatum = md_GebDate
End Property

Private Property Let IPerson_GebDatum(ByVal RHS As Date)
    md_GebDate = RHS
End Property

Private Property Let IPerson_Name(ByVal RHS As String)
    ms_Name = RHS
End Property

Private Property Get IPerson_Name() As String
    IPerson_Name = ms_Name
End Property

Private Function IPerson_Sprich() As String
    MsgBox "Ich heisse " & ms_Name & " und bin am " & md_GebDate & " geboren worden"
End Function

//zur Demonstration, das diese Klasse die Vererbten Methoden und Attribute
//beinhaltet, aber auch spezifische Sachen, nur die Klasse betreffend
Public Function Betrunken()
    MsgBox "Boah war die letzte Party übel. Ich glaub ich kotz gleich"
End Function

fertig ...
Jetzt mach das in Delphi ein komplettes Interface mit Plugin support...
Ich behaupte das du mehr an Aufwand betreiben mußt und es so einfach in Delphi nicht geht !!!

gruss Emil

[omata]

Hier mal mein Vorschlag...

[EWeiss]

Zitat:

Zitat von omata

Hier mal mein Vorschlag...

Nicht schlecht aber auch nicht das gleiche ? ;)

Viel mehr Code keine eigenständige DLL in dem sinne wie ich es ausgeführt habe.
Baby und Student sind eigenständige Dll's quasi Plugins und können
unabhängig von deiner Exe erweitert werden zum bsp. noch nen Opa dazu.

Die von dir erstellten Klassen werden nicht von außerhalb angesprochen.
trotzdem fein gemacht..

gruss Emil

[omata]

Ok, neuer Vorschlag...

[EWeiss]

Zitat:

Zitat von omata

Ok, neuer Vorschlag...

Na ja fast ;)
Schmeiß die unit BabyU.pas und StudentU.pas aus dem Exe Projekt raus dann stimmt es in etwa.
Wo ich drauf hinaus wollte ist das man unter Delphi einiges an Code mehr benötigt
und der aufbau nicht so simple ist wie in VB.

Und das hat sich ja bestätigt ;)

Die IPersonU ist Hauptsächlich dafür da das man unter VB alle eigenschafte (vererbungen) im Intelisense zur verfügung hat.
Nur so neben bei als Information.

gruss Emil

[omata]

Zitat:

Zitat von EWeiss

Schmeiß die unit BabyU.pas und StudentU.pas aus dem Exe Projekt raus dann stimmt es in etwa.

Ja, genau die Überlegung hatte ich auch. Dann wurde mir allerdings etwas klar...

Wenn ich eine Anwendung habe, die eine DLL benutzt dann kann ich innerhalb der DLL den Code anpassen und erweitern. Neue Funktionen kann ich dabei auch hinzufügen. Allerdings kennt meine alte Anwendung die neuen Funktionen ja nicht. Wie auch, als sie entstand existierten diese ja nicht. Deshalb die Frage: Wie soll das in VB gehen? Etwas was ich nicht kenne kann ich nicht aufrufen. Deshalb ist es ok, wenn ich die beiden Units in der Anwendung kenne. Oder nicht?

Zitat:

Zitat von EWeiss

Wo ich drauf hinaus wollte ist das man unter Delphi einiges an Code mehr benötigt
und der aufbau nicht so simple ist wie in VB.

Und das hat sich ja bestätigt ;)

Also das sehe ich jetzt nicht so bestätigt. Wo habe ich den wesentlich mehr Code geschrieben?

[EWeiss]

Zitat:

Wenn ich eine Anwendung habe, die eine DLL benutzt dann kann ich innerhalb der DLL den Code anpassen und erweitern. Neue Funktionen kann ich dabei auch hinzufügen. Allerdings kennt meine alte Anwendung die neuen Funktionen ja nicht. Wie auch, als sie entstand existierten diese ja nicht. Deshalb die Frage: Wie soll das in VB gehen? Etwas was ich nicht kenne kann ich nicht aufrufen. Deshalb ist es ok, wenn ich die beiden Units in der Anwendung kenne. Oder nicht?

Du kannst keine Unit's addieren die deiner anwendung nicht bekannt sind.
Baby.dll hat Emil geschrieben die Anwendung von Omata kennt diese aber nicht ..
Wie willst du sie dann addieren ?
Beide kennen wir nur das Interface IPersonU

Nein kannst du nicht!
Ein Plugin ist nur soweit erweiterbar wie die Class IPersonU das zuläßt
Alles darüber hinaus würde fehlschlagen da es in deiner Anwendung nicht verarbeitet wird.

Anwendung und DLL's sind abhängig vom Interface IPersonU
Willst du also neue Dinge hinzufügen geht das nur wenn diese von IPersonU
nach außen freigegeben werden und die neuen Funktionen bzw.. die geänderte Unit im jeweiligen Quelltext übernommen wird
also in jeder DLL und der anwendung aktualisiert wird.

Jedes Programm kann dann die IPersonU einbinden und mit deiner Anwendung kommunizieren. bzw.. die Plugins verwenden.

Zitat:

Also das sehe ich jetzt nicht so bestätigt. Wo habe ich den wesentlich mehr Code geschrieben?

Na ja wollen wir nicht so kleinlich sein. ;)

Meine komplette Anwendung kompiliert verwendet gepackt 22.5KB incl.. Source
Deine 1,2MB gut du hast die Runtime drin .. ohne Source
Auch habe ich keinerlei zusätzliche klassen einbinden müssen.

EDIT:
Auch das einbinden der IPersonU ist eigentlich nicht OK!
Diese ist nämlich ebenfalls eine eigenständige Datei(DLL) also ein Wrapper zwischen deiner Anwendung
und den Dll's welche sie verwenden du darfst also nur das interface von IPersonU einbinden nicht
die komplette Unit.

Interface schreibt PersonX
Ich die DLL und du die Anwendung.
Wird das interface geändert bekommt dieses eine neue GUID und du mußt
deine Anwenung daraufhin anpassen so wie ich meine DLL

Zitat:

Allerdings kennt meine alte Anwendung die neuen Funktionen ja nicht.

Nun kennt deine alte Anwendung die Funktionen auch. ;)

gruss Emil

[Elvis]

Sorry, ich muss hier ein paar fundamentale Missverständnisse aufklären...

Die VB Lib IST eine COM-Lib, VB kann ja gar nix anderes. In VB kann man nichtmal das interface selbst definieren, wodurch Versionierung praktisch unmöglich ist.
IOW: Eine pp, die dein Interface nutzt würde dir nach der Erweiterung desselbigen um die Ohren fliegen, weil VB einfach ncht nur die DispIDs nach der Stellung des Mondes vergibt, auch die reihenfolge der Members ist NICHT sichergestellt.

VB für sowas nutzen zu wollen, und diese fragile und instabile Lösung auch noch als "einfach" anstatt als "vereinfacht bis zum Grade der Nutzlosigkeit" zu bezeichnen kann auch nur einem VB'ler einfallen.

Ich hasse es hier wieder auf Stereotype zurückzukommen, aber VB ist nunmal nur ein erbärmliches Subset von dem was Delphi kann.
IOW: Delphi ist ein Superset von VBs Möglichkeiten. IOW2: Wer VB nutzt, nutzt immer das falsche Tool.

Delphi kennt Interfaces, und die halten sich in Delphi immer an COM-Pflichten, ohne dass du selbst durch die schrecklichen Höllen gehen müsstest, die man mit einer COM-Lib auf sich nehmen würde.

Wenn du deine Interfaces erweitern willst, dann leite einfach ein neues von dem alten ab und implementiere auch das.
Apps oder Plugins, die nur das alte Interface kennen, werden weiterhin funktionieren wie bisher.

Du kannst hier im Forum nach DLL und Interface suchen und solltest genug Posts von mir und anderen dazu finden.
Plugins ohne Packages, aber mit Interfaces sind absolut kein Problem.
Und wenn man sich einmal in die Verwendung von Interfaces eingearbeitet hat, hat man eine wunderbare Lösung, in der Plugins auch kompatible zu zukünftigen Versionen deiner App sind. Einfach weil du neue Versionen der Interfaces als Ableitungen dieser implementierst. :-)

[EWeiss]

Zitat:

Die VB Lib IST eine COM-Lib, VB kann ja gar nix anderes.

Quatsch kann dir DLL Projecte zeigen welche sehr wohl in der lage sind Standard DLL's zu erstellen
Sorry aber du lebst hinterm Mond!

Wenn du schon mitunter aufschlußreiche Dinge von dir gibst was VB angeht
dann Informiere dich bitte vorher richtig als hier Dinge zu verbreiten welche ich so nicht stehen lassen kann.

Zitat:

VB für sowas nutzen zu wollen, und diese fragile und instabile Lösung auch noch als "einfach" anstatt als "vereinfacht bis zum Grade der Nutzlosigkeit" zu bezeichnen kann auch nur einem VB'ler einfallen.

Du bist lustig mit dieser Methode verwalte und initialisiere ich meine Plugins
wie kannst du ohne internen Wissen so was behaupten.
Ich bin sehr wohl in der Lage bis zu 5 Standard und 1 Vis Plugin zur gleichen zeit laufen zu lassen.
Mehr habe ich leider nicht :)

Aber wird langsam OffTopic das Thema hier ;)

bis mutig ?
Dann schau meinen Player geschrieben in VB an
Wenn ich das immer höre von manchen Leuten.
Programmiere seit 15 Jahren mit Vb und 2 mit Delphi und gehe immer wieder gerne zurück .. hehehe

gruss Emil

[Elvis]

Zitat:

Zitat von EWeiss

Zitat:

Die VB Lib IST eine COM-Lib, VB kann ja gar nix anderes.

Quatsch kann dir DLL Projecte zeigen welche sehr wohl in der lage sind Standard DLL's zu erstellen

Du kannst also in VB Funktionen in einer fest definierten Calling convention exportieren, die du per LoadLibary/GetProcAdress ausführen kannst?
Ist das wirklich was du hier behaupten willst? Denn wenn es das nicht ist, dann bringe besser nicht den Mond ins Spiel. :mrgreen:

Zitat:

Sorry aber du lebst hinterm Mond!

Hat aber nix mit VB zu tun, sondern damit, dass es der Letzte Ort ist, an dem man vor Privat TV sicher ist. :mrgreen:

Zitat:

Wenn du schon mitunter aufschlußreiche Dinge von dir gibst was VB angeht
dann Informiere dich bitte vorher richtig als hier Dinge zu verbreiten welche ich so nicht stehen lassen kann.

Ich habe genügend VB Dinger zu etwas richtigen machen müssen, IOW: Ich kenne mich mit VB besser aus als ich will, und auf jeden Fall besser als die meisten VB'ler. ;-)

Zitat:

Zitat:

VB für sowas nutzen zu wollen, und diese fragile und instabile Lösung auch noch als "einfach" anstatt als "vereinfacht bis zum Grade der Nutzlosigkeit" zu bezeichnen kann auch nur einem VB'ler einfallen.

Du bist lustig mit dieser Methode verwalte und initialisiere ich meine Plugins
wie kannst du ohne internen Wissen so was behaupten.
Ich bin sehr wohl in der Lage bis zu 5 Standard und 1 Vis Plugin zur gleichen zeit laufen zu lassen.
Mehr habe ich leider nicht :)

Das heißt noch lange nicht dass man es wirklich so machen will.
Ich habe schon genügend Codes gesehen, die mir die Nackenhaare aufstehen ließen. Angeblich liefen die Programme auch problemlos. Nunja, bis sich mal etwas ändert, was defensive Programmierung abgefangen hätte.
In deinem Falle wäre es interessant zu wissen ob du eine binäre Delphi/C++/FPC DLL mit diesen Interfaces, OHNE COM Registrierung nutzen kannst. Und was passiert wenn du die VB "Klasse" nachträglich erweiterst?
Die bereits kompilierte DLL würde dir um die Ohren fliegen.

Zitat:

Aber wird langsam OffTopic das Thema hier ;)

Jupp, habe das jetzt hier nur geantwortet, weil ich so verhindern wollte, dass irgendjemand auf die Idee kommt tatsächlich VB für sowas nutzen zu wollen. :shock:

willst du dich mehr auslassen, dann schicke mir ein PN. ;-)

[EWeiss]

Zitat:

Du kannst also in VB Funktionen in einer fest definierten Calling convention exportieren, die du per LoadLibary/GetProcAdress ausführen kannst?
Ist das wirklich was du hier behaupten willst? Denn wenn es das nicht ist, dann bringe besser nicht den Mond ins Spiel.

Verlass dich drauf..

Mußte das noch los werden . hihiihih

gruss Emil

[Die Muhkuh]

Zitat:

Zitat von Elvis

willst du dich mehr auslassen, dann schicke mir ein PN. ;-)

Oder als neuen Thread, ist ganz interessant :)

[sirius]

von hier:

Zitat:

Zitat von EWeiss

...

Korrekt
Darum ging es aber auch nicht sondern darum ob ich standard DLL's erstellen kann.

Also kann man das hier gar nicht vergleichen? Wir reden hier über ein Interface ohne COM, wie ich ja schon oben schrieb.

[EWeiss]

Zitat:

Zitat von sirius

von hier:

Zitat:

Zitat von EWeiss

...

Korrekt
Darum ging es aber auch nicht sondern darum ob ich standard DLL's erstellen kann.

Also kann man das hier gar nicht vergleichen? Wir reden hier über ein Interface ohne COM, wie ich ja schon oben schrieb.

Nein kann man nicht.. da hat sich bei dem hin und her ein mißverständins eingeschlichen.

Sorry.. :)

gruss Emil