Zugriffsverletzung

[Privateer3000]

Hi, mach ich ja...ist nur nicht sichtbar gewesen...ausserdem hab ich nun alles schon ausprobiert.
Im übrigen gibts jetzt nur noch einen Fahler wenn die ini gelesen wird.Lass ich es beim Schreibvorgang ist alles Banane.

[Christian Seehase]

Moin Privateer,

vielleicht kannst Du Dir einen Teil des Problems erleichtern indem Du die Ini nur einmal erzeugst, und nur einmal freigibst. Dazu müsstest Du dann eine globale Variable vom Typ TIniFile anlegen, und die Datei dann, am Besten wohl in der Hauptunit, initialisieren, bzw. freigeben.
Ungefähr so:

Code:

.....

var
  INI : TIniFile;

implementation

.....


initialization
begin
  INI := TIniFile.Create(....);
end;

finalization
begin
  FreeAndNil(INI);
end;

[Marco Haffner]

Tritt die Schutzverletzung eigentlich nur auf nachdem die Ini-Datei mindestens einmal geschrieben wurde oder auch direkt nach einem Neustart von Windows?
Wenn der Fehler erst auftritt wenn mindestens einmal in die Ini-Datei geschrieben wurde, könnte es sein die Pufferung von Ini-Dateien der Übeltäter für die Schutzverletzung ist. Versuche mal nachdem Du die Ini-Datei geschrieben hast einen aufruf von TIniFile.Create ohne angabe eines Dateinames:

Code:

// ... hier wird die Ini-Datei geschrieben ...

with TIniFile.Create('') do
  Free;

Jedenfalls funzt das ganze unter XP. Aber hier habe ich auch keine Schutzverletzung.
Vor einigen Jahren hatte ich aber auch einmal Probleme beim zugriff auf Ini-Dateien.

[Marco Haffner]

Oh, da hab' ich wohl etwas voreilig reagiert, habe hier noch etwas mit einem kleinen Testprogramm herumgespielt und siehe da ich erhalte eine Schutzverletzung.
Bei meinem Programm lag der Fehler das die Einstellungen im OnClick Ereignis gespeichert werden. Entferne ich das Speichern aus dem OnClick Ereignis läuft das Programm auch wieder ohne eine Fehlermeldung.

[Christian Seehase]

Moin Privateer,

ich hab' noch mal einen Blick auf Deinen Code geworfen.

Warum schreibst Du nicht einfach:

Code:

procedure TForm1.RadioGroup2Click(Sender: TObject); 
begin 
   WriteInteger('pause','mpause',RadioGroup2.ItemIndex); 
end;

Wenn ich mein voriges Posting voraussetze, kann ich mir die Freigabe der INI sparen.;-)

[Privateer3000]

KAnn ich davon ausgehen das die Ini dann die ganze Laufzeit "offen" ist?
Wenn ja, ist es glaub ich keine gute Idee.Ich glaub eher das Marco recht hat.Es ist die Pufferung.Seltsam ist nur, das dies schon beim Start geschiet.Bis heute hab ich keine vernünftige Lösung.
Bis auf das ich die Einstellungen in der Reg speichere.Damit hatte ich noch gar kein Problem.

Grüsse
Privateer

[Christian Seehase]

Moin Privateer,

in der Hoffnung, dass ich jetzt (nach 6 Wochen ;-)) an der richtigen Stelle anknüpfe:

Wenn Du im initialization die INI erzeugst, und in finalization wieder schliesst, ist sie die ganze Zeit offen, aber was stört Dich daran?

Was so das Speichern von Einstellungen angeht verfahre ich allerdings doch noch etwas anders. Ich benutze dazu ein Objekt, dessen Properties den Einstellungen entsprechen, und dass dann die Werte durch Get- und Setmethoden ausliest bzw. speichert. Ob sich die Daten dann in der Registry oder einer Datei (ini, oder was auch immer) befinden lässt sich dann relativ leicht ändern.

[Marco Haffner]

Ich häng' mal ein Beispiel an (sind einentlich 3).
Bei dem ersten tritt eine Schutzverletzung auf, bei den anderen
zweien nicht.

Die Datei ist ca. 7KB groß, hast Du WinRAR 3, dann wären's nur 3KB.

[Daniel B]

Zitat:

Zitat von Marco Haffner

Die Datei ist ca. 7KB groß, hast Du WinRAR 3, dann wären's nur 3KB.

Ich denke das er es selbst mit einem Handy überleben würde. :roll: :mrgreen: :shock:

[Marco Haffner]

:?
Und da hab' ich noch nicht mal ein Handy.