Interfaces, DLLs und Strings: Sharemem benötigt?

[phreax]

Hallo zusammen,
Ich hoffe ich habe die richtige Sparte erwischt.

Ich möchte Mittels eines Interfaces Datenstrukturen zwischen meiner Anwendung und einer Dll tauschen.

folgendes Interface:

Delphi-Quellcode:

type IMyException = interface
  ['{682DE719-6008-404D-8921-D648F35FC1D7}']
  function Msg: String; stdcall;
  function ErrorClassName: String; stdcall;
  function GetProcName: String;
  procedure SetProcName(Value: String);
  property ProcName: String read GetProcName write SetProcName;
end;

Die Anwendung soll nun darauf zugreifen können:

Delphi-Quellcode:

function GetLastError: IMyException;  stdcall; external 'TestPlugin';
//...
ShowMessage(GetLastError.Msg);

Und in der DLL

Delphi-Quellcode:

var fLastError: IMyException;
//...
function GetLastError: IMyException;  stdcall;
begin
  Result := fLastError;
end;
//...
  except
    on E: Exception do
      begin
        Result := False;
        fLastError := TMyException.Create(E);
      end;
  end;

Geht das jetzt ohne Sharemem? Die Interfacestrukturen enthalten ja Funktionen die Strings zurückgeben...
Oder ist das ganze durch die Interfaces so gekapselt, das die Memorymanager von DLL und Anwendung nicht ins Gehege kommen?
Bei Tests hat es jedenfalls funktioniert, aber es kann ja sein das ich mit dem Feuer spiele

Grüße phreax

[Elvis]

Du kannst auf WideString ausweichen, um das Speichermanagement auf Windows abzuschieben. Dadurch wäre ShareMem nicht mehr notwendig und auch die Bindung an Delphi wäre nicht mehr vorhanden.
Du kannst natürlich auch weiterhin ShareMem nehmen (oder in Echse & DLL FastMM4 als erste Unit benutzen).

[phreax]

Das mit Widestring hört sich gut an, denn ich will es vermeiden eine weitere DLL mit der Exe ausliefern zu müssen...

Aber wenn ich einfach alle Strings einfach durch WideStrings ersetze, bekomme ich interessante Strings zurück:
Eine Test-Fehlermeldung:

Zitat:

---------------------------
Pluginmain
---------------------------
Datei C:\Dokumente und Einstellungen\Eigene Dateien\???????????????????????????????? kann nicht geöffnet werden. Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch
---------------------------
OK
---------------------------

Woher kann denn soetwas kommen?

Grüße phreax

[Luckie]

entweder gibst du den WideString mit WideString-Komponenten aus oder du castest ihn vor der Ausgabe nach String.

[Elvis]

Zitat von Luckie:

entweder gibst du den WideString mit WideString-Komponenten aus oder du castest ihn vor der Ausgabe nach String.

Genau, man kann den UCS2-String aus einem WideString nicht immer einfach so indirekt als AnsiString nehmen. ein expliziter Cast ist oft genug, ansonsten gibt es die OleStr-blabla-Konvertierungen. (wirklich immer auf Unicode zu setzen macht aber IMO mehr Sinn.)

[phreax]

Danke für die schnellen Antworten
Doch egal, ob
OleStrToString(PWideChar(GetLastError.Msg)); oder
ShowMessage(AnsiString(GetLastError.Msg)); Das Ergebnis bleibt immer wie oben...
Zugewiesen wurde mit:

Delphi-Quellcode:

constructor TMyException.Create(E: Exception);
begin
  inherited Create();
  fProcName := '';
  fMessage := WideString(E.Message);
  fClassName := WideString(E.ClassName);
end;

Ich hoffe es gibt auch dafür eine Lösung...

grüße phreax

[Elvis]

Öhm, kannst du mal bitte das Ganze mal so vereinfachen, dass wir es hier in unseren Delphis reproduzieren können?
Ich selbst bin schon ein "wenig" raus aus Delphi, es "klingelt"also gerade nicht bei mir...

[phreax]

Der Fehler scheint nur im Zusammenhang meiner Anwendung aufzutreten...
Ich kann es also leider nicht aus dem Zusammenhang nehmen.
Daher die ganze "Proof of Concept" Anwendung im Anhang.
Einfach eine Datei öffnen, die nicht existiert und es kommt eine Fehlermeldung

Grüße phreax

[generic]

phreax nutzt turbodelphi!
ich meine der fastmm ist dort der speichermanager, somit müsste das doch ohne sharemem bzw borlandmm gehen?!

[Luckie]

Bei SavePerson kommt überhaupt kein gültiger Dateiname an, sondern nur Fragezeichen. Da stimmt schon was nicht. Die Ausgabe ist wahrscheinlich korrekt.