INIFile.ReadSections führt zum Abstrakten Fehler

[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

[mkinzler]

TStrings ist eine abstrakte Klasse:

Delphi-Quellcode:

MySections := TStringList.Create;

[Luckie]

Zitat:

Zitat von mkinzler

TStrings ist eine abstrakte Klasse

Das heißt deren Methoden sind nicht implementiert, sondern nur virtuell vorhanden und werden erst von den Nachfolge-Klassen mit Leben gefüllt.

PS: Eine Forensuche hätte dir aber auch sagen können, was du da falsch machst.

[gmc616]

Okay. TStrings ... abstrakte Klasse ... kapiert!

Aber ich werd doch bekloppt!

Selbst wenn ich TStrings zu TStringList ändere, knallt der Code in der besagten Zeile. Zwar nicht mit einem Abstrakten Fehler sondern mit einer Schutzverletzung.
Da ich die Schutzverletzung für einen Fehler meinerseits hielt, habe ich es mit TStrings probiert und der Abstrakte Fehler erschien mir "glaubwürdiger". Deshalb der Post.

Jetzt hab ich das ganze mit Delphi7 und TStringList probiert, da funktionierts. Mit BDS2006 bekomme ich die Schutzverletzung.
Datt will mir nicht in den Schädel :wall:

:hi: gmc

[Assertor]

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

Delphi-Quellcode:

TIniFile.Create(ChangeFileExt (Application.ExeName,'.ini'));

Ist ja nicht gerade 100%.

Besser

Delphi-Quellcode:

TIniFile.Create(ChangeFileExt(ParamStr(0), '.ini'));

Nur aus dem Kopf - müßte stimmen...

Gruß winkel79

[gsh]

ne ob Applictation.ExeName oder Paramstr(0) ist egal da es des genau gleich ist.

Teste des einmal so:

Delphi-Quellcode:

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

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

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

  MySections.Free;
  MyIni.Free;

end;

wenns nicht geht test mal ob MyIni.ReadString(irgendwas, ..) geht

[gmc616]

Genau das ist auch mein Code.

Es knallt in besagter Zeile.

MyIni.ReadString (...) funktioniert, auch das Lesen von Bool, Integer usw. sowie das Schreiben. Nur das Lesen der Sections macht Probleme. Daher der Verdacht, dass es an den TStrings liegt. Aber das haben wir ja geklärt.

Irgendwo hier im Forum hab ich eine Alternative zum Lesen der INI-Sections gefunden, aber das ist ja nicht Sinn der Sache.

So langsam glaub ich auch mein BDS hat ne Macke, denn auch die IDE läßt sich nicht korrekt beenden (Schutzverletzung), obwohl der Rechner an sich sehr stabil läuft. :evil:

:gruebel:

[Progman]

und functioniert ReadSectionValues ?
Ich glaub auch fast, dein Delphi ist kaputt ;)

[RavenIV]

Wie sieht denn Deine ini aus?

Ich hatte mal den Fall, dass ich sowas in einer ini geschrieben habe.

Zitat:

...
...
[MISC]
Groesse=100 // dies ist die Grösse des Fensters,
die am Anfang gesetzt wird
Titel=Fenster für Optionen // Der Fenstertitel
wird ganz oben angezeigt
...
...

Das ReadInteger und ReadString hat funktioniert, da wurde der "Kommentar" ignoriert.
Aber das ReadSections hat nicht wollen und das Programm ist abgeschmiert mitsamt der Delphi7-IDE.
Dabei hat er sich am Zeilenumbruch gestört, vermutlich beim Integer-Wert.
Nachdem ich die "Kommentare" alle entfernt habe, ist es dann gelaufen.

[Progman]

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

[Daniel Schuhmann]

Zitat:

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:

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:

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 ... :gruebel:

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

Danke an alle

:hi: 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:

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

Delphi-Quellcode:

MySections := TStringList.Create;

statt mit

Delphi-Quellcode:

MySections := 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:

Zitat von Daniel Schuhmann

Zitat:

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.