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

[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

[Bbommel]

Mal ganz vorab: ich habe das Gefühl, das bei diesem ganzen Kram auch die Betriebssystem-Version nicht ganz unwichtig ist. Ich habe Win7, 64-Bit, Delphi 2009, und als zweites Testsystem (wo auch Visual Studio 2011 Beta und die Testversion von XE2 drauf laufen) Win8 Consumer Preview, ebenfalls 64-Bit.

Hm. Also der Reihe nach:

1.: Versuch, die exe direkt auszuführen
Die exe funktioniert leider nicht. Windows meldet sich direkt damit, dass das Programm nicht ausgeführt werden kann. Danach erscheint noch folgende Fehlermeldung:

---------------------------
Anwendungsfehler
---------------------------
Exception EOleSysError in Modul ActiveXStarterKit.exe bei 000453A5.
Fehler beim Zugriff auf OLE-Registrierung.
---------------------------

2.: Neukompilieren der exe mit meinem Delphi 2009
Wenn ich das Projekt in mein Delphi 2009 (also das in meiner Produktiv-Umgebung) lade und compiliere, dann kann ich die exe nachher problemlos starten. Allerdings funktioniert das .vbs noch immer nicht und liefert mir die Meldung:

---------------------------
Windows Script Host
---------------------------
Skript: D:\Eigene Dateien\Borland Studio-Projekte\delphi-praxis\activeXstarterKit\TestScript.vbs
Zeile: 3
Zeichen: 10
Fehler: ActiveX-Komponenten kann kein Objekt erstellen: 'ActiveXStarterKit.Application_'
Code: 800A01AD
Quelle: Laufzeitfehler in Microsoft VBScript
---------------------------

3.: Compilieren als 64-Bit-Exe mit XE2
Um auszuschließen, dass es jetzt irgendwie an 32/64-Bit-Problemen scheitert, habe ich das Ganze noch mal unter XE2 als 64-Bit compiliert, aber das brachte auch keine Besserung. exe läuft, aber vbs sieht sie nicht.

Du meintest, die Bibliothek würde sich selbst registrieren - wo tut sie das denn? Nur, um wenigstens das mal zu verstehen.

Ich glaube aber eigentlich nicht, dass bei mir der Scripting Host defekt ist. Das Problem tritt ja sowohl bei meinem normalen Win7 wie auch bei dem recht frischen Win8-Testsystem auf.

Ich versuche mir mal, ein olles XP zu basteln, vielleicht kommen wir des Rätsels Lösung dann ja näher...

Bis denn
Bommel

[shmia]

Zitat von Bbommel:

Mal ganz vorab: ich habe das Gefühl, das bei diesem ganzen Kram auch die Betriebssystem-Version nicht ganz unwichtig ist. Ich habe Win7, 64-Bit,

Das hast du sicher recht!
Du musst die Testanwendung einmal mit vollen Admin-Rechten starten.
(rechter Mausklick -> Als Administrator starten)
Dabei verankert sie sich in der Registry unter HKEY_LOCAL_Machine.

Falls du die Registrierung wieder loswerden willst das Programm mit dem Parameter /unregserver starten.

Zitat von Bbommel:

Du meintest, die Bibliothek würde sich selbst registrieren - wo tut sie das denn? Nur, um wenigstens das mal zu verstehen.

EXE-Anwendungen registrieren sich selbst bei jedem Start.
Mit dem (Kommandozeilen-)Parameter /regserver führt die Anwendung nur die Registrierung durch und beendet sich sogleich.

DLL und OCX müssen dagegen von Aussen mit dem Tool RegSvr32.exe (bzw. RegSvr64) registriert werden.

[Bbommel]

Hm, ich hatte gedacht, das mit den Admin-Rechten hätte ich schon getestet gehabt... hmpf. Zu viele Tests.

Also noch mal:

1.: Test von deiner exe
Also, ich habe eine Eingabeaufforderung mit Admin-Rechten gestartet und von dieser aus sowohl deine exe gestartet wie auch die vbs-Datei. Scheint zu funktionieren: Ich erhalte zunächst ein Popup...
---------------------------
Version: 1.0 beta Programm:ActiveX Starter Kit
---------------------------
...und im Fenster des Programms erscheinen zwei Zeilen mit einem Gruß des Scripts.

Nur am Ende des Scripts erhalte ich eine Fehlermeldung, schätze aber mal, dass die jetzt nichts mit unserem Problem zu tun hat:
---------------------------
Windows Script Host
---------------------------
Skript: D:\Eigene Dateien\Borland Studio-Projekte\delphi-praxis\activeXstarterKit\TestScript.vbs
Zeile: 11
Zeichen: 1
Fehler: IApplication.GetPath: Invalid Argument
Code: 80040096
Quelle: ActiveXStarterKit.Application_
---------------------------

2.: Compilieren mit D2009
Funktioniert dann jetzt genauso wie 1).

Cool. Vielen Dank schon mal. Das ist immerhin das erste Mal heute, dass ich das Gefühl habe, einen Schritt weiter gekommen zu sein. Dann kann ich ja wenigstens mal mit ein bisschen Optimismus in den Feierabend gehen...

Schönen Abend noch
Bommel

[Bbommel]

Hiho,

hier mal die aktuellen Fortschritte...

Zunächst mal der Link zum selben Thema im Emba-Forum: https://forums.embarcadero.com/threa...70095&tstart=0

Um mal die Ergebnisse von da zusammenzufassen: Dort gab es noch einen Hinweis, dass ich die Funktionen anders deklarieren muss in der IDL-Datei, aus der dann ja letztlich die Typbibliothek entsteht. Es soll nicht der String als Rückgabewert der Funktion genommen werden, sondern HRESULT und dann der eigentliche Rückgabewert in einem out-Parameter erscheinen. Das sieht dann in der ridl-Datei so aus:

Code:

  interface IStringOps: IDispatch
  {
    [id(0x000000C9)]
    HRESULT _stdcall ReverseStr([in] BSTR aInStr, [out, retval] BSTR oResult);
  };

Witzigerweise entsteht dann in den .pas-Dateien von Delphi genau der Code mit einem "safecall", auf den shmia die ganze Zeit hinaus wollte:

So sieht es in der TLB.pas aus:

Delphi-Quellcode:

// *********************************************************************//
// Interface: IStringOps
// Flags:     (4416) Dual OleAutomation Dispatchable
// GUID:      {8A734903-13FF-46BF-BC02-4E596CBE514F}
// *********************************************************************//
  IStringOps = interface(IDispatch)
    ['{8A734903-13FF-46BF-BC02-4E596CBE514F}']
    function ReverseStr(const aInStr: WideString): WideString; safecall;
  end;

// *********************************************************************//
// DispIntf:  IStringOpsDisp
// Flags:     (4416) Dual OleAutomation Dispatchable
// GUID:      {8A734903-13FF-46BF-BC02-4E596CBE514F}
// *********************************************************************//
  IStringOpsDisp = dispinterface
    ['{8A734903-13FF-46BF-BC02-4E596CBE514F}']
    function ReverseStr(const aInStr: WideString): WideString; dispid 201;
  end;

Und so in der Implentierung:

Delphi-Quellcode:

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

implementation

uses ComServ;

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

var i: integer;
    tempStr: string;

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

Wie man sieht, kommt das "HRESULT" hier dann gar nicht mehr vor, stattdessen taucht aber wie gesagt dann plötzlich ein "safecall" auf.

Interessant ist jetzt, dass ich die Funktion in VB.Net nutzen kann, wenn ich sie mit später Bindung aufrufe:

Code:

    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        Dim teststr As Object
        teststr = CreateObject("TestStr32Out.StringOps")
        MessageBox.Show(teststr.ReverseStr("Hallo"))
    End Sub

Das ist ja schon mal fein. Wenn ich die Funktion allerdings über "Verweis hinzufügen..." schon zur Designzeit dem Projekt hinzufügen möchte, dann knallt das ganze Visual Studio - obwohl das vorher, mit den vorigen Tests, wenigstens immer funktioniert hat.

Auch im VBscript funktioniert es nicht:

Code:

dim mystr
set mystr = CreateObject("TestStr32Out.StringOps")
wscript.echo "Hallo = "+mystr.ReverseStr("Hallo")

...führt dazu, dass der Scripting Host sich verabschiedet.

Also - Fortschritte ja, aber auch nur so irgendwie ein bisschen.

Bin gespannt auf weitere Ideen...

Bis denn
Bommel