Hilfe mit Delphi [idhttp.get error]

[Sir Rufo]

Generell sollte man sowas etwas mehr trennen:

Delphi-Quellcode:

procedure TDatMod.DoStoreBlobToFile(Feld: TField; Datei: String);
Var
  S : TStream;
  FileS : TFileStream;
begin
  If Not Feld.IsBlob Then
    raise Exception.Create( 'Das angegebene Feld ist kein Blobfeld.' );

  If Feld.IsNull Then
    raise Exception.Create( 'Im angegebenen Blobfeld des aktuellen Records befinden sich keine Daten.' );

  S := nil;
  FileS := nil;
  Try
    S := Feld.DataSet.CreateBlobStream(Feld, bmRead);
    FileS := TFileStream.Create(Datei, fmCreate);
    FileS.CopyFrom(S, S.Size );
  Finally
    S.Free;
    FileS.Free;
  End;
  if not FileExists( Datei ) then
    raise Exception.CreateFmt( 'Eigentlich sollte die Datei "%s" jetzt vorhanden sein?', [Datei] );
end; 

Function TDatMod.BlobFeldInDatei(Feld: TField; Datei: String): Boolean;
begin
  Result := True;
  try
    DoStoreBlobToFile( Feld, Datei );
  except
    on E: Exception do
    begin
      GLD.FehlerText := E.Message;
      Result := False;
    end;
  end;
end;

Schon wird es kürzer und knackiger, obwohl es jetzt zwei Methoden sind

[Perlsau]

Zitat von himitsu:

Jupp, aber dann vor dem Try natürlich nicht das :=nil vergessen, denn sonst knallt auch noch das Free, da nicht initialisiert, wenn es im Create knallte.

Echt jetzt? Aprilscherz? In der Unit System wird doch bereits auf Nil geprüft und Destroy nur ausgeführt, wenn nicht Nil:

Delphi-Quellcode:

procedure TObject.Free;
begin
// under ARC, this method isn't actually called since the compiler translates
// the call to be a mere nil assignment to the instance variable, which then calls _InstClear
{$IFNDEF AUTOREFCOUNT}
  if Self <> nil then
    Destroy;
{$ENDIF}
end;

Und wird eine Objektvariable nicht automatisch bei der Deklaration mit Nil initialisiert? Oder muß ich das dann auch bereits vor dem ersten Try machen?
So dürfte es dann wohl hinhauen:

Delphi-Quellcode:

Function TDatMod.BlobFeldInDatei(Feld: TField; Datei: String): Boolean;
Var
  S     : TStream;
  FileS : TFileStream;

begin
  Result := False;

  ...

  Try
    S     := Feld.DataSet.CreateBlobStream(Feld, bmRead);
    FileS := TFileStream.Create(Datei, fmCreate);
    Try
      FileS.CopyFrom(S, S.Size);
      Result := True;
    Except
      on e:exception Do GLD.FehlerText := 'Fehler bei BlobToFile: ' + e.Message;
    End;
  Finally
    S.Free;
    FileS.Free;
  End;
end;

[himitsu]

Ja, Free prüft auf nil, aber lokale Variablen sind nicht unbedingt automatisch mit nil initialisiert.
Aber das sollte dir der Compiler auch sagen.

Entweder es knallt nicht, weil der Zeiger zufällig auf "irgendein" Objekt zeigt und es dann freigegeben wird, oder es knallt hoffentlich.

[Perlsau]

Jetzt ist der Groschen auch bei mir gefallen:

UnitData.pas(331,1): warning W1036: W1036 Variable 'S' ist möglicherweise nicht initialisiert worden
UnitData.pas(331,1): warning W1036: W1036 Variable 'FileS' ist möglicherweise nicht initialisiert worden

Okay, dann füge ich die Nilsetzung vor dem ersten Try ein und gut ist

Zitat von himitsu:

Entweder es knallt nicht, weil der Zeiger zufällig auf "irgendein" Objekt zeigt und es dann freigegeben wird, oder es knallt hoffentlich.

Da hat noch nie was geknallt, hätte aber können
Jetzt ist ja alles wieder gut

[Bjoerk]

Zitat von Perlsau:

Echt jetzt? Aprilscherz?

Wenn  S := Feld.DataSet.CreateBlobStream(Feld, bmRead); scheitert geht er nach except und danach nach finaly. Dort veursacht FileS.Free ebenfalls eine Exception falls nicht zufällig mit nil initiiert. Deshalb hat Sir Rufo FileS erst mal nil gesetzt. Alternativ kann man auch 2 try finally Blöcke nehmen.

[himitsu]

Mehrere Frees in einem Finaly geht natürlich nur, wenn alle Frees selber keine Exceptions erzeugen können (also jeweils die Free vor einem anderen Free ... sozusagen der Letzte darf knallen, wenn er will)
Wenn das nicht nahezu sichergestellt ist, dann entweder jeder sein eigenes Try-Finally, oder ein Try-Finally/Except im Finally.

Fälle, wonach das Programm dann eh komplett im Arsch ist und sowieso beendet werden muß, "kann" man weniger sorgsam sichern.

[Sir Rufo]

Zitat von Bjoerk:

Zitat von Perlsau:

Echt jetzt? Aprilscherz?

Wenn  S := Feld.DataSet.CreateBlobStream(Feld, bmRead); scheitert geht er nach except und danach nach finaly. Dort veursacht FileS.Free ebenfalls eine Exception falls nicht zufällig mit nil initiiert. Deshalb hat Sir Rufo FileS erst mal nil gesetzt. Alternativ kann man auch 2 try finally Blöcke nehmen.

Jupp, allerdings ist es nicht ratsam (wegen der Lesbarkeit) für jeden und alles einen eigenen try finally Block zu nehmen, denn dann sieht man irgendwann den Wald vor lauter Bäumen (try und Einrückungen) nicht mehr

Und schreibfaul bin ich auch noch

[RooT314]

Hallo Leute !

Erstmal danke für eure zahlreichen Antwroten !

Ich werde mir die gelisteten Tipps von himitsu raussuchen und so gut wie es geht beheben !

Jedoch habe ich als Anfänger gerade einmal die hälfte Verstanden

Ich werde im Verlaufe des Tages Updates posten

@himitsu : Sie meinten das dir kein path sein soll ? Was soll den Dir sonst sein ? versteh ich nicht ganz Und das mit dem TOpenDialog habe auch nach dem Lesen im Wiki nicht verstanden

Gruß RooT

[Perlsau]

Himitsu meinte, daß du für das Abspeichern des des TFileStreams eine Datei und nicht nur ein Verzeichnis benötigst:

Nicht C:\MeinOrdner\
sondern
C:\MeinOrdner\Datei.html

[himitsu]

Path: C:\Programme\ = etwas in dem Verzeichnis (Pfadangabe für eine Datei/Verzeichnis zum Anhängen, also mit abschließendem PathDelimiter)
Directory, bzw. Pathname: C:\Programme = das Verzeichnis selber (der Verzeichnisname, also ohne abschließenden PathDelimiter)
Filepath: C:\Programme\Meine.exe = eine bestimmte Datei (inkl. Pfad)
Filename: Meine.exe = irgendeine Datei (ohne Pfad)

SaveToFile benötigt einen FileName, aber idealer Weise besser einen kompletten FilePath
Du schreibst aber erstmal einem Path in die Variable und der Auswahldialog wählt dann nur ein Verzeichnis (Dir).



PS: '\', oder PathDelim, TPath.DirectorySeparatorChar oder besser mit TPath.Combine .