Beispiele, Gedanken und Tipps bei der Nutzung von INI-Dateien

NAja,

fangen wir mal der Reihe nach an.

Bei mir ist die Namenskultur so, dass die "Haupt INI" immer wie das Programm heißt. Ist der Name also mach_mal.exe heißt die INI mach_mal.ini. Die *.exe und die ini liegen immer im gleichen Verzeichnis.

Hier packe ich alles rein, was sich mal schnell ändern könnte. Z.B. der Name eines Hilfsprogramms, oder wenn ich CSV dateien erstelle, der Trenner. Ich benutze bevorzugt ; brauche aber tatsächlich ab und an mal ,

usw. usw.

inis sind für mich einfache Textdateien. Die Gliederung [10] usw.. benutze ich zwar - ist aber eigentlich (für mich) verzichtbar.

LG

Peter

Für mich gilt ganz klar:

- Ini-Datei für Programmeinstellungen,

- Alles andere (in der Regel XML), wenn die Daten eine richtige Strucktur brauchen, mit mehreren Unter"verzeichnissen" (Knotenpunkten,...).

Moombas was ist alles andere?

LG

Peter

Peter S. Taler Damit waren alle anderen Methoden (XML, JSON, Registry und ggf. noch weitere) gemeint, die man dafür nutzen könnte.

Moombas

ok da war meine Ausdrucksweise missverständlich. Ich meinte nicht die Methoden, sondern die Inhalte. Ich kann mir immer nur schwer vorstellen, was man einem Programm sonst noch so mitgeben möchte. Wobei ich auch schon mal csv. Datensätze einfach in die ini schreibe...

Peter

SOLVE-SMART

ich glaub wir reden aneinander vorbei.

Als Beispiel steht in der Ini.

[10]

Artikelpreis_1 = 47.00;57,00;67,00 (Anmerkung wobei Preis1 = ab100 Stück, Preis2 ab 10 Stück Preis 3 ab 1 Stück.

Artikelpreis_2 = 27,10;30,22;85,22

[20]

artikelnummer_1 = 4711_so_köln_klein_2

usw

usw.

nun nimmst Du ein iniread und liest das ganze in z.B. Variablen ein

$_Artikelpreis_1 = iniread ("test.ini", "10", "Artikelpreis_1")

$_Artikelpreis_2 = iniread ("test.ini", "10", "Artikelpreis_2")

Mann kann stundenlang alles einlesen lassen. Letztlich nur eine Frage was geht schnell und wie kann man Daten von A nach B schaffen.

LG

Peter

Nunja, grundsätzlich ist eine INI das, was der Name suggeriert: eine Initialisierungsdatei.

Also gehören dort in erster Linie Angaben rein, die zum Start des Programms erforderlich sind bzw. zu dessen Modifikation durch den Anwender.

Da INIs einfach zu händeln sind, werden sie auch oft als kleine Datenbanken *missbraucht*. Das ist auch nicht verwerflich, wenn es klein und übersichtlich bleibt. Wie Peter S. Taler schrieb, ist hier die Frage der Geschwindigkeit maßgebend.

Meine Programme laufen grundsätzlich nur als *.exe, wenn sie den Produktions / Testraum verlassen haben.

Niemand geht her und schreibt csv Datein in *.inis, wenn man das auch als csv Datei einlesen kann. ABER manchmal macht es Sinn ein paar Daten in die *.ini zu schreiben. Macht manches übersichtlicher und man hat alle Daten in einer Datei zusammen.

Niemand behauptet, dass mein Vorgehen in Sachen Ablage und Benennung eine allgemeingültige Regel ist - aber es funktioniert, seit Jahren. Gerade für Anfänger halte ich dergleichen Ratschläge für angebracht - denn wir selbst haben oft Jahre gebraucht um uns das eine oder andere Standardvorgehen anzueignen. Mühsam gelernt durch lesen im Netz und Beispiele hier im Forum.

Wer es besser / anders machen will - nichts spricht dagegen - aber ein Anfangsvorschlag kann nie schaden. Ja man kann sich für alles "entschuldigen" - muss man aber nicht.

Manchmal ist auch nicht klar welche Daten in die *.ini gehören und welche nicht. Oft stehen Dinge drin, die man auch als const. in den Source hätte schreiben können - hätte man es vorher gewusst. Aber was solls sie stehen meist auch in der *.ini gut.

Peter

Zitat von Peter S. Taler

Moombas

ok da war meine Ausdrucksweise missverständlich. Ich meinte nicht die Methoden, sondern die Inhalte. Ich kann mir immer nur schwer vorstellen, was man einem Programm sonst noch so mitgeben möchte. Wobei ich auch schon mal csv. Datensätze einfach in die ini schreibe...

Peter

Peter S. Taler Also CSV-Daten würde ich nie auf die Idee kommen in eine Ini zu schreiben, wobei wenn es aus Konfigurationssicht Sinn macht und nur ein kleiner Datensatz ist, evtl. schon. Aber ich glaube ich würde das dennoch dann separieren.

Es kann auch sien das du die Konfiguration auf Grund der Strucktur des Programms anordnen möchtest und dies auch Sinnig ist (hatte bisher nur ein externes Programm wo das der Fall war), da macht es evtl. mehr Sinn dies auch entsprechend abzulegen ohne die Sektionsnamen in einer INI-Datei immer weiter zu verlängern etc.

Peter S. Taler Ich schreibe zu dem Thema INI hier weiter wenn es recht ist.

Es ist gut zu wissen mit der INI-Datei eine entsprechend konfigurierte .exe noch ändern zu können bzw. Einstellungen vorzunehmen.

Danke für diesen Hinweis.

Vermutlich werde ich es eher selten brauchen, da ich meistens mit der au.3 arbeite.

Also auf zur Praxis: *Händereib*

Ich habe eine Test.au3, Test.exe und eine Test.ini auf dem Desktop erstellt.

In der Test. exe ist Dein Code hinterlegt: (geht INI auch mit au.3? Tippe auf ja)

Const $programm_name = 'Test' ; der name des Programms

Global $start_dir ; Start Directory des Programms


; --- Pfaden Anfang ----

if stringlen(@ScriptDir) <= 3 Then

$Start_dir = Stringleft (@ScriptDir, 2)

Else

$Start_dir = @ScriptDir

EndIf

 MsgBox (0, "Start Dir", $Start_dir)


Const $ini_pfad = $start_dir &'\' & $programm_name & '.ini'


;------ Pfaden Ende

; Pfaden muss sein, da dder Befehl @ScriptDir z.B. bei F -> F:\ also mit dem schrägen liefert bei F:\test -> eben den schrägen

; nicht liefert.Damit würden Pfadzusammensetzungen unterschiedlich ausfallen. Eine Autoit Ungereimtheit, die man mal beseitigen

; könnte.


; Ini Read Anfang

Global $_trenner = (iniRead ($ini_pfad, "10", "trenner", "IniFehler")) ; einlesen des Trenners

MsgBox (0, "Trenner", $_trenner)

; Ini Read Ende

Was schreibe ich denn jetzt in die INI?

$_trenner = ;sowieCsvTrenner = ; bringt: "Ini Fehler".

Edit: Ich muss mal $_trenner = ";" versuchen.

Also der Reihe nach.

In Zeile 1 wird der name des Programms festgelegt. Dieser Name wird später für den Pfad und den Namen der *.ini verwendet. z.Z steht da test --> der Name ist test.ini

in Zeile 21 wird festgelegt, dass der Pfad zur test.ini so gewählt ist, dass die ini im GLEICHEN PFAD zu liegen hat wie die *.exe oder au3.

in Zeile 35 wird festgelegt in welchem Kapitel das steht hier KApitel 10 der ini und danach ist festgelegt wie die ini Bezeichnung ist.

Wenn du also in der ini wie folgt stehen hast

[10]

trenner = ;

und die ini test.ini heißt und im gleichen Verzeichnis liegt wie Dein Program ---> funktioniert das tadellos...

Alles klar?

Ach ja. Ich gebe zu dass das ein wenig blöd ist ... ich lege zwar in zeile 1 den programmnamen fest aber tatsächlich gibt es keinen Zusammenhang zwischen dieser Festlegung und dem tatsächlichen Programmnamen. Dieser könnte auch qwr_test sein ABER die *.ini muss tatsächlich IMMMER so heißen wie der angegebene name in zeile 1.

Hoffe Du kommst damit zurecht

LG

Peter

Sorry ich sehe da keinen Unterschied - liegt aber vielleicht daran dass ich farbenblind bin

Hochachtungsvoll

Peter

ich persönlich nutze die ini funktion von autoit nicht.

ich nutze meine eigne Funktion, indem ich zwar das ini Format nutze aber dort dann auch um Strings abzulegen die nicht alle sehen sollen, auf Wunsch liest meine func eigne verschlüsselte Dateien aus die im unverschlüsseltem zustand so aufgebaut sind wie eine ini datei, egal ob *ini *txt selbst erstellte Datei Formate.

Das reicht mir bisher wenn ich zeit finde baue ich auch noch einen wirter da könnte ich von @Alina aus dem theard 'INI Eintragen'   umbauen und auf meine Bedürfnisse anpassen.

Ansonsten nutze ich auch noch das Format um von einem Programm Zuweisungen auf ein Fremdes Programm IDs miteinander zu verbinden.

Da ich auch öfter mit INI-Dateien arbeite habe ich zwei Verschiende Verwendungszwecke:

1.) klassisch: Im INI-File stehen Daten wir Pfade, Werte oder Einstellungen für ein Programm. Das Programm verwendet jemand anders und kann den Sourcecode nicht einsehen. Damit aber z.B.: Serverdienste deinen ein AutoIT Programm verwendet wird angepasst werden kann, lege ich eine INI-Datei an.

2.) Für eine Berechnung von Buchhaltungsdaten habe ich ein INI-File missbraucht um Umsätze in Einnahmen und Ausgaben und das pro Monat aufzuteilen. Es war halt zu verlockend die Section zu als Ablage zu verwenden um später den Output (PDF) leichter zu generieren.

Ich sehe den Vorteil von INIs das es viele Programmier- oder Scriptsprachen leicht lesen können. Für ein Projekt wo ich in AutoIT schreibe, der Kollege in Powershell und der Dritte seine VB-Scripts anpasst sind die INIs von ganz großer Bedeutung: Ich schreibe Werte rein, das nächste Tool liest es aus....gibt sicher 1000 andere Möglichkeiten, aber das war am einfachsten.

Aber ich bin auch schon an die Grenzen von INI-Files gestossen: Ich wollte einige tausend Einträge machen (+-18000) und das hat nicht mehr funktioniert!

Mit Json stehe ich ganz besonders auf Kriegsfuß und XML ist auch nicht meines....da schreibe ich lieber im Binärcode in die Registry

lg

Racer

jup so isses. Man kann die ini sogar verschlüsseln und so "halbwegs" sichere Daten ablegen. Klar das hällt Profis nicht ab - für den Alltag ist es allemal genug. ..... Mit Json stehe ich ganz besonders auf Kriegsfuß und XML ist auch nicht meines..... jaaaa!

Vielleicht eine Frage des Standpunktes aber manchmal frage ich mich ... warum darf es nicht einfach sein?

lg

Peter