DLL Exportiert ein Interface mit Strings...

[Mavarik]

Hallo!

Wir alle kennen den Kommentar...

{ Wichtiger Hinweis zur DLL-Speicherverwaltung: ShareMem muss die erste...
Das gilt wahrscheinlich auch für ein Interface, oder?

Delphi-Quellcode:

type 
    IFOO = Interface
     ['{BC0B635C-5296-4316-9559-0E8E9A32D460}']
      Procedure Test(Parameter:String);
    End;

Procedure GetI(out IOUT : IFOO);stdcall;
begin
...
end;

Exports
  GetI;

Mavarik

[Sir Rufo]

Ja, es sein denn du nimmst WideString .

Und alle Methoden des Interfaces sollten auch mit stdcall oder whatever (Calling Convention) gekennzeichnet werden (sonst geht das nur mit Delphi)

[Mavarik]

Zitat von Sir Rufo:

Ja, es sein denn du nimmst WideString .

WideString <> AnsiString... Natürlich, ich meine im Bezug auf die Übergabe...?

[Sir Rufo]

Zitat von Mavarik:

Zitat von Sir Rufo:

Ja, es sein denn du nimmst WideString .

WideString <> AnsiString... Natürlich, ich meine im Bezug auf die Übergabe...?

Ähm, welche Übergabe denn jetzt? Und welche Rolle spielt das?

Wenn du einen Typen verwendest, der nur von Delphi gemanaged wird (z.B. string ) dann musst du ShareMem verwenden.

Nimmst du stattdessen einen Typen der nicht von Delphi gemanaged wird (statt string eben WideString ) dann brauchst du eben kein ShareMem .

[himitsu]

String, AnsiString und UnicodeString sind Typen, welche über den Speichermanager des Delphi verwaltet werden.
WideString wird über die OleAut32.dll verwaltet.
Und der ShortString ist ein Record und wird von keinem Speichermanager verwaltet, da er meistens direkt auf dem Stack liegt.

Alles was über den Delphi-Speichermanager verwaltet wird, muß z.B. via ShareMem verbunden werden.
Und wenn man z.B. Klassen übergeben will, oder andersweilig Typen teilt, dann muß auch noch die RTTI geshared werden -> BPLs.

[Mavarik]

OK Verstanden...

Habe gerade ein Testprojekt für die DLL geschrieben und habe in meinen Interface eine Funktion die einen String zurück gibt.

Test funktioniert... OHNE SHAREMEM und mit "normalen" String typen.

Zufall? Oder habe ich doch noch etwas nicht verstanden...

Mavarik

[himitsu]

Geplanter Zufall.

Probleme gibt es vorallem dann, wenn die Stringreferenzen auf der "falschen" Seite verändert, kopiert oder längere Zeit gespeichert werden.


Beispiel:

Erzeug dir einen String, z.B. über IntToStr (Achtung, es darf keine Konstante sein),
übergib ihn einer Interface-Methode und speichere ihn auf der anderen Seite in einer globalen Variable
und nun beende dein Programm oder entlade zumindestens die DLL.

[Sir Rufo]

Vor allem zwischen einer Delphi-erzeugten DLL und einer Delphi-Anwendung ticken auch die Uhren "synchroner" und trotz "nicht korrekter" Implementierung der DLL funktioniert es trotzdem irgendwie (mehr durch Zufall).

Sobald aber eine nicht Delphi-Anwendung diese DLL benutzt, dann rappelt es im Karton.

[Mavarik]

Zitat von Sir Rufo:

Vor allem zwischen einer Delphi-erzeugten DLL und einer Delphi-Anwendung ticken auch die Uhren "synchroner" und trotz "nicht korrekter" Implementierung der DLL funktioniert es trotzdem irgendwie (mehr durch Zufall).

Sobald aber eine nicht Delphi-Anwendung diese DLL benutzt, dann rappelt es im Karton.

OK...
Die Frage ist dann unter welchen Umständen kann man das so machen...

Ich muss eine Unit von einem Dritthertseller (nur DCU vorhanden) in eine DLL Kapseln, damit ich diese auch mit zukünftigen Delphi Version benutzen kann.

Beispiel:

Delphi-Quellcode:

Bla.SavetoFile(Filename); // String übergeben
S := Bla.GetStr(100);             // String zurück erhalten

Also eigentlich immer nur Strings mal eben weiterreichen, verarbeiten und zurück geben.

Kann man das "Riskieren" oder doch lieber auf WideString gehen?

Mavarik

[Sir Rufo]

Hauptproblem wird wohl sein, dass die DCU nicht für Unicode funktioniert.

Wenn du die Definition der Klasse kennst, dann erstelle dir diese Klasse neu (für die neuen Versionen).

Die Klasse selber holt sich eine Interface-Instanz von der DLL und reicht alle Anfragen darüber an die DLL durch und holt auch die Daten darüber zurück.

Am sinnvollsten wäre auch die Verwendung von PAnsiChar statt WideString und die neue Klasse benutzt als Parameter AnsiString statt string .