PureBoard

Verfasst: **14.08.2006 14:00**

@AND51

Man müsste dann alle Ausgabelängen aufaddieren.
Das finde ich dann aber wirklich nicht mehr praktisch.
Zudem müsste man immer so einen Notausstieg wie
mit den 80000 machen. Das kann es nicht sein.

Ob die Datei angelegt ist, sollte nicht nötig sein, es zu prüfen,
da der Open einen entspr. Returncode liefern müsste.

Verfasst: **14.08.2006 14:15**

Das Problem ist gelöst!

Die Dokumentation von PB4 ist hier wirklich etwas stiefmütterlich.
Nach dem Posting von "Kaeru Gaman" habe ich dann doch einmal
im MSDN nachgeschaut. Es scheint wirklich so zu sein, dass der
write immer die Anzahl der Bytes zurückliefert und erst der fflush
dann ggf. einen Fehlercode liefert, indem er eine Zahl liefert, die
nicht der des write entspricht.

Das Testprogramm sollte daher wie folgt geändert werden:

Code: Alles auswählen

OpenConsole()
AusgabeDatei$ = "A:\xxx.txt"
Zaehler.l = 0
If CreateFile(1, AusgabeDatei$)
  Repeat
    Zaehler = Zaehler + 1
    AusgabeSatz$ = "Zeile #" + Right("0000000" + Str(Zaehler),7)
    RC = WriteStringN(1, AusgabeSatz$)
    RCF = FlushFileBuffers(1)
;    PrintN(Str(Zaehler) + " - RC: " + Str(RC) + " / RCF: " + Str(RCF))
  Until RCF <> RC
  CloseFile(1)
Else
  PrintN("Fehler!")
EndIf
PrintN("Done!")
End

Dann klappts auch wieder mit der Nachbarin.
Ich wußte doch, dass PB4 gar nicht so schlecht ist.
[Schulmeister]
Aber:
Ich kann allen nur empfehlen diese Prüfung in den
eigenen Programmen auch zu machen!
Sowas gehört in die Doku!!!
[/Schulmeister]

Verfasst: **14.08.2006 14:17**

cool. da bin ich ja mal gespannt.

Verfasst: **14.08.2006 14:30**

Jetzt verrat mir nur noch jemand, warum das mit
dem "[code]" und dem "[/code]" bei mir nicht
funktioniert und dieser Montag ist mein Freund.

Verfasst: **14.08.2006 14:35**

geh mal auf edit und guck unten bei den checkboxen, da muss das häkchen bei "BBCode in diesem Beitrag deaktivieren" weg.
das kannst du als grundeinstellung auch in deinem profil ändern.

PS: und meinen Namen brauchst du nicht in Anführungszeichen zu setzen.

Verfasst: **14.08.2006 14:38**

@ Kaeru Gaman
You made my day. Tnx

Verfasst: **14.08.2006 14:45**

@topic

interessant.
ja, auf die verwendung von FlushFileBuffers() sollte explizit hingewiesen werden.

normalerweise würde man aber ja wohl eher die schleife nach der menge der zu schreibenden daten ausrichten, und die bedingung "RCF <> RC" in einem abbruch+fehlermeldung münden lassen.
(is ja wohl nurn beispiel wies funktioniert)

Verfasst: **14.08.2006 14:54**

Kaeru Gaman hat geschrieben: normalerweise würde man aber ja wohl eher die schleife nach der menge der zu schreibenden daten ausrichten, und die bedingung "RCF <> RC" in einem abbruch+fehlermeldung münden lassen.
(is ja wohl nurn beispiel wies funktioniert)

Natürlich! Keine Frage!
Aber nach jedem "Write..." sollte ein "FlushFileBuffers" folgen. Die
(undokumentierten) Rückgabewerte sollten verglichen werden und
es sollte eine Fehlerbehandlung erfolgen, sofern die beiden
Rückgabewerte differieren. Was zu tun ist, hängt vom Programm
ab. Das geht von einem Eintrag im Logfile bis zum Programmabbruch,
je nachdem, was sinnfälliger ist. In der Regel wird es wohl ein
Programmabbruch werden.

Verfasst: **14.08.2006 14:58**

kommt ganz aufs programm an.

bei nem editor würde ich mir ne meldung à la "Datenträger ist voll" wünschen,
weil ich wohl kaum möchte, das meine mühsam erstellte karte verworfen wird,
nur weil sie nicht mehr auf die diskette passt.

innerhalb eines games wirds etwas schwieriger, vielleicht wäre da so etwas denkbar:

Spielstand kann nicht gespeichert werden.
Der Datenträger ist voll.
Bitte löschen Sie ältere Spielstände und versuchen Sie es dann erneut

ein kompletter programmabbruch wäre i.m.h.o. eher die ausnahme.

Verfasst: **14.08.2006 15:08**

Kaeru Gaman hat geschrieben:kommt ganz aufs programm an.

bei nem editor würde ich mir ne meldung à la "Datenträger ist voll" wünschen,
weil ich wohl kaum möchte, das meine mühsam erstellte karte verworfen wird,
nur weil sie nicht mehr auf die diskette passt.

innerhalb eines games wirds etwas schwieriger, vielleicht wäre da so etwas denkbar:
Spielstand kann nicht gespeichert werden.
Der Datenträger ist voll.
Bitte löschen Sie ältere Spielstände und versuchen Sie es dann erneut
ein kompletter programmabbruch wäre i.m.h.o. eher die ausnahme. ;)

Ich habe ja "in der Regel" geschrieben.

Wenn es um Dateien geht, die du interaktiv erzeugst, gebe ich dir Recht.
Dann sollte sich ein Programm derart verhalten, wie du es beschreibst.

Bei Programmen für die Konsole wird der Dateiname beim Aufruf
übergeben. Dann ist ein Abbruch, nach vorherigem Löschen des
Dateifragments, sinnvoller. Ebenso verhält es sich bei temporären,
programmintern genutzten Dateien. Auch hier ist es warscheinlich,
dass ein Fortsetzen des Programmlaufs sinnlos ist. Ich habe unterstellt,
dass derartige Dateien eher in der Mehrzahl, gegenüber den interaktiv
erzeugten Ausgaben sind.

Selbstverständlich sollte ein Programmabbruch nie ohne sinnvolle
Meldung erfolgen.

PureBoard

Dateien schreiben - Returncode