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

  • Hi MojoeB,

    Danke dir für dein Statement zur Verwendung des INI Formats 👍 .

    [...] 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. [...]

    Hier würde mich interessieren wie genau das bei dir aussieht? Falls du Lust und Zeit haben solltest, würde ich mich über ein Beispiel freuen, klingt interessant 😀 .

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

    Auch hier wäre ein Beispiel ziemlich hilfreich. Ich habe zwar ein Bild vor Augen, was du das tust, jedoch ist es anderen ggf. nicht ganz klar, was du damit meinst.

    [...] 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. [...]

    Auch dir Racer Danke für deine Beschreibung und Einschätzung 👍 . Ich teile deine Meinung für den von dir beschriebenen Anwendungsfall schon => "Programmier- oder Scriptsprachen können leicht mit INIs umgehen". Doch für andere Anwendungsfälle1 gilt es meiner Wahrnehmung nach nicht, das der Umgang mit INIs einfacher ist als der mit JSON, XML oder YAML.

    Ich versuche, nachdem ich auch ein ganz konkretes INI-Verwendungsbeispiel mal aufgezeigt habe, euren Input und den der anderen hier Beitragenden zusammenzufassen und es im post #1 aufzubereiten/darzustellen 😀 .


    Viele Grüße
    Sven

    1 Ich nehme Bezug auf "Frage/Anregung/Beispiel" im post #10 (ganz unten).

  • SOLVE-SMART

    Ich hab leider festgestellt das die Version die ich zuhause habe fehlerhaft ist.

    Auf der Arbeit funktioniert die Funktion die ich selber gebaut habe. Da ich mir die mühe nicht zweimal machen will, hol ich die Tage die Funktion von der Arbeit und ändere Sie nochmal um.

    weil ich etwas festgellt habe als ich mit dieser Version die ich zu hause habe, dass ich da noch etwas abändern kann um fehler beim auslesen zu vermeiden ^^.

  • MojoeB
    Wenn es zuhause nicht einwandfrei arbeitet oder gar nicht, stellt sich mir die Frage, was der Unterschied zwischen "Zuhause" und "Arbeit" ist?

    Lieben Gruß,
    Alina

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Geheime Information: ;)
    OuBVU5ebLhHu5QvlnAyQB4A7SzBrvWulwL7RLl2BdH5tI6sIYspeMKeXMSXl

  • Auf der Arbeit funktioniert die Funktion die ich selber gebaut habe. Da ich mir die mühe nicht zweimal machen will, hol ich die Tage die Funktion von der Arbeit und ändere Sie nochmal um.

    Nur die Ruhe MojoeB. Aus meiner Sicht keine Eile, ich schrieb ja extra "[...] Falls du Lust und Zeit haben solltest [...]"

    Wenn es zuhause nicht einwandfrei arbeitet oder gar nicht, stellt sich mir die Frage, was der Unterschied zwischen "Zuhause" und "Arbeit" ist?

    Ich glaube er meint das der Code-Stand auf der Arbeit ein anderer (neuerer) ist, welcher funktioniert und zu Hause hat er einen alten Stand.
    So habe ich es zumindest verstanden 😀 .

    Viele Grüße
    Sven

  • Hi zusammen 👋 ,

    wie angekündigt hier endlich das konkrete Beispiel von mir, zu einer Möglichkeit wie man mehrere INIs verwenden/nutzen kann.


    💡 Wichtig zu wissen ist:

    • Allgemein, gehe ich davon aus, dass das jeweilige Programm/Skript (unabhängig vom folgenden Beispiel) zu einer Exe kompiliert wurde und somit kein direkter Einfluss auf das Programm gegeben ist bzw. der Code nicht einfach geändert werden kann.
      • Denn ansonsten braucht es auch keine INI, wenn man es direkt im Code konfiguriert.
    • Nutzer, der Anwendung (wie Dritte, Außenstehende (Stakeholder bspw.)), kennen sich mit dem Programm und dessen Code nicht aus, wollen jedoch dennoch etwas am Programm beeinflussen/ändern.
      • Dies wäre eine Verwendung von Konfigurationsdateien, wie einer INI.
      • Eine weitere Verwendung ist ein Deployment der Anwendung auf verschiedene Server/Maschinen mit verschiedenen Konfigurationen.
    • Das folgenden Beispiel ist bitte auch als Beispiel zu betrachten. Es soll nur darstellen, wie INIs zur Konfiguration dienen/genutzt werden können.
      • Also bitte keine Hinweise das dies oder jenes nicht sinnvoll ist oder keinem echten Anwendungsfall entspricht.
      • Wobei ich mir Mühe gegeben habe, es nicht zu trivial zu gestalten 🤞 .

    🎲 Werden wir mal etwas konkreter. Um meinem Beispiel zu folgen, kann mittels folgendem Skripts die Struktur (Ordner- und Datei-Struktur) angelegt werden.

    Hiermit wird auf dem Desktop das Verzeichnis ini-demo angelegt. Danach kann die Main.au3 (das eigentliche Beispiel) verwendet werden. Oder man kompiliert das Programm und führt die Exe im build Verzeichnis aus.


    👓 Das Ganze sieht dann so aus:

    Es gibt die settings.ini welche allgemeine Einstellungen beinhaltet, aber auch die Schlüssel "Environment", dessen Wert festlegt welche spezifische Konfiguration (eine weitere INI-Datei) verwendet werden soll. Hierbei gibt es den Wert test-env und prod-env. Je nachdem was in der settings.ini ausgewählt wird, sieht die GUI (welche ich zur Darstellung des Beispiels verwende) unterschiedlich aus.


    👓 test-env:

    👓 prod-env:

    (1) Der erste Anwendungsfall ist somit die Verwendung von Sub-Konfigurationen, die spezifisch für eine Umgebung gedacht sind. Der Wechsel des Wertes, vom Schlüssel "Environment", in der settings.ini bewirkt die unterschiedlichen Darstellungen und angezeigten Labels, je nach Umgebung. Greifbarer ist sicherlich die Datenbankverbindung, welche mit ConnectionStringDb in der jeweiligen Sub-INI (test-env.ini oder prod-env.ini) dargestellt ist.

    (2) Als zweites Beispiel für die Verwendung von INIs greife ich hier das Aktualisieren von Texten der GUI, zur Laufzeit des Programmes auf. Also wenn der Button "Text anzeigen" gedrückt wird, aktualisiert sich der Label-Text, welcher in der jeweiligen INI hinterlegt ist. Anders als beim Beispiel (1), bei dem nur einmalig die INI-Werte (der Sektionen "GUI" und "Database") gelesen werden, wird hier im Beispiel (2) die INI immer erneut befragt und liefert den dort geänderten Text zurück.


    👓 INI-Nutzung zur Laufzeit:

    Animiertes Bild zum Verständnis (GIF)

    💡 Dies ist zunächst ein Zwischenstand. Ich werde diesen post sicherlich nochmal umformulieren und weiter beschreiben, jedoch erhoffe ich mir jetzt bereits, dass es verständlich ist. Ich freue mich über euer Feedback, Kritik in jeglicher Form oder einfach über Fragen dazu 🤝 .

    Viele Grüße

    Sven

  • Ich nutze INI´s u.a. um in Programmen die komplette Lokalisierung einzustellen, ohne dafür den Programmcode ändern zu müssen.

    Dabei gibt es in der INI u.a. Abschnitte, welche die komplette Beschriftung der Buttons, Menüs, Labels, Hilfetexte usw. enthalten.

    Die Sprachauswahl erfolgt über das Traymenü des Programms, welches sich (ohne Programmneustart) aktualisiert, sobald es per Rechtsklick aufgerufen wird.

    Wir setzen im Unternehmen in der Produktion auch Leiharbeiter ein, die dazu auch noch oft als "Springer" an den verschiedensten Arbeitsplätzen aktiv sind. Diese Mitarbeiter kommen aus allen möglichen Ländern und haben entsprechend ihre eigene (Mutter-)Sprache. Viele sprechen deutsch, bei den Fachbegriffen ist es dann aber schwierig.

    Meine Erfahrung hat gezeigt, dass es bei der Einarbeitung wesentlich einfacher ist, dem Mitarbeiter in seiner Muttersprache einen Vorgang/Begriff deutlich zu machen.

    Um eine "neue" Sprache in der INI anzulegen, wird der deutschsprachige Bereich der Lokalisierung kopiert und in die neue Sprache übersetzt. Sobald die INI gespeichert wurde, ist die neue "Sprache" auf allen Rechnern im Netz ohne Programmneustart per Rechtsklick im Tray verfügbar.

    Dieses Verfahren setze ich nicht nur in AutoIt ein, sondern auch in VBA. Da VBA so etwas wie #include nicht kennt, benutze ich Textdateien in verschiedensten Bereichen.

    Der mMn. positivste Nebeneffekt dabei ist, dass man sich als Programmierer Gedanken macht, warum und ob bestimmte Programminteraktionen überhaupt nötig sind und wie man diese dann eliminieren kann. Das führt zu WESENTLICH geringerer Fehlerquote und einem schnelleren Arbeitsablauf.

    Das fließt natürlich auch in meine Neuprogrammierung ein, was seitens externer Programmierer, die bei uns ab und zu reinschauen (und sich anfangs über meine, als "Nebenbeiprogrammierer" benutzte "oldschool"-Programmierung lustig machten), schon zu reichlich Überraschungen gesorgt hat.

    Mich hatte einmal der Geschäftsführer einer Branchensoftware in Begleitung seiner TOP 5 Programmierer gefragt, wieso ich (mittels AutoIt) einige neue Buttons in SEINE Software eingefügt hatte.

    Daraufhin fragte ich ihn, welcher seiner Mitarbeite JEMALS mit SEINER Software konstruktiv gearbeitet hatte! Unverständnis pur^^. Daraufhin hatte ich in SEINER Software demonstriert, dass es 19 (neunzehn) Interaktionen, d.h. Tastatureingaben/Mausklicks bedarf, um den aktuell bearbeiteten Vorgang als Begleitpapier auf dem Drucker auszudrucken. Das was jeder unserer 12 Mitarbeiter in diesem Bereich ca. 20x bis 30x am Tag ausführen muss. Benötigte Zeit dafür (je nach Server/Datenbank/Netzwerklast) 60-80 Sekunden. Stattdessen nur EIN Klick auf den "neuen" Button in der Buttonleiste, und 20 Sekunden später liegt das Papier im Drucker...

    Einsparung pro Jahr: 0,5 Stunden pro Mitarbeiter pro Tag mal 12 Mitarbeiter mal 200 Arbeitstage im Jahr sind 1200 Stunden aka 30 Mann-Wochen pro Jahr! Das ist fast ein kompletter Mitarbeiter, dessen Ressourcen freigeschaufelt werden konnten, so dass er "wichtige" Aufgaben erledigen kann!

    Daraufhin meine Frage an die anwesenden "Profis": Wieso muss ich als Anwender mir Gedanken über die Optimierung bzw. den Ablauf einer Software machen und warum wird das nicht von vornherein von den Programmierern erledigt?!

    Statt sich weltweit auf SCRUM-Events rumzutreiben und sich mit "agiler" Softwareentwicklung selbstzubeweihräuchern, sollten sich Programmierer doch eigentlich (was einer der Grundsätze der Agilität ist!) um die Kundenwünsche/anforderungen und deren unkomplizierte Umsetzung als Ziel einer Softwareentwicklung kümmern?!

    Etliche Vorgänge könn(t)en durch einfachste Mittel verbessert werden, gut gemachte INI-Dateien sind die Grundlage für gute Programme mit unterschiedlichsten, ggf. sogar vom Anwender steuerbaren, Konfigurationen.

    Und zum Thema INI sei "oldschool" (heutzutage fliegt ja alles in eine Datenbank). Wenn mein Programm nicht per se schon eine Datenbankanwendung ist/hat, dann sollte man für einige Handvoll Parameter nicht unbedingt eine anlegen....

    Nutzer, der Anwendung (wie Dritte, Außenstehende (Stakeholder bspw.)), kennen sich mit dem Programm und dessen Code nicht aus, wollen jedoch dennoch etwas am Programm beeinflussen/ändern.

    Dies wäre eine Verwendung von Konfigurationsdateien, wie einer INI.
    Eine weitere Verwendung ist ein Deployment der Anwendung auf verschiedene Server/Maschinen mit verschiedenen Konfigurationen.

    THIS!

  • Oh wow Andy 👍 ,

    ich bin bei vielen (fast allen) deiner Ausführungen bei dir und dein plakatives Beispiel ist absolut einleuchtend, da gibt es nichts hinzuzufügen. Dennoch kann nicht alles mit simplicity gelöst und umgesetzt werden - es hängt von vielen Faktoren ab, wie komplex eine Anwendung sein muss/wird. Bzgl. der reinen Idee des Threads => "INIs", ist dein Beitrag Gold wert, vielen Dank 🤝 .

    Noch eines bzgl. Agile, aktueller Software-Entwicklung usw.:
    Es gibt so viele Adaptionen des Agile/Scrum-Manifests, dass es unweigerlich zu Problemen bei dem einen oder anderen Team kommen muss.
    Daher empfiehlt es sich ja an Design Pattern und Clean Code Pattern (KISS, DRY, ...) zu orientieren.

    💡 An dieser Stelle breche ich jedoch das Thema ab, denn das passt hier nicht her und sprengt absolut den Rahmen 😅 .

    Fazit: Danke für deine ausführlichen Gedanken und Einschätzungen 👍 . Dies ist absolut hilfreich für INI-Unerfahrene, meiner Meinung nach.

    Viele Grüße
    Sven

  • Es gibt so viele Adaptionen des Agile/Scrum-Manifests, dass es unweigerlich zu Problemen bei dem einen oder anderen Team kommen muss.

    Du weißt ja, wie man TEAM definiert?! Tu´s Ein Anderer Mal!

    Dies ist absolut hilfreich für INI-Unerfahrene

    Ich hatte, auch hier im Forum, schon reichlich Scripte gesehen, bei denen INI-Dateien (falsch, die AutoIt´schen INI-Funktionen) missbraucht wurden, weil die Scripter schlicht nicht in der Lage sind/waren einfachste Textdateien zu bearbeiten bzw. die String-Bearbeitungsfunktionen zu benutzen.

    Da werden/wurden dann die INI-Funktionen als FileWrite() bzw. FileRead()-Ersatz genutzt. Mir dreht sich da der Magen um...aber wenn es funktioniert... :saint:

  • Andy Auch wenn wir uns schon das eine oder andere mal gekappelt haben.... das mit der Branchensoftware und den xy Programierern - das haben wir gemeinsam. Unsere Branchensoftware wurde auch an diversen Ecken von old schoold AutoIt Programmen erweitert - > da ist der Hersteller immer sprachlos.

    Das mit der Bedienung ist dito bei uns auch so..... die Herren reden wichtig und haben ihre eigene Software noch nie benutzt :)

    Und JAAAAAA inis sind nicht altmodisch sondern einfach nur praktisch!!!!! Und vieles läßt sich pragmatisch einfach lösen!!! Man muss es nur wollen!

    Bei mir führt das Verhalten der sog. Profis .... immer zu einem wenig salonfäigen Spruch über Profiprogramierer....

    So long

    Peter

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

    Ab 19-10-22 ergänzt um:

    Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen. (Albert Einstein)