Delphi-ActiveX-DLL in VB.Net: Problem mit Strings

[Bbommel]

Einen schönen Nachmittag in die Runde,

ich begebe mich gleich in drei Bereichen auf für mich neues Gebiet und stoße da vielleicht etwas an meine Grenzen: Testen von XE2, Entwicklung einer ActiveX-DLL und Arbeiten mit Visual Studio. Wobei ich letzteres vor allem nutzen wollte, um zu testen, ob das, was ich in Delphi an DLL erstellt habe, auch unter anderen Systemen funktioniert.

Das Ziel wird es letztlich sein, einem Kunden eine DLL zur Verfügung zu stellen, über die er von einem Server Daten in sein eigenes System importieren kann. Hier geht es aber jetzt erst einmal nur darum, ein paar ganz einfache Tests ans Laufen zu bekommen.

Ein Vorteil, statt einer "einfachen DLL" eine ActiveX-DLL zu nehmen, sei es unter anderem, dass man einfacher mit Strings arbeiten kann, so dachte ich. Doch genau daran scheitert es: Wenn ich aus VB.Net heraus eine Funktion aufrufe, die einen String zurückgibt, erhalte ich (in VB) eine Zugriffsverletzung.

Folgendes habe ich gemacht:

In Delphi ein neues Projekt erstellt, und zwar eine "ActiveX-DLL". Dort habe ich dann ein "Automatisierungsobjekt" hinzugefügt und diesem wiederum zwei Methoden verpasst. Die DLL "myteststr32.dll" exportiert dann die Typbibliothek "TestStr32" mit dem Interface "IStringOps" und dort den beiden Methoden "ReverseStr" und "CountStrLength".

"ReverseStr" soll einen String übergeben bekommen und diesen in umgekehrter Reihenfolge zurückgeben. "CountStrLength" soll einfach nur die Länge des Strings zurückgeben (spannend, oder? )

So sieht die Implementierung in Delphi aus:

Delphi-Quellcode:

unit teststr32_impl;

{$WARN SYMBOL_PLATFORM OFF}

interface

uses
  ComObj, ActiveX, TestStr32_TLB, StdVcl;

type
  TStringOps = class(TAutoObject, IStringOps)
  protected
    function CountStrLength(const aInStr: WideString): SYSINT; stdcall;
    function ReverseStr(const aInStr: WideString): WideString; stdcall;
  end;

implementation

uses ComServ;

function TStringOps.CountStrLength(const aInStr: WideString): SYSINT;
begin
  Result:=Length(aInStr);
end;

function TStringOps.ReverseStr(const aInStr: WideString): WideString;

var i: integer;

begin
  Result:='';
  for I := length(aInStr) downto 1 do
    Result:=Result+aInStr[i];
end;

initialization
  TAutoObjectFactory.Create(ComServer, TStringOps, Class_StringOps,
    ciMultiInstance, tmApartment);
end.

Wenn ich die DLL, die beim Compilieren entsteht, registriere und dann in einem neuen Delphi-Projekt diese einbinde, dann klappt das auch alles ganz ausgezeichnet. Das Wichtige soll es aber sein, dass auch außerhalb der Delphi-Welt alles funktioniert.

Weil ich gerade eh ein Win8-Testsystem mit Visual Studio 2011 Beta hier habe, dachte ich mir, dass sich das doch gut für einen Test eignen würde.

Also: Neues WinForms-Projekt erstellt, zwei Buttons, ein Editfeld ("Textbox") und ein Label für die Ausgabe auf das Formular gezogen. Die DLL lässt sich hier mindestens so leicht wie in Delphi importieren (Projekt->Verweis hinzufügen) und kann dann im Code verwendet werden. Im Formular soll man nun in die Textbox einen beliebigen Text eingeben können. Bei dem Druck auf den einen Button soll angezeigt werden, wie lang der Text ist, beim anderen Button soll der umgedrehte Text ausgegeben werden. So sieht der Code aus:

Code:

Public Class Form1
    Private Sub ButtonReverse_Click(sender As Object, e As EventArgs) Handles ButtonReverse.Click
        Dim testStr As TestStr32.StringOps
        testStr = New TestStr32.StringOps

        LabelResult.Text = testStr.ReverseStr(TextBoxInput.Text)
    End Sub

    Private Sub ButtonLength_Click(sender As Object, e As EventArgs) Handles ButtonLength.Click
        Dim testStr As TestStr32.StringOps
        testStr = New TestStr32.StringOps

        LabelResult.Text = testStr.CountStrLength(TextBoxInput.Text).ToString
    End Sub
End Class

Funktioniert nur nicht. Also: ButtonLength_Click, also die Ausgabe, wie lang der String ist, klappt tadellos, aber die Ausgabe des umgedrehten Textes führt beim Aufruf der Funktion zu einer Zugriffsverletzung, also genau in der Zeile:

Code:

LabelResult.Text = testStr.ReverseStr(TextBoxInput.Text)

Ideen? Mache ich in VB irgendwas falsch oder in Delphi oder machen Strings hier generell wieder mal Probleme?

Hilfe!

Bis denn
Bommel

[Iwo Asnet]

Versuch mal OleVariant als Typenbezeichnung anstatt Widestring.

[Bbommel]

Immerhin sieht die Fehlermeldung in VB jetzt anders aus:

Code:

Die Typensignatur der Methode ist nicht Interop-kompatibel.

(kommt an der selben Stelle wie vorher).

Auch wenn ich anstelle einer direkten Ausgabe ins Label zuerst mal versuche, das Ergebnis einer Variable vom Type "VariantType" oder "Object" zuzuweisen, bekomme ich diesen Fehler.

Hmmm....

[Bbommel]

Ich habe mir mal diese Liste angesehen und geschaut, welche Typen vielleicht noch in Frage kommen.

Nun habe ich mich für LPWSTR entschieden, was in der Delphi-Implementierung dann zu einem PWideChar wird. Ich habe gehofft, dass das funktioniert, weil es mich doch stark an eine "normale" DLL erinnert.

Tatsächlich war ich damit erfolgreich. Der Code in Delphi sieht nun so aus:

Delphi-Quellcode:

function TStringOps.ReverseStr(const aInStr: WideString): PWideChar;
var i: integer;
    tempStr: string;
begin
  tempStr:='';
  for I := length(aInStr) downto 1 do
    tempStr:=tempStr+aInStr[i];
  Result:=PWideChar(tempStr);
end;

Damit klappt es dann, die DLL, spezizell diese Methode, sowohl in einem anderen Delphi-Projekt wie auch im oben erwähnten VB.Net-Projekt einzubinden.

Jetzt bin ich zwar erst mal froh, dass es funktioniert, aber hat irgendwer noch eine Idee, was die Ursache für meine Probleme war? Liegt es daran, dass hier die Grenze zwischen COM- und .Net-Techniken überschritten wurde?

Danke fürs Lesen
Bommel

[shmia]

Also das "gefällt" mir gar nicht mit deinem PWideChar als Rückgabewert.
Das ist nicht sicher und auch nicht Scriptfähig.

Also, was du braucht ist ein sogenanntes Duales Interface.
Es zeichnet sich dadurch aus, dass es von IDispatch abgeleitet ist und man daher nur bestimmte (sichere) Datentypen verwenden darf.
Ausserdem werden Exceptions, die in deiner DLL entstehen automatisch aufgefangen und korrekt an den Aufrufer weitergeleitet.

Hier ein Beispiel.
Man erkennt
1.) ITest ist abgeleitet von IDispatch
2.) safecall Aufrufkonvention (wichtig für Exception Weiterleitung)
3.) Zusätzliches dispinterface - um den Zugriff über das IDispatch-Interface zu beschleunigen

Delphi-Quellcode:

// *********************************************************************//
// Schnittstelle: ITest
// Flags:     (4416) Dual OleAutomation Dispatchable
// GUID:      {03D4B87D-FB7A-4632-831C-6318AE294C42}
// *********************************************************************//
  ITest = interface(IDispatch)
    ['{03D4B87D-FB7A-4632-831C-6318AE294C42}']
    function  CountStringLength(const Value: WideString): Integer; safecall;
    function  ReverseStr(const Value: WideString): WideString; safecall;
  end;

// *********************************************************************//
// DispIntf:  ITestDisp
// Flags:     (4416) Dual OleAutomation Dispatchable
// GUID:      {03D4B87D-FB7A-4632-831C-6318AE294C42}
// *********************************************************************//
  ITestDisp = dispinterface
    ['{03D4B87D-FB7A-4632-831C-6318AE294C42}']
    function  CountStringLength(const Value: WideString): Integer; dispid 2;
    function  ReverseStr(const Value: WideString): WideString; dispid 3;
  end;

[Bbommel]

Hallo shmia,

Danke für deine Antwort - ich hatte mich in den Feierabend verabschiedet und komme erst jetzt zum weiteren Testen.

Glücklich macht mich das mit dem PWideChar auch noch nicht so richtig. Vor allem: wenn das schon nicht geht, wie soll das erst mit komplexeren Strukturen enden?

Das Problem ist: wenn ich alles richtig verstanden habe, dann habe ich bereits so ein duales Interface, abgeleitet von IDispatch. Der Code, den Delphi für meine testStr32_TLB.pas erzeugt, unterscheidet sich kaum von dem, den du gepostet hast. Als deutlichen Unterschied sehe ich nur den zwischen "stdcall" und "safecall":

(hier jetzt wieder WideString/BSTR als Rückgabetyp, nicht mehr PWideChar. In VB taucht wieder der Fehler auf)

Delphi-Quellcode:

// *********************************************************************//
// Interface: IStringOps
// Flags:     (4416) Dual OleAutomation Dispatchable
// GUID:      {C97D8342-0B92-42AF-AB10-28A825B221FE}
// *********************************************************************//
  IStringOps = interface(IDispatch)
    ['{C97D8342-0B92-42AF-AB10-28A825B221FE}']
    function ReverseStr(const aInStr: WideString): WideString; stdcall;
    function CountStrLength(const aInStr: WideString): SYSINT; stdcall;
  end;

// *********************************************************************//
// DispIntf:  IStringOpsDisp
// Flags:     (4416) Dual OleAutomation Dispatchable
// GUID:      {C97D8342-0B92-42AF-AB10-28A825B221FE}
// *********************************************************************//
  IStringOpsDisp = dispinterface
    ['{C97D8342-0B92-42AF-AB10-28A825B221FE}']
    function ReverseStr(const aInStr: WideString): WideString; dispid 201;
    function CountStrLength(const aInStr: WideString): SYSINT; dispid 202;
  end;

Du hast zwar geschrieben, dass "safecall" vor allem eine Auswirkung für Exceptions hat, aber könnte das auch was mit den Strings zu tun haben? Wie sage ich Delphi in diesem Typbibliotheks-Editor denn, dass er safecall nutzen soll?

Bis denn
Bommel

[Bbommel]

Hier mal ein neuer Zwischenstand, der mich aber nicht wirklich glücklicher macht:

Was das "safecall" angeht, ist das wohl eher eine Delphi-interne Geschichte, die besonders beim Import fremder ActiveX-DLLs nach Delphi relevant ist - ich suche aber ja den umgekehrten Fall. Das ist zumindest das, was ich zu dem Thema im Netz gefunden habe.

Um mal nicht direkt mit dem "großen" Visual Studio um mich zu schießen, habe ich auch mal eine 64-Bit-DLL erzeugt (und damit auch mal direkt gesehen, das wenigstens das funktioniert) und diese in ein VBScript eingebaut und aufgerufen. Ergebnis ist aber das selbe: Die Funktion, die ein Integer zurückgibt, kann ich problemlos aufrufen, aber den WideString bekomme ich nicht - der ganze Scripting-Host verabschiedet sich dann.

Nächster Ansatz: Anstelle den String direkt zurückzugeben, wird das Ergebnis in einer privaten Variable zwischengespeichert, die über die Property "LastResult" abgefragt werden kann. Funktioniert - so kommt der Text ohne Fehler sowohl bei VB.Net als auch im VBScript an. Aber das ist ja nicht das, was ich will! Es muss doch möglich sein, einen String als Rückgabewert zu haben! Ich habe selber schon (okay, in Delphi) fremde ActiveX-DLLs genutzt, die mir einen String zurückgeben. Und die DLL, die ich letztlich durch eine neue ablösen will, gibt auch die Ergebnisse fleißig als String zurück. Kann doch nicht sein, dass der aufrufende Programmierer jedes Mal dieses "LastResult" aufrufen muss. Irgendwas geht da schief... und ich finde keinen Ansatz...

Zur Verdeutlichung hier mal der Code, der "funktioniert":

Die Unit zur Implementierung:

Delphi-Quellcode:

unit teststr32_impl;

{$WARN SYMBOL_PLATFORM OFF}

interface

uses
  ComObj, ActiveX, TestStr32_TLB, StdVcl;

type
  TStringOps = class(TAutoObject, IStringOps)
  private
    FLastResult: string;
  protected
    function CountStrLength(const aInStr: WideString): SYSINT; stdcall;
    function ReverseStr(const aInStr: WideString): SYSINT; stdcall;
    function Get_LastResult: WideString; safecall;
    procedure Set_LastResult(const Value: WideString); safecall;
  end;

implementation

uses ComServ;

function TStringOps.CountStrLength(const aInStr: WideString): SYSINT;
begin
  Result:=Length(aInStr);
end;

function TStringOps.ReverseStr(const aInStr: WideString): SYSINT;
var i: integer;
    tempStr: string;
begin
  tempStr:='';
  for I := length(aInStr) downto 1 do
    tempStr:=tempStr+aInStr[i];
  FLastResult:=tempStr;
  Result:=0
end;

function TStringOps.Get_LastResult: WideString;
begin
  Result:=FLastResult;
end;

procedure TStringOps.Set_LastResult(const Value: WideString);
begin
  FLastResult:=Value;
end;

initialization
  TAutoObjectFactory.Create(ComServer, TStringOps, Class_StringOps,
    ciMultiInstance, tmApartment);
end.

Und der wesentliche Ausschnitt aus der _TBL.pas sieht so aus:

Delphi-Quellcode:

// *********************************************************************//
// Interface: IStringOps
// Flags:     (4416) Dual OleAutomation Dispatchable
// GUID:      {C97D8342-0B92-42AF-AB10-28A825B221FE}
// *********************************************************************//
  IStringOps = interface(IDispatch)
    ['{C97D8342-0B92-42AF-AB10-28A825B221FE}']
    function ReverseStr(const aInStr: WideString): SYSINT; stdcall;
    function CountStrLength(const aInStr: WideString): SYSINT; stdcall;
    function Get_LastResult: WideString; safecall;
    procedure Set_LastResult(const Value: WideString); safecall;
    property LastResult: WideString read Get_LastResult write Set_LastResult;
  end;

// *********************************************************************//
// DispIntf:  IStringOpsDisp
// Flags:     (4416) Dual OleAutomation Dispatchable
// GUID:      {C97D8342-0B92-42AF-AB10-28A825B221FE}
// *********************************************************************//
  IStringOpsDisp = dispinterface
    ['{C97D8342-0B92-42AF-AB10-28A825B221FE}']
    function ReverseStr(const aInStr: WideString): SYSINT; dispid 201;
    function CountStrLength(const aInStr: WideString): SYSINT; dispid 202;
    property LastResult: WideString dispid 203;
  end;

Und letztlich der Aufruf im Visual Studio:

Code:

Public Class Form1
    Private Sub ButtonReverse_Click(sender As Object, e As EventArgs) Handles ButtonReverse.Click
        Dim testStr As Object
        testStr = CreateObject("TestStr32.StringOps")

        LabelResult.Text = testStr.ReverseStr(TextBoxInput.Text).ToString
        LabelResult2.Text = testStr.LastResult
    End Sub

    Private Sub ButtonLength_Click(sender As Object, e As EventArgs) Handles ButtonLength.Click
        Dim testStr As Object
        testStr = CreateObject("TestStr32.StringOps")

        LabelResult.Text = testStr.CountStrLength(TextBoxInput.Text).ToString
    End Sub
End Class

Ich weiß ja nicht mal, ob ich irgendwas falsch mache oder ob es ein Bug in Delphi ist oder irgendwo an einer COM/Net-Zwischenschicht oder im Visual Studio (letzteres glaube ich nicht, da der gleiche Fehler ja auch im VBScript auftritt).

Wer auch immer Ideen hat, her damit. Werde wohl auch mal im Emba-Forum nachfragen, vielleicht weiß dort ja jemand etwas.

Bis denn
Bommel

[shmia]

Im Anhang habe ich mal mein "ActiveXStarterKit" angehängt.
Programmiert mit Delphi 5.
Es enthält eine Anwendung mit Automatierungsschnittstelle sowie ein VBScript, mit dem die Anwendung angesteuert wird.

Delphi-Quellcode:

IApplication = interface(IDispatch)
    ['{1A8EFC07-D8CF-493C-B544-16080D82EBE6}']
    function  Get_Version: WideString; safecall;
    procedure SendTextMessage(const text: WideString); safecall;
    function  MethodeDieExceptionVerursacht: WideString; safecall;
    function  Get_Caption: WideString; safecall;
    procedure Set_Caption(const Value: WideString); safecall;
    property Version: WideString read Get_Version;
    property Caption: WideString read Get_Caption write Set_Caption;
  end;

Falls ich mal Zeit finde, mache ich noch eine ActiveX DLL hinzu.

[Bbommel]

Vielen Dank für deine Unterstützung. So ganz ist mir aber noch nicht klar, was ich damit machen soll. In Delphi kann ich dein Projekt zwar öffnen und ausführen, aber was kann ich daraus lernen? Wenn ich die .vbs ausführe, bekomme ich einen Fehler ("ActiveX-Komponente kann kein Objekt erstellen"), was ich auch verstehen kann, denn ich habe ja nichts registriert, was VBS kennen könnte.

Sorry, wenn meine Nachfrage etwas "dumm" erscheint, aber nach bald zwei Tagen mit dem Murks dreht sich mir etwas der Kopf.

Du hast die ganzen .pas-Dateien aber manuell erstellt oder hast du dafür einen Assistenten von Delphi genutzt? Denn ich wunder mich immer noch über das "safecall", das (wie du ja oben siehst) Delphi bei mir nur bei den Getter/Setter benutzt und sonst nicht.

Bis denn
Bommel

[shmia]

Zitat von Bbommel:

So ganz ist mir aber noch nicht klar, was ich damit machen soll.

Einfach mal in deiner Umgebung testen; bei mir läuft das Beispiel ohne Probleme.
1.) beiliegende EXE starten (EXE registriert sich selber) und danach Script starten
sollte funktionieren
Damit wäre bewiesen, dass der Windows Scripting Host mit VBScript auf deinem Rechner ohne Problem läuft.
Es wird auch bewiesen, dass Exceptions zurück an das Script geliefert werden.

2.) Projekt mit deinem Compiler übersetzen und Test von 1.) wiederholen
damit wäre bewiesen, dass deine Delphi Umgebung prinzipiell funktionierende ActiveX-Anwendungen erzeugen kann

3.) Anstelle der EXE muss nun im nächsten Test eine ActiveX DLL treten.
Diese wird ebenfalls mit einem (neu zu erstellenden) VBScript getestet

4.) Einbinden in .NET / C# und testen