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

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

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:

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:

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:

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:

Zitat von hoika

Welche Komponente nimmt man ???

Für solche INI Sachen gedacht und genutzt: XMLLib

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

[himitsu]

Also ich bin auf TMemIniFile umgestiegen.

Erstens öffnet TIniFile anscheinend immer mit Schreibrechten (wie bemerkt)
und dann wird die Datei bei jedem Zugriff (jedem Read.../Write...) geöffnet, gelesen/geschrieben und wieder geschlossen, was nicht gerade schnell ist - vorallem bemerkbar wenn die INI auf 'nem langsamen Datenträger liegt.

(TIniFile.Create hinterlegt nur den Dateinamen im Objekt)



TMemIniFile ließt bei TMemIniFile.Create die Datei einmalig (mit Leserechten) aus, der Rest läuft alles in der Kopie im RAM ab.
Geschrieben wird nur in Ini.UpdateFile.

[Der_Unwissende]

Zitat:

Zitat von himitsu

Erstens öffnet TIniFile anscheinend immer mit Schreibrechten (wie bemerkt)
und dann wird die Datei bei jedem Zugriff (jedem Read.../Write...) geöffnet, gelesen/geschrieben und wieder geschlossen, was nicht gerade schnell ist - vorallem bemerkbar wenn die INI auf 'nem langsamen Datenträger liegt.

Wobei hier auch klar betont werden sollte, dass du damit immer alle Änderungen sofort stattfinden, man also immer auf der selben Datenbasis arbeitet und alle Änderungen sofort gespeichert werden (irgendwer hat da schon in anderen Threads immer wieder drauf aufmerksam gemacht). Ein TMemInifile ist sicherlich bei reinem Lesen geeigneter, aber auch hier könnte ja eine zweite Anwendung ein Datum in der Ini verändern ohne dass man dies bemerkt und Änderungen werden nur mit dem Update geschrieben (dass z.B. bei einem Fehler nicht immer aufgerufen wird).

[hoika]

Hallo,

TMemIniFile habe ich jetzt eingebaut.
Jetzt meckert der app verifier nicht mehr ;)

Aber. Schreibzugriff auf Registry (HCLM) irgendwo bei Multimedia (Joystick).
Also ich bin das nicht !!!
Was zur Hölle macht Delphi da,
mit Multimedia hat mein Programm überhaupt nix zu tun.
Das ist schon im RTL-Code! Sauerei! :wall: :wall:


Heiko