INIFile.ReadSections führt zum Abstrakten Fehler

[Daniel Schuhmann]

Zitat von winkel79:

Und du bist sicher, daß er die INI findet?

Selbst wenn er sie nicht findet, darf es nicht "knallen", die Stringliste wäre einfach nur leer.

[Progman]

wenn er sie nicht findet, kommts zum Crash in der ntdll.dll, jedenfalls meistens

[RavenIV]

Zitat von Progman:

RavenIV: stimmt, das kann zum crash führen.
Kommentare in Ini's nur mit ; am Anfang einer Zeile, das wird akzeptiert.

Stimmt, ich glaube, ich hatte das mit

Zitat:

Groesse=100 ; dies ist die Grösse des Fensters,
die am Anfang gesetzt wird

geschrieben.

[Daniel Schuhmann]

Zitat von Progman:

wenn er sie nicht findet, kommts zum Crash in der ntdll.dll, jedenfalls meistens

Nein, beim Lesen nicht, nur beim Schreiben.

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  Ini: TIniFile;
  SL: TStringList;
begin
  Ini := TIniFile.Create('NUL');
  SL := TStringList.Create;
  Ini.ReadSections(SL);
  SL.Free;
  Ini.Free;
end;

procedure TForm1.Button2Click(Sender: TObject);
var
  Ini: TIniFile;
begin
  Ini := TIniFile.Create('NUL');
  Ini.WriteString('Test', 'Test1', 'Val1');
  Ini.Free;
end;

Nur bei der Schreibroutine kracht es. Wenn beim Lesen ein Fehler auftritt, wird der Standardwert angenommen.

[Progman]

Ok, stimmt, hast recht

[gmc616]

Also, ich hab keine Ahnung was der Grund für den Fehler ist.

Es hat sich allerdings heraus gestellt, dass mein BDS generell Probleme mit TStringlists bzw. TStrings zu haben scheint. Einige meiner Programme machen plötzlich Probleme wenn ich sie mit dem z.Z. installierten BDS compiliere. Immer wieder stürzen sporadisch die Anwendenung ab, wenn ich z.B. Dateien in TStringlisten laden. Der gleiche Code auf einem anderen Rechner mit D7 compiliert, funzt problemlos.

komisch komisch ...

Ich werd mal das BDS platt machen und Neuinstallieren. Mal sehn obs was hilft ...

Danke an alle

gmc

[ulhau]

Guten Morgen gmc616!

Ehe du dein BDS platt machst, probiere doch mal das kompilierte Programm (die StringListvariante)ohne IDE auszuführen. Manchmal macht Inifiles so seltsame Sachen wenn das Programm innerhalb der IDE getestet wird. Aber bei der Ausführung ohne IDE gibt es dann meistens keine Probleme mehr.

Jedenfalls die Stringlistvariante hat keine Probleme gemacht als ich das Programm standalone ausgeführt habe, obwohl die gleichen Fehler beim ausführen innerhalb der IDE wie bei dir aufgetreten sind. (Die Ini war natürlich eine andere.)

Tschüssss

[SM3D]

Zitat von gmc616:

Namd DP,

ich glaub ich werd bekloppt!

Könnt ihr mir verraten warum dieser Code zu einem Abstrakten Fehler führt? (BDS2006)

Delphi-Quellcode:

uses IniFiles;

[...]

procedure TForm1.Button1Click(Sender: TObject);
var
  MyIni : TIniFile;
  MySections : TStrings;
  I: Integer;
begin
  MySections := TStrings.Create;
  MyIni := TIniFile.Create(ChangeFileExt (Application.ExeName,'.ini'));

  MyIni.ReadSections(MySections);  // <-- Hier knallts !!

  for I := 0 to MySections.count - 1 do
    ShowMessage (MySections.Strings[i]);

  MySections.Free;
  MyIni.Free;

end;

Isses schon so spät, dass ich's nicht sehe??

Danke und Grüße
gmc

Grüsse,

ich würde es mal mit
MySections := TStringList.Create; statt mitMySections := TStrings.Create; probieren, hab Dein Beispiel nachgestellt und eins A geklappt, mit Deinem Code kommt Abstrakten Fehler, wenn Du Mein Beispiel nimmst kommen in ner MessageBox die Sections

MfG SM3D

[Muetze1]

Zitat von Daniel Schuhmann:

Zitat von Progman:

wenn er sie nicht findet, kommts zum Crash in der ntdll.dll, jedenfalls meistens ;)

Nein, beim Lesen nicht, nur beim Schreiben.

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  Ini: TIniFile;
  SL: TStringList;
begin
  Ini := TIniFile.Create('NUL');
  SL := TStringList.Create;
  Ini.ReadSections(SL);
  SL.Free;
  Ini.Free;
end;

procedure TForm1.Button2Click(Sender: TObject);
var
  Ini: TIniFile;
begin
  Ini := TIniFile.Create('NUL');
  Ini.WriteString('Test', 'Test1', 'Val1');
  Ini.Free;
end;

Nur bei der Schreibroutine kracht es. Wenn beim Lesen ein Fehler auftritt, wird der Standardwert angenommen.

Also wer auch einen illegalen und verbotenen Dateinamen verwendet, da ist es kein Wunder das es kracht. Afaik sollte es sogar hier durch den Dateinamen bei beiden Aufrufen knallen.

Siehe auch MSDN: File Names, Paths, and Namespaces dort unter Basic Naming Conventions. Warum sollte jedem DOS/Shell Nutzer bekannt sein.