TIniFile.ReadString erzeugt Schreibzugriff ?

[hoika]

Hallo #,

ich dachte immer, dass Windows die Ini-Dateien nur zum Lesen öffnet,
wenn ich nur per ReadString zugreife.
Der Application Verifier meckert aber und sagt, ich will Schreiben.
Der folgende Code wird angemeckert.

Ich weiss, dass Ini-Dateien out sind, aber sie sind so schön einfach
für kleinere lokale Optionen.
Ich will da nicht die Registry bemühen.

Delphi-Quellcode:

      IniFile:= TIniFile.Create(ExtractFilePath(Application.ExeName)+'App.Ini');
      try
        bMultipleInstances:= IniFile.ReadBool('Options', 'bMultipleInstances', False);
      finally
        IniFile.Free;
      end;

Heiko

[marabu]

Hallo Heiko,

probiere es mal mit TMemIniFile anstelle von TIniFile.

Grüße vom marabu

[MarcoWarm]

Zitat von hoika:

ich dachte immer, dass Windows die Ini-Dateien nur zum Lesen öffnet,
wenn ich nur per ReadString zugreife.
Der Application Verifier meckert aber und sagt, ich will Schreiben.

Scheinbar öffnet GetPrivateProfileString die Ini Datei doch nicht nur zum Lesen. Ich denke mal an diesen Routinen hat lange keiner mehr gearbeitet seit Win95. (Daher wahrscheinlich auch die Längenbeschränkung bei ReadString)

Zitat von hoika:

Ich will da nicht die Registry bemühen.

Du kannst deinen Code fast vollständig so belassen, wenn du TRegIniFile benutzt. Das ist ein Wrapper für Registry-Zugriffe auf "Ini-Art"

[hoika]

Hallo,

ja, ich weiss, der Punkt ist,
der Nutzer kann dort ein paar Sachen reinschreiben,
die das Startverhalten des Programms beeinflussen.
Aber 1. es soll keiner so ohne weiteres machen können
und 2. wenn doch, soll es einfach festzulegen sein.

TRegIniFile heisst für den Nutzer "regedit fummeln".

Naja, ich werde ihm wohl ein Form dafür spendieren müssen,
obwohl es mir nicht so passt.


Heiko

[MarcoWarm]

Zitat von hoika:

Aber 1. es soll keiner so ohne weiteres machen können
und 2. wenn doch, soll es einfach festzulegen sein.

das widerspricht sich. Egal, für diesen Zweck sind XML Dateien auch gut geeignet. Schön strukturiert und von erfahrenen Nutzern können die auch bearbeitet werden, ohne das Gefahr für das System besteht. Und wenn du es richtig anstellst, sind XMLs auch abschreckend genug, damit Laien die Finger davon lassen (was sie erfahrungsgemäß nicht tun)

[Der_Unwissende]

Hi,
ich glaube es gibt zig andere Ini-Komponenten, davon auch ein zwei recht bekannte, die eben die VCL Version ersetzen können. Da sind dann sämtliche Beschränkungen in der Größe bereits entfernt (insbesonder die 64K Grenze, soweit die in der VCL auch existiert). Einfach mal suchen, könnte sowas wie TBigIni oder so gewesen sein.

Gruß Der Unwissende

[hoika]

Hallo,

diese ini ist der Rest von altem Code.
Ich muss das eh umstellen.
Ich bin nur darüber gestolpert beim Test des Application Verifiers.

Zu XML, das löst das Problem nicht.
Ich habe die Ini ja im Programme-Verzeichnis
Und dort erlaubt der UAC von Vista keinen Schreibzugriff.

Korrektur, der Admin darf ja,
also würde das das Problem doch lösen,
wenn die XML-Kompponente wirklich nur lesend zugreift.

Aprpos:
Welche Komponente nimmt man ???
Ich kenne bisher nur die von MS direkt.


Heiko

[MarcoWarm]

Zitat von hoika:

Welche Komponente nimmt man ???
Ich kenne bisher nur die von MS direkt.

TXMLDocument
Dort kannst du als Vendor auch einen anderen als MSXML angeben. z.B OpenXML (das ist native Object Pascal)

[OldGrumpy]

Was spricht dagegen, die Ini-Datei an einen Ort mit Schreibrechten zu verlegen? Jeder User hat dafür ja sein eigenes Verzeichnis, leg dort einfach ein Verzeichnis mit Deinem Programmnamen an und speicher die Ini-Datei dort drin ab. Wir stellen hier auch gerade diverse Projekte dahingehend um...

[Muetze1]

Zitat von hoika:

Welche Komponente nimmt man ???

Für solche INI Sachen gedacht und genutzt: XMLLib

Öffnet erst zum Schreiben, wenn geschrieben werden soll...