Fehler beim überschreiben von Datei

[EWeiss]

Wenn ich meine Datei die vorher mit hFile geschlossen wurde
überschreiben will bekomme ich einen EInOut Error

Delphi-Quellcode:

  myFile := SKAERO_SaveFileDialog(MainHandle, 'MidiTracker files (*.mtf*)|*.mtf*', 'mtf', 'MidiTrackerFile');
  AssignFile(f, myFile);
  Rewrite(f);

Der Fehler tiritt in der Zeile Rewrite(f); auf.

Was mache ich falsch?

Geschlossen wird es korrekt.

Delphi-Quellcode:

procedure FClose(var hFile: Cardinal);
begin
    if hFile <> 0 then
      CloseHandle(hFile);

    hFile := 0;

end;

gruss

[s.h.a.r.k]

Was genau für ein Fehler? Da gibts doch immer eine Nummer, oder? :)

[EWeiss]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1094478)

Was genau für ein Fehler? Da gibts doch immer eine Nummer, oder? :)

I/O Error 32 // << Datei ist belegt. Dateiname ist möglicherweise bereits vorhanden und geöffnet.

Meinst das ? ;)

Ist aber geschlossen.

EDIT:
Fülle den Buffer

Delphi-Quellcode:

FBuffin(MidiTrackerFile);

Delphi-Quellcode:

procedure FBuffin(FileName: string);
var
  sBuffer: string;

begin

  if not FExist(FileName) then Exit;
    nErrCode := FOpen(FileName, 0, 2, myFile);
  if nErrCode <> 0 then exit;
    nReading := 0;

  Assignfile(ParseFile, FileName);
  reset(ParseFile);

  while not eof(ParseFile) do
  begin
    ReadLN(ParseFile, sBuffer);
    FSeekTo(nReading, sBuffer);
    inc(nReading);
  end;

end;

Dann öffne ich die Datei und setze die Zugriffsrechte

Delphi-Quellcode:

FOpen(FileName, 0, 2, myFile);

Nur Lesen
0= AccessIs := GENERIC_READ;
Schreibzugriff verweigern.
2= ShareIs := FILE_SHARE_READ

Nach dem einlesen der datei wird alles wieder geschlossen und auf nil gesetzt

Delphi-Quellcode:

  // MidiTrackerFile schließen
  FClose(myFile);

  FPBuffer := nil;
  FToPBuffer := nil;
  Result := True;

Theoretisch dürfte jetzt kein zugriff auf die Datei mehr vorhanden sein.
Aber trotzdem kann ich sie nicht überschreiben.
Die Zugriffsrechte dürften dann keinen Einfluss mehr auf die Datei haben
nach dem schließen.

gruss

[himitsu]

Zitat:

Zitat von EWeiss (Beitrag 1094474)

Was mache ich falsch?

Geschlossen wird es korrekt.

Du öffnest über Pascal-Routinen und schließt über die WinAPI?

Warum nicht

Delphi-Quellcode:

CloseFile(f);

?

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1094485)

Zitat:

Zitat von EWeiss (Beitrag 1094474)

Was mache ich falsch?

Geschlossen wird es korrekt.

Du öffnest über Pascal-Routinen und schließt über die WinAPI?

Warum nicht

Delphi-Quellcode:

CloseFile(f);

?

Siehe mein EDIT!

gruss

[Klaus01]

Delphi-Quellcode:

 if not FExist(FileName) then Exit;
    nErrCode := FOpen(FileName, 0, 2, myFile);

Hallo Emil,

Du öffnest die Datei immer mit FOpen
schliesst sie aber nie mit z.B. mit FClose.

Reset öffnet die (Text)Datei zum Lesen - das scheint ja noch in Ordnung zu sein.
Da die Datei mit
0= AccessIs := GENERIC_READ;
Schreibzugriff verweigern.
2= ShareIs := FILE_SHARE_READ
geöffnet wurde.

Rewrite öffnet die Datei zum Schreiben - da kracht es weil die Datei nur zum Lesen geöffnet wurde.

Grüße
Klaus

[EWeiss]

Zitat:

schliesst sie aber nie mit z.B. mit FClose.

Und wie nennst du das ?

Delphi-Quellcode:

  // MidiTrackerFile schließen
  FClose(myFile);

  FPBuffer := nil;
  FToPBuffer := nil;
  Result := True;

Ist das ein Vielleicht FClose?

Zitat:

Rewrite öffnet die Datei zum Schreiben - da kracht es weil die Datei nur zum Lesen geöffnet wurde.

Wie kann ein Rewrite einfluss auf eine geschlossenen Datei haben ?
Siehe FClose....

Die zugriffsrechte haben dann keine Bedeutung mehr.
Es sei denn das schließen des Handle allein genügt nicht!
Und die Datei ist mehr oder weniger immer noch offen.

Oder aber die zugriffsrechte werden in die Datei gespeichert!
Dann wäre es verständlich wenn sie sich nicht überschreiben läßt.

grrr....

gruss

[rollstuhlfahrer]

wäre es nicht mal sinnvoll, einen größeren Teil des Quellcodes auszupacken? - Zumindest mit dem Teil hier habe ich so meine Probleme:

Zitat:

Zitat von EWeiss

Delphi-Quellcode:

procedure FBuffin(FileName: string);
var
  sBuffer: string;

begin

  if not FExist(FileName) then Exit;
    nErrCode := FOpen(FileName, 0, 2, myFile);
  if nErrCode <> 0 then exit;
    nReading := 0;

  Assignfile(ParseFile, FileName);
  reset(ParseFile);

  while not eof(ParseFile) do
  begin
    ReadLN(ParseFile, sBuffer);
    FSeekTo(nReading, sBuffer);
    inc(nReading);
  end;

end;

Du öffnest die Datei eimal über dein FOpen und direkt danach ein 2. Mal über AssignFile/Reset (also Pascal-Routinen). Bis zu dem Ende der Routine wird die Daei 0x wieder geschlossen, also müsste sie danach 2x auf sein. Außerdem finde ich es sehr schlecht, Datei-Handles als globale (nicht-lokale) Variablen zu wählen, da falls die Routine noch mal aufgerufen wird, bevor die Datei geschlossen wurde (und zwar 2x) ist die erste Datei noch auf und die 2. Datei überschreibt ALLE Referenzen. Eventuell ein Struktur-Problem?

Bernhard

[EWeiss]

Zitat:

ein 2. Mal über AssignFile/Reset (also Pascal-Routinen).

Danke habe ich auch gerade bemerkt als ich meine zeilen nochmal überflogen habe.

Globale Variablen habe ich rausgeschmissen und deklariere sie nun in meiner procedure direkt.

Ich glaube den Mist habe ich vor langer zeit mal selbst verzapft.
Ich denke weil ich zu der zeit (und immer noch nicht weis) wie ich hFile durch
eine EOF schleife laufen lassen kann.

Das ich die Datei dadurch 2 mal öffne ist mir nicht wirklich aufgefallen.

EDIT:
Sehe gerade kann hFile gar nicht mit EOF öffnen da EOF zu Pascal und hFile zur Win32 Api gehört.
grrr.. muss dann wieder alles umschreiben.

Ok geht jetzt..
Habe meine procedure umgeschrieben.

Delphi-Quellcode:

procedure FBuffin(FileName: string);
var
  sBuffer: string;
  f      : TextFile;
begin

  if not FExist(FileName) then
    Exit;

  Assignfile(f, FileName);
  reset(f);

  while not eof(f) do
  begin
    ReadLN(f, sBuffer);
    FSeekTo(nReading, sBuffer);
    inc(nReading);
  end;

  CloseFile(f);

end;

Die Datei dann nochmals über hFile zu öffnen macht dann nicht wirklich sinn.

gruss

[Klaus01]

Hallo Emil,

ich würde die FBuffin Procedure so umbauen,
dass die Datei darin geöffnet und auch geschlossen wird.

Delphi-Quellcode:

procedure FBuffin(FileName: string; {var hFile: THandle});
var
  sBuffer: string;
  f : TextFile;
  hFile : THandle;
begin

  if not FExist(FileName) then Exit;

  nErrCode := FOpen(FileName, 2, 4, hFile);  // Was willst Du damit bewecken? 
                                             // Nur einen ErrorCode bekommen?

  if nErrCode <> 0 then exit;                

  nReading := 0;

  Assignfile(f, FileName);
  {$I -}
  reset(f);
  {$I +}

  if IOResult = 0 then
    begin
      while not eof(f) do
        begin
         ReadLN(f, sBuffer);
         FSeekTo(nReading, sBuffer);
         inc(nReading);
        end;
      closeFile(f);
    end;
  fClose(hFile);
end;

So weit ich gesehen habe, wird die Variable hFile nicht
in der Routine ParsetoMidiTracker verwendet (ausser für fClose).

Grüße
Klaus

[EWeiss]

Delphi-Quellcode:

FOpen(FileName, 2, 4, hFile);

Nein ich wollte die datei mit Zugriffsrechten öffnen.
Das war der einzige Sinn und zweck..

Scheinbar ist mir da ein Denkfehler unterlaufen.

Habe es jetzt so gelößt..

Delphi-Quellcode:

procedure FBuffin(FileName: string);
var
  sBuffer: string;
  f : TextFile;
begin

  if not FExist(FileName) then
    Exit;

  Assignfile(f, FileName);
  reset(f);

  while not eof(f) do
  begin
    ReadLN(f, sBuffer);
    FSeekTo(nReading, sBuffer);
    inc(nReading);
  end;

  CloseFile(f);

end;

Danke für eure Hilfe

gruss

[Aphton]

Dieses Snippet ist so nicht sicher...
Was ist, wenn aus welchen Gründen auch immer in der Schleife ein Fehler auftritt? In diesem Fall wird das Filehandle nicht geschlossen, dh. CloseFile(f); wird nicht unbedingt aufgerufen. Im weiteren Programmfluss könnte das zu Bugs führen!
Daher packe das bitte in ein Try-Finally Konstrukt!

[EWeiss]

Zitat:

Zitat von Aphton (Beitrag 1094518)

Dieses Snippet ist so nicht sicher...
Was ist, wenn aus welchen Gründen auch immer in der Schleife ein Fehler auftritt? In diesem Fall wird das Filehandle nicht geschlossen, dh. CloseFile(f); wird nicht unbedingt aufgerufen. Im weiteren Programmfluss könnte das zu Bugs führen!
Daher packe das bitte in ein Try-Finally Konstrukt!

Also für den Fall der Fälle

Meinst so? :)

Delphi-Quellcode:

procedure FBuffin(FileName: string);
var
  sBuffer: string;
  f      : TextFile;
begin

  if not FExist(FileName) then
    Exit;
  try
    Assignfile(f, FileName);
    reset(f);

    while not eof(f) do
    begin
      ReadLN(f, sBuffer);
      FSeekTo(nReading, sBuffer);
      inc(nReading);
    end;
  finally
    CloseFile(f);
  end;

end;

[Luckie]

ich würde da noch eine Fehlerbehandlung einbauen. Sonst wunderst du dich irgendwann warum nichts passiert und suchst dich wieder dumm und dämlich.

[EWeiss]

Zitat:

Zitat von Luckie (Beitrag 1094521)

ich würde da noch eine Fehlerbehandlung einbauen. Sonst wunderst du dich irgendwann warum nichts passiert und suchst dich wieder dumm und dämlich.

Bitte wie sollte die aussehen .. ;)
Ideal wäre auch mit SchreibLeserechtzugriffen.

Weil meine Skin.ini aus dem Programm keinesfalls mit Schreibrechten aufgerufen werden sollte.
Deshalb habe ich auch den kram mit hFile überhaupt eingebaut.

Aber nicht darauf geachtet das die Datei dadurch mehrfach geöffnet wird.

So siehts jetzt aus..
Vielleicht kann es ja jemand brauchen muss halt die Routine für MediaTrackerfile umbauen.

Delphi-Quellcode:

unit uParseTrackerFile;

interface
uses Classes, Windows, uGlobal, SKAeroAPI;

type
  PParseFile = ^TParseFile;
  TParseFile = record
    Nr    :Integer;
    Str   : string;
    Ptr   : PParseFile;
    Max   : Integer;
  end;

function FExist(FileSpec : string): Boolean;
procedure FSeekTo(nReading: Integer; sBuffer: string);
function ParsetoMidiTracker(MidiTrackerFile: string;
  ExePath: string; List: TStringList): Boolean;
procedure FBuffin(FileName: string);

implementation
uses uMidiTracker;

var
  LineStart            : PParseFile;
  FPBuffer             : PParseFile;
  FToPBuffer           : PParseFile;
  nReading             : Integer;

function ParsetoMidiTracker(MidiTrackerFile: string;
  ExePath: string; List: TStringList): Boolean;
var
  sParse     : String;
  IntB: Integer;
  IntA: Integer;

begin

  // Buffer Liste füllen
  FBuffin(MidiTrackerFile);
  if not assigned(FPBuffer) then
  begin
    result := False;
    exit;
  end;

  List.Delimiter := ',';
  FPBuffer := LineStart;
  while (FPBuffer.Nr <= LineStart.Max) do
  begin
    FPBuffer := FPBuffer^.Ptr;
    sParse := LeftTrim(FPBuffer.Str);
    if Length(sParse) <> 0 then
    begin
      List.DelimitedText := sParse;
      // Lade die Noten
      for IntA := 0 to 7 do
      begin
        for IntB := 0 to List.Count - 1 do
          Grid[IntA, IntB] := StrToInt(List.Strings[IntB]);

        inc(FPBuffer.Nr);
        FPBuffer := FPBuffer^.Ptr;
        sParse := LeftTrim(FPBuffer.Str);
        List.DelimitedText := sParse;
        
        for IntB := 0 to List.Count - 1 do
          InstGrid[IntA, IntB] := StrToInt(List.Strings[IntB]);

        inc(FPBuffer.Nr);
        FPBuffer := FPBuffer^.Ptr;
        sParse := LeftTrim(FPBuffer.Str);
        List.DelimitedText := sParse;
      end;

      // Lade das Tempo
      if (FPBuffer.Nr = 16) then
        begin
          for IntB := 0 to List.Count - 1 do
            MidiTracker.Tempo := StrToInt(List.Strings[IntB]);

          SKAERO_SetTrackValue(SKAERO_GetMainItem(MainHandle, ID_TRACK_TEMPO), MidiTracker.Tempo);
          TempoWait := 1000 div round((MidiTracker.Tempo / 15));
        end;
      end;
      if not (FPBuffer.Nr >= LineStart.Max) then
      begin
        inc(FPBuffer.Nr);
        FPBuffer := FPBuffer^.Ptr;
        sParse := LeftTrim(FPBuffer.Str);
        List.DelimitedText := sParse;
      end;

      if (FPBuffer.Nr > 16) then
      begin
        for IntA := 0 to 7 do
        begin
          MidiTracker.CurrentInst[IntA] := StrToInt(List.Strings[IntA]);

        end;
        inc(FPBuffer.Nr);
      end else
      begin
        for IntA := 0 to 7 do
          MidiTracker.CurrentInst[IntA] := InstGrid[IntA, 0];

        inc(FPBuffer.Nr);  
      end;

  end;

  // Resourcen Freigeben
  FPBuffer := nil;
  FToPBuffer := nil;
  Result := True;

end;

procedure FBuffin(FileName: string);
var
  sBuffer: string;
  f      : TextFile;
begin

  if not FExist(FileName) then
    Exit;
  try
    Assignfile(f, FileName);
    reset(f);

    while not eof(f) do
    begin
      ReadLN(f, sBuffer);
      FSeekTo(nReading, sBuffer);
      inc(nReading);
    end;
  finally
    nReading := 0;
    CloseFile(f);
  end;

end;

function FExist(FileSpec : string): Boolean;
var
  hFile: Cardinal;
  lpFindFileData: TWin32FindData;
begin
  Result := False;
  hFile := FindFirstFile(PAnsiChar(FileSpec), lpFindFileData);
  if hFile <> INVALID_HANDLE_VALUE then
  begin
    Windows.FindClose(hFile);
    Result := True;
  end;
end;

procedure FSeekTo(nReading: Integer; sBuffer: string);
begin

  New(FPBuffer);

  if nReading = 0 then
  Begin
    New(FToPBuffer);
    LineStart := FToPBuffer;
  end;

  FPBuffer^.Nr    := nReading;
  FPBuffer^.Str   := sBuffer;
  LineStart^.Max  := nReading;
  FToPBuffer^.Ptr := FPBuffer;
  FToPBuffer      := FPBuffer;

end;

end.

gruss

[sx2008]

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.

[Aphton]

Zitat:

Zitat von EWeiss (Beitrag 1094520)

Zitat:

Zitat von Aphton (Beitrag 1094518)

Dieses Snippet ist so nicht sicher...
Was ist, wenn aus welchen Gründen auch immer in der Schleife ein Fehler auftritt? In diesem Fall wird das Filehandle nicht geschlossen, dh. CloseFile(f); wird nicht unbedingt aufgerufen. Im weiteren Programmfluss könnte das zu Bugs führen!
Daher packe das bitte in ein Try-Finally Konstrukt!

Also für den Fall der Fälle

Meinst so? :)

Delphi-Quellcode:

procedure FBuffin(FileName: string);
var
  sBuffer: string;
  f      : TextFile;
begin

  if not FExist(FileName) then
    Exit;
  try
    Assignfile(f, FileName);
    reset(f);

    while not eof(f) do
    begin
      ReadLN(f, sBuffer);
      FSeekTo(nReading, sBuffer);
      inc(nReading);
    end;
  finally
    CloseFile(f);
  end;

end;

Ähm ich würd Assignfile vorziehen, denn, was ist, wenn z.B. genau dieser Befehl zu Fehler führt? Dann wird CloseFile aufjedenfall noch ausgeführt und das wiederum dürfte zu Fehlern führen, weil es nicht AssignFile nicht richtig ausgeführt werden konnte!

[Luckie]

Zitat:

Zitat von EWeiss (Beitrag 1094523)

Zitat:

Zitat von Luckie (Beitrag 1094521)

ich würde da noch eine Fehlerbehandlung einbauen. Sonst wunderst du dich irgendwann warum nichts passiert und suchst dich wieder dumm und dämlich.

Bitte wie sollte die aussehen .. ;)

So zum Beispiel:

Delphi-Quellcode:

function ReadTextFile(Filename: AnsiString; AccessMode: Integer): AnsiString;
var
  F: TextFile;
  Line: AnsiString;
  FileContent: AnsiString;
begin
  FileMode := AccessMode;
  AssignFile(F, Filename);
  try
    try
      Reset(F);
      while not EOF(F) do
      begin
        Readln(F, Line);
        FileContent := FileContent + Line + #13#10;
      end;
    except
      raise Exception.Create(SysErrorMessage(GetLastError));
    end;
  finally
    CloseFile(F);
  end;
  Result := FileContent;
end;

procedure TForm15.Button1Click(Sender: TObject);
const
  FILENAME = 'D:\Computer\exclude.lst';
var
  s: AnsiString;
begin
  try
    s := ReadTextFile(FILENAME, fmOpenRead); 
    ShowMessage(s); 
  except
    on E: Exception do
      ShowMessage(E.Message);
  end;
end;

[DeddyH]

Wozu den AccessMode angeben, wenn man eh nur lesen möchte? Und den Filename-Parameter könnte man auch als const deklarieren.

Just my 2 cents.

[Luckie]

Weil Standard ist Lesen und Schreiben. Und ich habe eben gedacht, wenn man sie mal anders öffnen möchte, dann kann man das so bequem mit angeben. Und mit dem const hast du recht, das vergesse ich immer.

[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.

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1094635)

Meinst du nicht $I- ?

Ja korrekt! ;)

Zitat:

Wobei Seek und ReadLn garnicht zusammen funktionieren sollte.

Bei mir schon wobei ich nicht Seek sondern FSeekTo verwende was ein sehr großer Unterschied ist.
Ich fülle damit meine Variablen um nachher den start und endpunkt eines Textes über eine Abfrage besser
identifizieren zu können.

Delphi-Quellcode:

procedure FSeekTo(nReading: Integer; sBuffer: string);
begin

  New(FPBuffer);

  if nReading = 0 then
  Begin
    New(FToPBuffer);
    LineStart := FToPBuffer;
  end;

  FPBuffer^.Nr    := nReading;
  FPBuffer^.Str   := sBuffer;
  LineStart^.Max  := nReading;
  FToPBuffer^.Ptr := FPBuffer;
  FToPBuffer      := FPBuffer;

end;

Delphi-Quellcode:

  FPBuffer := LineStart;
  while (FPBuffer.Nr <= LineStart.Max) do
  begin

usw..

Aber wie schon gesagt.
Jeder so wie er am besten zurecht kommt.

EDIT:
So schlecht wie er hier hingestellt wird ist mein Code gar nicht ;)
Einfacher wäre natürlich Copy/Paste hier aus dem Forum.


gruss

[shmia]

Die Procedure FSeekTo müsste eigentlich AppendToLinkedList heissen; denn das ist genau das was passiert: der übergebene Puffer (in Form eines String) wird an die verkettete Liste angehängt. Mit "Seek" oder "FileSeek" hat die Prozedur nix zu tun.
Namensgebung ist beim Programieren einfach sehr wichtig; das darf man nicht auf die leichte Schulter nehmen.

[EWeiss]

Zitat:

Zitat von shmia (Beitrag 1094650)

Die Procedure FSeekTo müsste eigentlich AppendToLinkedList heissen; denn das ist genau das was passiert: der übergebene Puffer (in Form eines String) wird an die verkettete Liste angehängt. Mit "Seek" oder "FileSeek" hat die Prozedur nix zu tun.
Namensgebung ist beim Programieren einfach sehr wichtig; das darf man nicht auf die leichte Schulter nehmen.

Ich suche oder?
Daher auch die Namensgebung

PS:

Zitat:

Mit "Seek" oder "FileSeek"

Habe ich nie gesagt das es damit etwas zu tun hat..

gruss

[Aphton]

Um dich etwas zu stützen - was zählt, ist, dass letzendlich alles klappt.

Genau das ist aber das Ziel und ans Ziel zu gelangen sollte nicht unnötig erschwert werden indem man sich selbst Stolpersteine in den Weg legt (indem man z.B. hardkodierte Zahlen anstatt Konstanten verwendet)
Ausschlaggebend wird das ganze dann beim Debuggen oder wiederverwenden der Codesnippets!

Letzendlich willst du, dass dein Code funktioniert. Das tut es im Moment aber was ist, wenn du nach einer 3-4 monatigen Pause wieder mal dran arbeiten und ein paar Bugs beheben willst. Dir wird dann $02 nichts sagen! Konstanten hingegen dürften verständlicher und dir somit beim Erreichen deines "Zieles" (funktionierender & wiederverwendbarer Code) behilflicher sein!

Es gibt unendlich viele Gründe, warum man Dinge richtig anpacken sollte - damit will ich nicht implizieren, dass deine Methode in irgendiner Form falsch wäre/ist. Aber es gibt bessere Wege! Und warum nicht diese begehen?

:stupid:

Edit: Dies bezieht sich auf diesen Text

Zitat:

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.

[shmia]

Zitat:

Zitat von EWeiss (Beitrag 1094666)

Ich suche oder? Daher auch die Namensgebung

Sag mal, merkst du das nicht, dass die Procedure überhaupt nichts mit "suchen", "streben nach", "forschen" oder "erlangen wollen" zu tun hat???

"AnhaengenAnVerketteListe", "Speichern" oder "Merken" wäre hier korrekte Begriffe!!
Demzufolge ist dein Prozedurname einfach sehr sehr irreführend.
"AppendToLinkedList" wäre eine wirklich passende Beschreibung für die Prozedur.

[Luckie]

Zitat:

Zitat von himitsu (Beitrag 1094628)

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

Und in IOResult steht der letzte Fehler drin? Zumindest, wenn die Datei nicht existiert, kommt der richtige Fehlertext.

@EWeiss: Die Kritik an deinen Code war nicht persönlich gemeint nur eine Konstruktive Kritik. Nehmen wir das Beispiel mit den Konstanten. Wenn du diese hart codest und sie ändern sich mal, bin ich mir zu hundert Prozent sicher, dass du nicht alle Stellen findest, wo du sie benutzt hast. Benutzt du aber eine benannte Konstante, musst du sie nur an einer Stelle im Code ändern.

[EWeiss]

Zitat:

Zitat von shmia (Beitrag 1094668)

Zitat:

Zitat von EWeiss (Beitrag 1094666)

Ich suche oder? Daher auch die Namensgebung

Sag mal, merkst du das nicht, dass die Procedure überhaupt nichts mit "suchen", "streben nach", "forschen" oder "erlangen wollen" zu tun hat???

"AnhaengenAnVerketteListe", "Speichern" oder "Merken" wäre hier korrekte Begriffe!!
Demzufolge ist dein Prozedurname einfach sehr sehr irreführend.
"AppendToLinkedList" wäre eine wirklich passende Beschreibung für die Prozedur.

Hast mich überzeugt ;)
Werd es dann mal berichtigen.

Zitat:

@EWeiss: Die Kritik an deinen Code war nicht persönlich gemeint nur eine Konstruktive Kritik. Nehmen wir das Beispiel mit den Konstanten. Wenn du diese hart codest und sie ändern sich mal, bin ich mir zu hundert Prozent sicher, dass du nicht alle Stellen findest, wo du sie benutzt hast. Benutzt du aber eine benannte Konstante, musst du sie nur an einer Stelle im Code ändern.

Habe ich auch nicht so verstanden..
Grundsätzlich gebe ich euch ja recht.

IOResult der erste Eintrag bei Google ;)

Delphi-Quellcode:

var F: file of Byte;
begin
 Assign(F, ParamStr(1));
 {$I-}
 Reset(F);
 {$I+}
 if IOResult = 0 then
   Writeln('Dateigröße in Byte ', FileSize(F))
 else
   Writeln('Datei nicht gefunden');
end.

gruss

[himitsu]

Zitat:

Zitat von Luckie (Beitrag 1094680)

Und in IOResult steht der letzte Fehler drin?

Ja.

Sobald ein Fehler auftrat, werden alle nachfolgenden Pascal-Datei-Routinen übergangen und nicht mehr ausgeführt.
Und ist {$i} aktiviert (+), dann lößt der erste Fehler eine Exception aus und die Codebearbeitung wird unterbrochen.

Achtung: Das Auslesen von IOResult setzt den internen Fehlercode wieder auf 0. (danach werden also die Dateiroutinen wieder ausgeführt)


[add]
Jetzt weiß ich auch endlich wieder, wieso ich mal auf die saublöde Idee kam, GetLastError würde seinen Fehlercode zurücksetzen. :wall:

[Luckie]

Zitat:

Zitat von EWeiss (Beitrag 1094682)

IOResult der erste Eintrag bei Google ;)

Delphi-Quellcode:

var F: file of Byte;
begin
 Assign(F, ParamStr(1));
 {$I-}
 Reset(F);
 {$I+}
 if IOResult = 0 then
   Writeln('Dateigröße in Byte ', FileSize(F))
 else
   Writeln('Datei nicht gefunden');
end.

woher weißt du, dass die Datei nicht existiert und nur nicht geöffnet werden kann, weil sie exklusiv von einem anderen Prozess geöffnet wurde?

[EWeiss]

Zitat:

Zitat von Luckie (Beitrag 1094688)

Zitat:

Zitat von EWeiss (Beitrag 1094682)

IOResult der erste Eintrag bei Google ;)

Delphi-Quellcode:

var F: file of Byte;
begin
 Assign(F, ParamStr(1));
 {$I-}
 Reset(F);
 {$I+}
 if IOResult = 0 then
   Writeln('Dateigröße in Byte ', FileSize(F))
 else
   Writeln('Datei nicht gefunden');
end.

woher weißt du, dass die Datei nicht existiert und nur nicht geöffnet werden kann, weil sie exklusiv von einem anderen Prozess geöffnet wurde?

Es ist doch nur ein Beispiel von Google ;)
Nicht meins um die alten Schalter von Turbo Pascal zu dokumentieren.
Wie sie damals angewendet wurde.

gruss