Hilfe mit Delphi [idhttp.get error]

[Perlsau]

Zitat von bcvs:

Ich sehe nicht, wo da irgendetwas gespeichert wird. Du liest den Inhalt einer Webseite in einen Stream und gibst den gleich wieder frei. Dazwischen müsste der Stream seinen Inhalt aber erstmal noch speichern (s. Write oder WriteBuffer).

Lies doch erstmal den Text der Online-Hilfe zu TFileStream.Create, bevor du da was behauptest:
fmCreate – Erstellt eine Datei mit dem angegebenen Namen. Ist eine Datei mit diesem Namen bereits vorhanden, wird die Datei zum Schreiben geöffnet.
Das heißt: In dem Moment, in dem du in einen geöffneten Filestream was reinschreibst, wird das auf Platte geschrieben. Ich mach das seit Jahr und Tag mit meiner Blob-To-File-Funktion ganz genau so:

Delphi-Quellcode:

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

begin
  Result := False;

  If Not Feld.IsBlob Then
  Begin
    GLD.Fehlertext := 'Das angegebene Feld ist kein Blobfeld.';
    Exit;
  End;

  If Feld.IsNull Then
  Begin
    GLD.Fehlertext := 'Im angegebenen Blobfeld des aktuellen Records befinden sich keine Daten.';
    Exit;
  End;

  S     := Feld.DataSet.CreateBlobStream(Feld, bmRead);
  FileS := TFileStream.Create(Datei, fmCreate);

  Try
    Try
      FileS.CopyFrom(S, S.Size);
      Result := FileExists(Datei);
    Except
      on e:exception Do
      Begin
        GLD.FehlerText := 'Fehler bei BlobToFile: ' + e.Message;
        Result := False;
      End;
    End;
  Finally
    S.Free;
    FileS.Free;
  End;
end;

Zitat von bcvs:

Außerdem gibst du dem Stream beim create lediglich ein Verzeichnis an und keinen vollständigen Dateinamen.

Das dürfte wohl eher die Fehlerursache sein ...

[bcvs]

Zitat von Perlsau:

fmCreate – Erstellt eine Datei mit dem angegebenen Namen. Ist eine Datei mit diesem Namen bereits vorhanden, wird die Datei zum Schreiben geöffnet.
Das heißt: In dem Moment, in dem du in einen geöffneten Filestream was reinschreibst, wird das auf Platte geschrieben.

OK, dass das so funktioniert, wusste ich nicht, gebe ich zu. Aber aus der Hilfe lese ich das auch nicht. Da steht nur, dass die Datei zum Schreiben geöffnet wird, und nicht das da auch automatisch was reingeschreiben wird, wenn man in den Stream was reinschreibt.

[Luckie]

@Perlsau: Nur im Unterschied zum Threadersteller schreibst du auch was rein FileS.CopyFrom(S, S.Size);

Delphi-Quellcode:

 edit1.Text := (dir);
...
...
...
ResponseStream := TFileStream.Create(Edit1.Text, fmCreate);

Jetzt rate mal wie die Datei heißt und wo sie liegt?

Ausgewählte Verzeichnis: c:\ddd\eee -> Dateiname eee im Verzeichnis c:\ddd. Ich glaube kaum, dass das funktionieren wird.

[Perlsau]

Zitat von bcvs:

OK, dass das so funktioniert, wusste ich nicht, gebe ich zu.

Tja, man lernt nie aus, das gilt für mich ebenso

Zitat von bcvs:

Aber aus der Hilfe lese ich das auch nicht.

Und wo hast du das mit dem WriteBuffer gelesen? Etwa in der Online-Hilfe zu TFileStream?

Zitat von bcvs:

Da steht nur, dass die Datei zum Schreiben geöffnet wird, und nicht das da auch automatisch was reingeschreiben wird, wenn man in den Stream was reinschreibt.

Zum Schreiben geöffnet heißt, sie wird erstellt und wartet darauf, daß geschrieben wird. Wie befüllt man ein geöffnetes Gefäß? Indem man was reingießt? Und wie schreibt man in einen Filestream? Indem man was reinkopiert? Also für mich ist der Text in der OH eindeutig.

Man sollte hier wirklich nichts behaupten, das man nicht zuvor überprüft hat, nur um sich hervorzutun mit einem "ich weiß auch was" und sich dann doch zu blamieren

Übrigens kann man im Codebeispiel zu TFileStream.Create genau diese Vorgehensweise finden.

Zitat von Luckie:

@Perlsau: Nur im Unterschied zum Threadersteller schreibst du auch was rein FileS.CopyFrom(S, S.Size);

Und macht das der TE mit idHTTP1.Get(url, ResponseStream); etwa nicht? Was macht die Get-Version mit String als Var-Parameter? Richtig, das Resultat wird im String gespeichert. Warum sollte es bei einem Stream als Ziel-Behälter dann anders sein?

AResponseContent is the TStream instance that is the destination for data retrieved from the specified URL. For example: AHttp.Get(AUrl, AResponseContent)

[Luckie]

Ok, überlesen. Aber letztendlcih wird es daran scheitern dass ein Verzeichnis übergeben wird und kein Dateiname.

[himitsu]

Noch besser, das "dir" ist erstmal ein "path", denn dir := ExtractFilePath(Application.ExeName); , aber hier passt Vieles nicht so ganz.

• erst wird in "dir" ein Pfad "path" reingeschrieben ( C:\dir\ )
• dann noch der falsche Dialogtext "Bitte ein Verzeichnis auswählen" > Ergibt ein "dir" ( C:\dir\dir2 ), aber nur wenn man den Editinhalt ändert und nicht so belässt
• Bezogen auf SelectDirectory stimmt der Text zwar, aber in "dir" Edit1 (echt blöde Name) soll doch ein Dateiname (samt path) rein ... warum dann kein TOpenDialog?
• und zum Schluß wird das Verzeichnis "dir" auch noch direkt als Dateiname "file" verwendet ( C:\dir\file )
• wenn wirklich ein Vereichnis (dir oder path) in "dir" und Edit1 rein soll, dann muß das eben bei TFileStream um den Dateinamen ergänzt werden

PS: @BlobFeldInDatei
Result := FileExists(Datei); ist etwas sinnlos nutzlos, denn es muß zwangsläufig immer True zurückgeben.
Entweder knallte das TFileStream.Create und der Code kommt dort nie vorbei, oder TFileStream.Create(fmCreate) war erfolgreich und die Datei ist somit auch vorhanden.

Wenn TFileStream.Create knallt, dann bleibt auch noch der Blob-Stream schön als Speicherleck zurück.

[Perlsau]

Zitat von himitsu:

PS: @BlobFeldInDatei
Result := FileExists(Datei); ist etwas sinnlos nutzlos, denn es muß zwangsläufig immer True zurückgeben.
Entweder knallte das TFileStream.Create und der Code kommt dort nie vorbei, oder TFileStream.Create(fmCreate) war erfolgreich und die Datei ist somit auch vorhanden.
Wenn TFileStream.Create knallt, dann bleibt auch noch der Blob-Stream schön als Speicherleck zurück.

Du meinst, das TFileStream.Create gehört in den Try-Finally-Block? Klingt logisch, werde ich gleich mal ändern. Dann macht auch Result := FileExists(Datei); Sinn, obwohl ich da natürlich genausogut schreiben könnte Result := True; .
Du hast meinen Code verbessert, dafür sei dir mein Dank gewiß

[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.
2x Try-Finally, oder Create drinnen und davor initialisieren.

Sinn: Nja, wenn es im Create knallt, kommt es dennoch nicht beim Exists vorbei, außer Exists steckt im finally.

[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