Closefile geht nicht ... ? [ gelöst ]

[corpsman]

Hossa,

Ich wollte mir gerade eine kleine Funktion basteln, welche mir meine UTF8 Texte unter Linux in Iso8859 Texte für Windows Umwandelt.

Also habe ich folgendes ergoogelt :

Code: Alles auswählen

Var
  f_: File Of byte;
  s: String;
  i: integer;
  b: Byte;
Begin
  If savedialog1.execute Then Begin
    //    s := ConvertEncoding(memo1.Lines.text, EncodingUTF8, EncodingAnsi);
    s := ConvertEncoding(Synedit1.Lines.text, EncodingUTF8, 'iso88591');
    assignfile(f_, savedialog1.filename);
    rewrite(f_);
    For i := 1 To Length(s) Do Begin
      If s[i] = #10 Then Begin
        write(f_, 13);
        write(f_, 10);
      End
      Else Begin
        b := ord(s[i]);
        write(f_, b);
      End;
    End;
    closefile(f_);
  End;
End;

Nun in meinem "Demo" mit dem Memo klappt es auch wunderbar, doch in meinem "richtigen" projekt wo ich es einsetzen will ( das dann auch die Synedit benutzt ) bekomme ich eine Kompilerfehlermeldung zu Closefile :

unit1.pas(845,17) Error: Incompatible type for arg no. 1: Got "File Of Byte", expected "LongInt"

Nun bin ich aufgeschmissen, denn ich verstehe absolut nicht was ich falsch gemacht habe. In beiden Projekten stehen die Kompilerswitches auf

{$MODE objfpc}{$H+}

Kann mir hier jemand sagen was ich falsch gemacht habe ?

[theo]

Weiss ich nicht. Aber warum so umständlich und fehleranfällig?
So geht doch auch:

Code: Alles auswählen

sl:=TStringList.create;
sl.Text := ConvertEncoding(Synedit1.Lines.text, EncodingUTF8, 'iso88591');
sl.SaveToFile(savedialog1.filename);
sl.free;

Oder gleich meine charencstreams
http://wiki.lazarus.freepascal.org/Theodp" onclick="window.open(this.href);return false;

[lrlr]

@theo: THEOretisch:für gbyte große file ist, wäre deine TstringList halt eher ungeeignet...


@corpsman: vermutlich die reihenfolge der uses "falsch"

mit strg-> auf CloseFile clicken, dann siehst du welche unit verwendet wird.

sicherheitshalber einfach System.Closefile() verwenden, dann wird sicher die richtige verwendet..

[theo]

@theo: THEOretisch:für gbyte große file ist, wäre deine TstringList halt eher ungeeignet...

Naja, S hält er ja auch in Memory. Dieses Totschlag-Argument sollte man nicht dauernd wiederholen.
Es gilt nur für spezielle Fälle (LogFiles etc), bei denen man normalerweise um die GIGA-Grösse Bescheid weiss.

[lrlr]

ok, wusste nicht, dass dich schon andere darauf angesprochen haben

2. argument: er macht auch convertierung von LF auf CRLF

da wäre ich mir jetzt auch die schnelle nicht sicher, was die stringliste da macht...



für die arbeit hab ich mir einen "reader" gebastelt der TStream als source hat, und die zeilenenden selber sucht..


ähnlich: http://www.delphi3000.com/articles/article_1363.asp?SK=" onclick="window.open(this.href);return false;
(aber auf die schnelle hätte ich gesagt, meiner ist schöner, vorallem exception bei EOF find ich nicht gut..)

vielleicht kann man ja mal einen opensource FPC TTextFileReader machen...

[corpsman]

ui, danke für die Ideen, ich habs nun hin bekommen

Ich hatte den Fehler den lrlr beschreibt.

Allerdings hab ich nun objpas.closefile(),

Und die von Hand cr -> crt Konvertierung ist weil ich eben auch nicht wusste was TStringlist macht .

Ich bin halt Linux Mensch und wollte so die Möglichkeit haben, mit nur einem Klick einen Win Menschen eine Datei zu machen. Und nun gehts *freu*.

Danke auch an alle Beteiligten.

[Hitman]

Ich bin halt Linux Mensch und wollte so die Möglichkeit haben, mit nur einem Klick einen Win Menschen eine Datei zu machen. Und nun gehts *freu*.

Gerade da braucht man sowas doch eigentlich nicht selbst entwickeln .... dos2unix gibts doch schon (und bitte erstmal die man page dazu angucken)

[theo]

Schaut doch mal ein bisschen in die RTL statt alles immer neu zu entwickeln.

TStringList macht die LineBreaks nach der Plattform.
Will man es anders haben, kann man das angeben:
sl.TextLineBreakStyle:=tlbsCRLF

oder nur für Strings:
function AdjustLineBreaks(const S: string; Style: TTextLineBreakStyle): string;

[theo]

ok, wusste nicht, dass dich schon andere darauf angesprochen haben

Solche Klugscheisser Argumente kommen leider immer wieder und führen Neulinge in die Assignfile Hölle

Es ist als würde man dauernd wiederholen;
Trinkt euer Wasser nicht aus Gläsern!!! Man kann sich an Glasscherben übel verletzen!!
Trink lieber aus rostigen Kübeln!

[lrlr]

weil ich grad drübergefallen bin

http://pasdoc.svn.sourceforge.net/viewv ... neTalk.pas" onclick="window.open(this.href);return false;

ließt streams zeilenweise..

[theo]

weil ich grad drübergefallen bin
ließt streams zeilenweise..

Das ist zweifellos eine gute Sache.
Nur bin ich total dagegen, mit absurden Argumenten die Praxis des schnellen und fehler-unanfälligen Programmierens a la TStringList deswegen zu opfern. Oder v.a. Neulingen einzureden, es wäre besser mit zeilenweisem Lesen auf Textfiles rumzukratzen. (v.a wenn diese dann doch in einem String im RAM landen).
Die gesamte Encyclopædia Britannica hat auf ca. 300 MB Platz. Das kann heute jeder Rechner in den Speicher laden.

[Hitman]

Die gesamte Encyclopædia Britannica hat auf ca. 300 MB Platz. Das kann heute jeder Rechner in den Speicher laden.

Aber sicherlich komprimiert ... ansonsten wär die ja ziemlich mager.

[theo]

Aber sicherlich komprimiert ... ansonsten wär die ja ziemlich mager.

Habe ich falsch gerechnet? Hier steht 300 Millionen Characters:
http://en.wikipedia.org/wiki/Wikipedia:Size_comparisons" onclick="window.open(this.href);return false;

[Hitman]

Habe ich falsch gerechnet? Hier steht 300 Millionen Characters:
http://en.wikipedia.org/wiki/Wikipedia:Size_comparisons" onclick="window.open(this.href);return false;

Ah, reiner Text - dann passts. Zu der Enzyklopädie gehören aber sicher auch jede Menge Bilder, daher hat mich das schon etwas verwundert, wie die unkomprimiert in 300MB passen sollte.

[theo]

Wir reden hier von Textfiles (Kodierung umwandeln) und da interessieren die Bilder ja nicht.
Mir geht bloss dieses blödsinnige Argument für zeilenweises Einlesen auf den Sack.

Es ist übrigens der gleiche Blödsinn, wie wenn man einem Neuling beibringen will, statt mit dynamischen Arrays rumzufummeln, eine TList (oder TFPList) zu verwenden. Da kommt dann immer das Schlaumeier Argument, dass man dabei irgendwie 4 Bytes Overhead hat und das Einfügen theoretisch 0.0000003 % langsamer ist.
Die Vorteile der Fehlerunanfälligkeit und des schlaueren Speicher-reservierens interessieren dann keinen mehr.

Einfach Klappe halten, oder konsequenterweise den ASM Code vorlegen