TFileStream-Probleme

[DeCodeGuru]

Hi Leute,

letztens habe ich versucht eine Datei in ein FileStream zu laden.
Das habe ich folgender Maßen gemacht:

Code:

MyStream := TFileStream.Create(OpenDialog1.Filename,fmOpenReadWrite);

So, als ich jetzt das Programm gestartet habe und eine Datei laden wollte, kam bei mir ne Exception und sagte: Ungültiges Format %p!!

Oder so ähnlich (Habe die Fehlermeldung nicht mehr so richtig im Kopf)

[Daniel]

Also folgender Code funktioniert bei mir unter Delphi 6.02:

Code:

procedure TForm1.Button3Click(Sender: TObject);
var MyStream : TFileStream;
begin
  If OpenDialog1.Execute Then
  Begin
    MyStream:= TFileStream.Create( OpenDialog1.Filename, fmOpenReadwrite );
    //
    ShowMessage( IntToStr(MyStream.Size) + ' Bytes gelesen' );

    MyStream.Free;
  End;
end;

Hast Du vielleicht nochmal die genaue Fehlemeldung?

Grüße,
Daniel

[DeCodeGuru]

Also, ich habe das Programm jetzt mal gestartet und der Fehler ist nicht mehr aufgetreten, als ich um den Code einen try..finally-Block gesetzt habe. Anscheinend funktioniert es so. Ich werde den Fehler versuchen nochmal zu reproduzieren.

Aber danke für deine Antwort.

MfG DeCodeGuru

[Daniel B]

Hi,

ich meine das sachen die Createt und Freeet werden grundsätzlich in einem Try...Finally sein sollten.

Grüsse, Daniel

[DeCodeGuru]

Hi Daniel!

Zitat:

ich meine das sachen die Createt und Freeet werden grundsätzlich in einem Try...Finally sein sollten.

Da kann man geteilter Meinung sein. Es kommt immer auf die Situation an. Sicherlich bietet sich eine Try-Finally-Konstellation an, aber grundsätzlich kann man hier nicht sagen - würde ich sagen

[Alfons_G]

Spätestens, wenn Create und Free in unterschiedlichen Prozeduren stehen (müssen), ist try ... finally natürlich nicht mehr möglich. In diesem Fall kann man, falls das Programm trotz eines eventuellen Fehlers fortgesetzt werden soll, eine Statusvariable mitführen.

Eine mögliche Sitation ist z.B. eine Log-Datei, die ins Programmverzeichnis geschrieben wird, falls möglich. Wird das Programm dagegen von einem Read-Only-Verzeichnis oder von CD gestartet, entfällt das Log.

Wo möglich, sollte man jedoch schon mit try ... finally kapseln. Eine erhebliche Fehlerquelle ist damit ausgeschaltet. Vor allem zum Vermeiden von Speicherlecks bei permanent laufenden Hintergrundprogrammen oder Serveranwendungen ist das lebenswichtig.

[MathiasSimmack]

Zitat von Alfons_G:

Wo möglich, sollte man jedoch schon mit try ... finally kapseln.

Da möchte ich zustimmen. Bei deiner Download-Routine hattest du das auch schon vergessen, DeCodeGuru. Auf Teufel komm raus mit der Fehlertoleranz spielen, kann bös´ nach hinten losgehen.

[DeCodeGuru]

Zitat:

Auf Teufel komm raus mit der Fehlertoleranz spielen, kann bös´ nach hinten losgehen.

Da gebe ich dir natürlich Recht.

Zitat:

Bei deiner Download-Routine hattest du das auch schon vergessen, DeCodeGuru.

Gut, ok, das war aber nur ein Zufall. Normalerweise verwende ich auch try...finally.

[Christian Seehase]

Moin Alfons,

Zitat von Alfons:

Spätestens, wenn Create und Free in unterschiedlichen Prozeduren stehen (müssen), ist try ... finally natürlich nicht mehr möglich.

Jain, würde ich sagen.
Wird das Objekt (unit)global benötigt, wird man es in der Regel in initialization erzeugen und in finalization freigeben können, was ja, im Wesentlichen, dem try/finally entspricht.
Könntest Du, oder natürlich auch jemand anders, mal ein Beispiel angeben, wo dies nicht möglich ist?