TPath.Combine, TPath.GetTempPath threadsicher?

[zeras]

Zitat von himitsu:

Aber warum kommt keiner auf die Idee diesen Wert in einer globalen Veriable zwischenzuspeichern
oder kann es denn passieren, daß sich dieser Wert jemals ändern wird?

Das war eine Funktion, die ich erst mal aus einem Beispiel genommen hatte. Die Idee, den Wert in eine globalen Variable zu speichern, ist gar nicht so schlecht, aber ich wollte erst mal das Beispiel zum Fliegen bringen. Danach wäre ich (oder vielleicht auch nicht) auf die Idee gekommen, das ganze zu optimieren.

Zitat von Mavarik:

Damit man außen in einem Log FName ausgeben kann.

Nicht ganz, aber ich möchte die Datei dann über den Mediaplayer abspielen und so brauche ich den Namen mit Pfadangabe.

Zitat von Mavarik:

Klar gibt es Result=false... bei einer Exception.

So ganz falsch ist doch dieser Teil nicht oder? Wenn ich den Stream nicht speichern kann, ist die Abfrage false und es wird dann in der aufrufenden Funktion nicht weiter gemacht. Es nützt ja nichts, wenn keine MP3 Datei da ist, dass ich dann den Mediaplayer anwerfe.

[Mavarik]

Zitat von zeras:

Zitat von Mavarik:

Klar gibt es Result=false... bei einer Exception.

So ganz falsch ist doch dieser Teil nicht oder? Wenn ich den Stream nicht speichern kann, ist die Abfrage false und es wird dann in der aufrufenden Funktion nicht weiter gemacht. Es nützt ja nichts, wenn keine MP3 Datei da ist, dass ich dann den Mediaplayer anwerfe.

Nein, das ist richtig, aber ein Try Finally fängt keine Exception ab...
Also könntest Du außen die Exception abfangen und Result weg lassen oder must noch ein try except drum setzen.

Mavarik

[Uwe Raabe]

Zitat von zeras:

Zitat von Mavarik:

Klar gibt es Result=false... bei einer Exception.

So ganz falsch ist doch dieser Teil nicht oder? Wenn ich den Stream nicht speichern kann, ist die Abfrage false und es wird dann in der aufrufenden Funktion nicht weiter gemacht. Es nützt ja nichts, wenn keine MP3 Datei da ist, dass ich dann den Mediaplayer anwerfe.

Eben nicht! Da die Exception innerhalb der Function nicht durch ein except abgefangen wird, gelangt sie an den nächsthöheren try-finally bzw. try-except Block. Damit wird die Auswertung der Funktionsrückgabe gar nicht ausgeführt.

Soll also bei einer auftretenden Exception lediglich ein false zurückgegeben werden, würde sich dieses Konstrukt anbieten:

Delphi-Quellcode:

//kopiert einen Song als Resource in eine Datei
Function CopyStream2File(ResourceID: string; var fName: String): boolean;
var
  ResStream: TResourceStream;

begin
  try
    ResStream := TResourceStream.Create(HInstance, ResourceID, RT_RCDATA);

    try

      //MP3 File aus Resource laden und in Filesystem ablegen
      fName := TPath.Combine(TPath.GetTempPath, 'tmp.mp3');

      ResStream.Position := 0;
      ResStream.SaveToFile(fName);
      Result := True;
    finally
      ResStream.Free;
    end;
  except
    result := false;
  end;
end;

Roter Kasten: Wie Mavarik korrekt bemerkt.

[Mavarik]

Zitat von Uwe Raabe:

Eben nicht!

eben doch
Zum Beispiel so:

Delphi-Quellcode:

Function CopyStream2File(ResourceID: string; var fName: String): boolean;
var
   ResStream: TResourceStream;

begin
  Result := False;
   
  try 

   ResStream := TResourceStream.Create(HInstance, ResourceID, RT_RCDATA);

   try

     //MP3 File aus Resource laden und in Filesystem ablegen
     fName := TPath.Combine(TPath.GetTempPath, 'tmp.mp3');
// fName := TPath.Combine('/data/data/com.embarcadero.Meinprogram/files/', 'tmp.mp3');

     ResStream.Position := 0;
     ResStream.SaveToFile(fName);
     Result := True;
   finally
     ResStream.Free;
   end;
  except
  end
end;

oder

Delphi-Quellcode:

var
  FName  : String;
  error : boolean;
begin
  ...
  try
    error := CopyStream2File('42',FName);
  except
    MyError('Fehler...');
  end;

  if not Error then
    Play(FName)
  
end;