Fehler beim überschreiben von Datei

[DeddyH]

Dann würde ich persönlich das aber so deklarieren:

Delphi-Quellcode:

function ReadTextFile(const Filename: AnsiString; AccessMode: Integer = fmOpenRead): AnsiString;

[Luckie]

OK, das sind jetzt Kleinigkeiten. Es ging ja um die Fehlerbehandlung.

[DeddyH]

Sicherlich, aber wenn wenn man Code verbessern kann, spricht doch nichts dagegen. Das finde ich zumindest besser, als wenn auf die SuFu verwiesen wird und diese nur halbgare Lösungen zu Tage befördert (ich meine damit jetzt nicht diesen konkreten Fall).

[EWeiss]

Zitat:

Zitat von sx2008 (Beitrag 1094540)

Ganz schlimmer Sourcecode. :duck:
Globale Variablen, Funktion die nicht das tun was man erwartet, wirre verkettete Listen,
hart codierte Zahlen anstelle von Konstanten, Speicherlecks, usw.

Zitat:

wirre verkettete Listen

Was ist da wirr haben alle ihre Berechtigung.

Zitat:

Globale Variablen

Ist ein Hobby von mir Rückbleibsel aus VB(Visual Basic) Tagen

Zitat:

Speicherlecks

Und das siehst du so ohne GlasKugel.. WOW!

Wer schreibt mir vor in welchen Stil ich schreiben muss?
Für mich zählt das ergebnis nicht ob ich eine für mich nichtssagende Konstante
verwende oder hartcode.
Solange wie der Compiler damit zurecht kommt.
Sieht man das nachher in der Compilierten EXE?

Kennst den Unterschied zwischen
Dim X% und Dim X As Integer ?

Siehste ... welche Schreibweise ist dir genehm wenn beides das gleiche Ergebnis liefert.

gruss

[EWeiss]

Zitat:

Zitat von DeddyH (Beitrag 1094600)

Sicherlich, aber wenn wenn man Code verbessern kann, spricht doch nichts dagegen. Das finde ich zumindest besser, als wenn auf die SuFu verwiesen wird und diese nur halbgare Lösungen zu Tage befördert (ich meine damit jetzt nicht diesen konkreten Fall).

DeddyH / Luckie
Danke euche

gruss

[himitsu]

@Luckie:
Diese alten Pascal-Routinen nutzen IOResult und nicht GetLastError :zwinker:

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1094628)

@Luckie:
Diese alten Pascal-Routinen nutzen IOResult und nicht GetLastError :zwinker:

Und nicht vergessen.
Bei IOResult müssen die Schalterbefehle $I auf $I+ gesetzt werden.

Ja, ja was für eine Ironie

gruss

[p80286]

Könnte mir mal jemanderklären was es mit

Delphi-Quellcode:

FSeekto

auf sich hat?
Bei der Kombination

Delphi-Quellcode:

Seek

und

Delphi-Quellcode:

Readln

kringeln sich mir meist die Fingernägel.

Gruß
K-H

[EWeiss]

Zitat:

Zitat von p80286 (Beitrag 1094632)

Könnte mir mal jemanderklären was es mit

Delphi-Quellcode:

FSeekto

auf sich hat?
Bei der Kombination

Delphi-Quellcode:

Seek

und

Delphi-Quellcode:

Readln

kringeln sich mir meist die Fingernägel.

Gruß
K-H

Heehehehehe
Seek kommt von!

• 1.suchen
• 2.streben nach
• 3.forschen
• 4.erlangen wollen

Zitat:

kringeln sich mir meist die Fingernägel

Bei mir auch.

gruss

[himitsu]

Meinst du nicht $I- ?

ich dachte $I+ schaltet die delphiseitige Prüfung an, womit Delphi dann exceptions wirft, wenn es nicht geht.

Aber für Luckies Beispiel ist $I+ richtig, da er dort die delphiinterne Excepetions nutzt und in Try-Except IOResult auswerten würde.

Bei $I- wird keine Exception geworfen und man muß im "normalen" Programmablauf auf IOResult prüfen, ob die vorherrigen Operationen erfolgreich waren.
ja ja, das waren schon komische Fehlerbehandlungen damals.


Wobei Seek und ReadLn garnicht zusammen funktionieren sollte. :shock:
ReadLn ist nur für Textdateien und Seek sollte bei Textdateien nicht funktionieren und einen Fehler auslösen.
(Da sich Borland es gespart hat den internen Textpuffer bei Seek zu behandeln und lieber einen Fehler auslöste)

Also irgendwie ist mir diese ganze UIrgendwasParse-Unit etwas suspekt.