Zitat:
Ich denke aber das es vorher auch schon ne
exception gab,...
Nicht eine
Exception, sondern ein Free'n des Streams. Das Free'n des Filestreams in der TIdMessage.SaveToFile-Methode wäre danach also schon das zweite Mal hintereinander und würde demzufolge dann diese
Exception verursachen.
Der eigentliche Fehler liegt aber noch eines tiefer, nämlich an LIOHS, diesem TIdIOHandlerStream, mittels dem diese IOAktion da abgewickelt wird. Da es bei diesen IORoutinen gelegentlich üblich ist, dass an sie übergebene Streams dann von ihnen auch gleich schon intern mit gefree't werden, wäre das also auch in unserem Falle der hier gesuchte Fehler. Und siehe da, beim Erzeugen von LIOHS wird im TIdIOHandlerStream-Konstruktor auch ein diesbezüglich so lautendes Feld 'FFreeStreams' auf TRUE gesetzt (welches also wie gesagt jetzt (unten, nach finally: FreeAndNil(LIOHS)) dafür sorgt, dass unser Stream fälschlicherweise schon intern gefreet wird). Wenn man also in der Zeile unter dem Konstruktor-Aufruf (innerhalb von TIdMessage.SaveToStream) dieses auf TRUE-Setzen gleich wieder rückgängig macht, und zwar mittels der dazugehörenden Property 'FreeStreams', dann funzt es danach auch ordnungsgemäß.
Code:
constructor TIdIOHandlerStream.Create(AOwner: TComponent);
begin
inherited;
FFreeStreams := True; // <===== verursacht bei uns nacher (indirekt) die
Exception
end;
procedure TIdMessage.SaveToStream(AStream: TStream;
const AHeadersOnly: Boolean = False);
var
LMsgClient: TIdMessageClient;
LIOHS: TIdIOHandlerStream;
begin
LMsgClient := TIdMessageClient.Create(nil);
try
LIOHS := TIdIOHandlerStream.Create(nil);
LIOHS.FreeStreams := false; // ====> wird fälschlicherweise im Creater darüber TRUE; ergo:...
(habe ich irgendwann/wo auch mal so ähnlich zur Kenntnis genommen ...handelt sich dabei wohl tatsächlich noch um einen echten Bug.)