TPath.Combine, TPath.GetTempPath threadsicher?

[zeras]

Ich nutzte folgenden Code, um eine Resource in das Filesystem zu schreiben.
Da alles im Hintergrund laufen soll, habe ich das in einen Thread gepackt.
Leider bricht mir dann mein Tablet mit Meldung "Anwendung wurde beendet" nach einiger Zeit ab.
Ich habe dann testweise TPath.GetTempPath gegen den Pfad als String getauscht und nun scheint es zu laufen.
Ist denn TPath eine visuelle Komponente, oder wie kann man sich das Problem erklären?

Delphi-Quellcode:

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

begin
  Result := False;

  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;
end;

[himitsu]

TPath.GetTempPath selber ist threadsave, aber wie es mit GetTempPath und GetLongPathName aussieht, kann ich nicht sagen.

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? :stupid:



Und was sind das für Threads und wie behandelst du die Exceptions darin?


PS:
Warum ist fName ein VAR-Parameter?
Und Result=False wird es niemals geben.

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1284870)

PS:
Warum ist fName ein VAR-Parameter?
Und Result=False wird es niemals geben.

GlaskugelMode.Active := true;

Damit man außen in einem Log FName ausgeben kann.
Klar gibt es Result=false... bei einer Exception.

GlaskugelMode.Active := false;

[zeras]

Zitat:

Zitat von himitsu (Beitrag 1284870)

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? :stupid:

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:

Zitat von Mavarik (Beitrag 1284891)

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:

Zitat von Mavarik (Beitrag 1284891)

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:

Zitat von zeras (Beitrag 1284893)

Zitat:

Zitat von Mavarik (Beitrag 1284891)

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:

Zitat von zeras (Beitrag 1284893)

Zitat:

Zitat von Mavarik (Beitrag 1284891)

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.

[himitsu]

@GlaskugelMode:

Wie gerade schon jemand sagte:

Es gibt entweder True oder eine Exception.
Bei einer Exception wird mit der Panzerfaust reingeschossen, man fliegt an der Result-Rückgabe vorbei, direkt zum nächsten Try-Except und es gibt somit kein Result.

Im Prinzip funktioniert die gezeigte Lösung, auch wenn es nicht wirklich "optiomal" ist, wenn die Exception so abgefangen, dann einfach verworfen und in einen nichtssagenden Boolean verwandelt wird.

* Exception abfangen und als Boolean zurückgeben, dann aber bitte mit Zusatzinfox ala GetLastError
* oder als Fehlercode zurückgeben (die Fehler/Exception sprechend umwandeln)
* oder eben ohne Fehlerrückgabe-Wert und dafür mit Exceptions arbeiten

[add]
Lach .... die RedBox lebt mal wieder :thumb:

[Mavarik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1284897)

Eben nicht!

eben doch :stupid:
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;

[zeras]

Ich habe nun eure Meinungen verstanden und etwas dazugelernt.
Aber was hat es mit dem roten Kasten auf sich?

[Mavarik]

Zitat:

Zitat von zeras (Beitrag 1284902)

Aber was hat es mit dem roten Kasten auf sich?

Immer wenn einer schneller war mit seinem Posting... Während Du noch geschrieben hast.
(Na, wer hatte Ihn dieses mal?)


So wäre wahrscheinlich die bevorzugte Lösung:

Delphi-Quellcode:

Function CopyStream2File(ResourceID: string): String;
var
    ResStream: TResourceStream;
begin
    ResStream := TResourceStream.Create(HInstance, ResourceID, RT_RCDATA);
    try
      //MP3 File aus Resource laden und in Filesystem ablegen
      Result := TPath.Combine(TPath.GetTempPath, 'tmp.mp3');

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


var
   FName : String;
begin
   try
     FName := CopyStream2File('42');
     Play(FName);
   except
   end;
end;

Auch wenn ich es immer so mache wie in meinen 1. Posting...

Mavarik