Dateien schreiben - Returncode

[Prowokant]

@ bobobo

Dann arbeite ich lieber ohne die PB-Funktionen und
mache es selbst. Ist ja nicht die Welt. Für das normale
Dateihandling haben wir ja brauchbare Lösungen
gefunden. Schade nur um die netten Funktionen.
Aber es wird sicher irgendwann mal alles gut.

[Tafkadasom2k5]

@ Tafkadasom2k5

Du solltest den Thread vielleicht erst einmal lesen.

Das hatte ich, und ich dachte, dass du das mit Bobobos Methode (wie er in seinem letzen Post beschrieb) machst. (Größe berechnen, gucken ob es passen würde, schreiben, vll sogar noch Korrekturlesen).

Deshalb war ich ein wenig verwundert. Zudem Pref-Dateien selten sooo groß sind, dass sie eine Diskette füllen

(OK, ich wusste jetzt nicht mehr genau, ob beim Dateischließen wirklich geflusht wird oder nicht..)

Gr33tz
Tafkadasom2k5

[Prowokant]

@ Tafkadasom2k5

"Bobobos Methode" funktioniert (für meinen Geschmack) nicht.
Beim Schreiben können viele Fehler auftreten, nicht nur, dass
das Medium voll ist.

Es gibt nur zwei brauchbare Möglichkeiten:
1. Wenn Geschwindigkeit kein Problem ist:
Nach jedem Write ein Flush mit Prüfung der beiden Returncodes.
2. Wenn man Geschwindigkeit schinden muss:
Flush-Puffer-Größe recht hoch setzen.
Returncodes von den Writes summieren und einen Flush bei einer
programmspezifischen High-Water-Mark auslösen. Den Returncode
dann mit der Summe vergleichen.

Alles Andere ist Unsinn, da nicht alle Fehler berücksichtigt werden.
Man darf das Problem nicht auf "Medium voll" reduzieren und man
darf auch nicht vergessen, dass man nicht allein auf einem Rechner
arbeitet und dass man selbst und andere mit mehreren Programmen
arbeiten. Auch arbeiten alle evtl. auf dem selben Medium und man
weiß auch nicht immer, wie groß Dateien werden.

> Zudem Pref-Dateien selten sooo groß sind, dass sie eine Diskette
> füllen :wink:

Es ist gleichgültig, wie groß Dateien werden oder nicht werden. Klar,
im Idealfall gibt es zu dem Programm eine Datei mit Preferenzen,
die bereits die Maximalgröße hat und wenn man die dann schreiben
kann, ist Alles im grünen Bereich. Man programmiert aber keine
Idealfälle, sondern geht immer von den widrigsten Umständen aus.

[bobobo]

ich schrob deshalb ja auch extra "Doof"-Methode

.... Man programmiert aber keine
Idealfälle, sondern geht immer von den widrigsten Umständen aus.

... die man dann zu ca. 90 Prozent per Programm abfangen kann, was einem dann allerdings der Auftraggeber nicht bezahlt. Aber niemand hat je behauptet, dass Programmieren glücklich machen soll.

[Prowokant]

@ bobobo

und ich schrob deshalb ja auch extra "@ Tafkadasom2k5 "

... die man dann zu ca. 90 Prozent per Programm abfangen kann

Wenn die Programmierumgebung das zulässt. :-)

was einem dann allerdings der Auftraggeber nicht bezahlt.

Ich arbeite mit PureBasic nur Just-For-Fun. Professionell nutze ich
andere Sprachen.

Aber niemand hat je behauptet, dass Programmieren glücklich machen soll.

Wenn man Just-For-Fun programmiert, sollte es glücklich machen
und wenn man es professionell betreibt, so sollte es, wie jeder
andere Beruf auch, wenigstens Spass machen, oder?

[PureLust]

... und wenn man es professionell betreibt, so sollte ...

... die Programmiersprache zumindest die Funktionen bieten, die eine professionelle Programmiersprache haben sollte.

[PMV]

Ich verstehe dein Problem nicht ... was PB nicht liefert mache man sich
selber ... und durch die Macros funzt das ganze sogar als ob
es ein ganz normaler PB-Befehl wäre, also alter Code bleibt funktionsfähig:

Code: Alles auswählen

Procedure MyWriteStringN(File, Text$)
  Protected Size.l, BufferSize.l
  Size = Lof(File)
  BufferSize = WriteStringN(File, Text$)
  FlushFileBuffers(File)
  If Lof(File) <> BufferSize + Size
    BufferSize = Lof(File) - Size
  EndIf
  ProcedureReturn BufferSize
EndProcedure
Macro WriteStringN(File, Text)
  MyWriteStringN(File, Text)
EndMacro

;================================
;Bobobos Beispiel etwas umgeändert :-)
;-----------
;Ausgabesatz erzeugen 
;der sollte in diesem Demo allerdings letztlich mindestens 4096 Byte lang sein 
;weil das anscheinend die Größe des Speicherbuffers ist. 
;Bei kleineren Werten funktioniert das nicht 
;weil der Autor dieser Zeilen noch nie was von Filebuffersize gehört hat 
;und sich dafür schämt 
For i= 1 To 4096 
  Ausgabesatz.s+Chr(Random(26)+45) 
Next i 
OpenConsole() 
EnableGraphicalConsole(#True)
AusgabeDatei$ = "A:\xxx.txt" 

If OpenFile(1, AusgabeDatei$) 
  FileSeek(1, Lof(1))
  s = Lof(1)
  ConsoleLocate(2, 2)
  PrintN("Filesize: ")
  Repeat 
    s + Size
    ConsoleLocate(12, 2)
    Print(Str(s) + " Byte") 
    Size = WriteStringN(1, Ausgabesatz) 
    If Size <> Len(Ausgabesatz+#CRLF$) ; wegen WriteStringn(), bei writestring() ohne den Anhang 
      ConsoleLocate(2, 4)
      PrintN("Programmende: Speichermedium voll!")
      Break
    EndIf
  ForEver
  Input() 
  CloseFile(1) 
  ;DeleteFile(AusgabeDatei$)
Else
  PrintN("Datei konnte nicht erstellt werden!")
EndIf

End

MFG PMV

[Prowokant]

@ PureLust

... die Programmiersprache zumindest die Funktionen bieten, die eine professionelle Programmiersprache haben sollte. /:->

Genau. Full ACK! Genau so war dies gemeint:

Wenn die Programmierumgebung das zulässt. :-)

[PMV]

PS: der Code war die Lösung zu deinem

1. Wenn Geschwindigkeit kein Problem ist:
Nach jedem Write ein Flush mit Prüfung der beiden Returncodes.

und zu deinem 2. Punkt kann man das ganze auch leicht erstellen

Aber es wäre natürlich auch nicht schlecht, wenn FlushFileBuffer() einen
Rückgabewert hätte oder die Write-Befehle einen optionalen
Parameter, wodurch das direkte schreiben in Dateien möglich ist.

Ach ja, mich würde mal interezieren, was es noch für Probleme geben
kann, außer Speichermedium entfernen oder voll?

MFG PMV

[Prowokant]

@ PMV

Ich verstehe dein Problem nicht ... was PB nicht liefert mache man sich selber

Das "Problem" ist, dass eine aktuell gepflegte
Programmiersprache es nicht nötig haben darf, dass man sich
da was selber machen muss. So etwas Triviales wie das
Schreiben von Dateien muss mit allem Notwendigen einfach
funktionieren. Da gibt es gar keine Diskussion.

Dein Macro ist ja nett. Selbstverständlich würde man es
genau in dieser Art machen müssen. Das ist eine
Selbstverständlichkeit. Es darf aber nicht nötig sein.

Ich habe PB im Juli 2003 gekauft. Ich wusste um einige
Unzulänglichkeiten. Ich war und bin aber vom Potential von
PB überzeugt. Leider musste ich bis zur Version 4 warten,
bis die für mich wichtigen Datentypen implementiert
waren. Nun möchte ich mich ans Werk machen und stelle
fest, dass so elementare Dinge, wie das Schreiben in
eine Datei, immer noch nicht so funktionieren wie sie
sollten. Das ist nicht mehr lustig. Das ist absolut
indiskutabel, ein Witz (ein schlechter).

Ich bin nicht der Spezialist für Windows-Programmierung
und ich muss mich auch in Basic wieder etwas einarbeiten,
aber ich weiß, was ich von einer Programmierumgebung
und einer Programmiersprache erwarten darf. Ich
programmiere seit mehr als 20 Jahren professionell und
privat seit knapp 30 Jahren. Ich entwickle vorwiegend
systemnahe Funktionsbibliotheken und relativ große
Anwendungen im Bereich GIS. Meine Heimat sind
Unix-Systeme. Ich habe allerdings auch schon einige
Windows-Programme geschrieben. Ich wollte dies nicht
gern schreiben, aber es nervt mich langsam, wenn zig
Leute versuchen mir zu erklären, dass man das, was mir
an Funktionalität fehlt, überhaupt nicht braucht. Bitte
verschont mich mit solchem Unsinn.

Ich wollte ursprünglich nur wissen, wie man es überhaupt
regeln kann. Die Infos über die undokumentierten
Rückgabewerte haben mir völlig gereicht. Ich wusste
was PB diesbezüglich kann und was nicht.

Die Preferenz-Datei-Funtionen lassen die Möglichkeit,
die die Dateifunktionen bieten, nicht zu. Damit sind
sie gänzlich unbrauchbar. Schade eigentlich - und das
meine ich ernst.