DLL Exportiert ein Interface mit Strings...

[Mavarik]

Zitat von 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 .

Unicode ist kein Thema... Geht von XE5 -> XE6. Die DLL soll aber auch mit Delphi 2007 Funktionieren..

[himitsu]

Zitat von Sir Rufo:

und die neue Klasse benutzt als Parameter AnsiString statt string .

Achtung: AnsiString ist nicht gleich AnsiString.

Mit Umstellung auf Unicode wurde das AnsiString erweitert und ist daher nicht mehr wirkltich kompatibel zueinander.


Die DLL mit einer alten Delphiversion kompiliert, kommt mit der alten DCU klar, aber das Interface, welches die DLL veröffentlicht sollte daher maximal WideString oder PAnsiChar verwenden.

[Mavarik]

OK..

Was ist mit einem TStream?

Mavarik

[himitsu]

Das ist eine Klasse? Siehe oben bei RTTI.
Und TMemoryStream, TStringStream, TBytesStream usw. geht auch wieder auf SharedMem hinaus.

Es gibt allerdings den IStream, aber der ist nicht kompatibel mit TStream's, wobei es dafür aber eine Wrapper-Klasse gibt.

[Mavarik]

Zitat von himitsu:

Es gibt allerdings den IStream, aber der ist nicht kompatibel mit TStream's, wobei es dafür aber eine Wrapper-Klasse gibt.

Wrapper-Klasse?

[himitsu]

TStreamAdapter

[Mavarik]

Zitat von Mavarik:

Wrapper-Klasse?

OK. War vielleicht ein bisschen kurz...

Zitat von himitsu:

TStreamAdapter

Also habe ich keine bessere Antwort verdient...
ok dann nochmal:

Danke für die Info zum IStream. Die Wrapper Klasse hier für habe ich gefunden. Hast Du ein Stück Beispiel-Code, wie man das
für eine bidirektionale Übergabe an eine DLL verwenden muss?

Grüsse Mavarik

[himitsu]

Eigentlich Recht einfach.

- TStream-Nachfolger können nicht direkt an IStream übergeben werden.
> TStream ist halt ein Delphi-Typ und ISteam kommt irgendwo aus dem OLE32, oder so.
> Gut, man hätte natürlich auf die Idee kommen können, die Methoden von IStream direkt in TStream einzubauen, damit man auch direkt darüber das IStream hätte supporten können, aber so schlau war wohl Keiner.

Man nimmt also irgendeinen Stream, packt ihn in den TStreamAdapter und überlegt sich dann noch, wer für die Freigabe sorgen soll.

Delphi-Quellcode:

type
  IMyIntf = interface
    function GetStream: IStream;
    procedure PutStream(S: IStream);
  end;

function TMyClass.GetStream: IStream;
begin
  Result := TStreamAdapter.Create(FStream, soReference);
end;

function TMyClass.GetStream: IStream;
begin
  Result := TStreamAdapter.Create(TFileStream.Create('Test.dat', 0), soOwned);
end;


begin
  MyIntf.PutStream(TStreamAdapter.Create(FStream, soReference));
end;

begin
  MyIntf.PutStream(TStreamAdapter.Create(TFileStream.Create('Test.dat', 0), soOwned));
end;

[Mavarik]

Zitat von himitsu:

Eigentlich Recht einfach.

Man nimmt also irgendeinen Stream, packt ihn in den TStreamAdapter und überlegt sich dann noch, wer für die Freigabe sorgen soll.

OK

Delphi-Quellcode:

Procedure Machwas(A,B:TStream);
var
  StreamA,
  StreamB : IStream;
begin
  StreamA := TStreamAdapter.Create(A,soReference);
  StreamB := TStreamAdapter.Create(B,soReference);
  DLL_MachWas(StreamA,StreamB);  // Soweit richtig?
  // Und dann? 
end;

Wenn die DLL_MachWas mit den Streams arbeitet? Wie kommt der Inhalt wieder zurück in A & B
oder arbeitet die DLL dann auf A & B oder einer Kopie?

Mavarik

[himitsu]

Das bleibt die ganze Zeit da drin.

Der Stream-Adapter leitert nur alle Zugriffe auf die TStream-Klasse um, welche über seine Methoden gemacht werden.