Re:Bedarf an Bearbeitung v. Parameterdateien?
Hallo Ralf,
im Prinzip ganz einfach.
Wird ein Script etwas umfangreicher, ist es oft nötig Einstellungen, Daten für verschiedene Dinge oder Parameter etc. zu speichern.
Nun kann jeder das Rad neu erfinden, und jeder schreibt sich seine eigenen Routinen um Daten oder Programmparameter zu speichern und zu lesen. Jeder schreibt ein anderes Format, dass nur sein Programm lesen und schreiben kann. Meist Binär oder Kryptisch, so dass man manuell wenig ändern kann.
Unter normaler Programmumgebung kann man sich mit WIN-API-Funktionen zum Schreiben und Lesen von Parameterdateien (INI-Dateien) behelfen, einer Konfigurationsdatenbank oder über die Registry.
Da man die Registry wegen Undurchsichtigkeit nicht überstrapazieren sollte, schon gar nicht, wenn ein Skript einfach gelöscht wird, habe ich den Weg über Parameter-Dateien gewählt. Diese kann man zur Not über den Editor manuell nachbearbeiten, um neue Einstellungen festzulegen, oder eine Vorlage auf die Schnelle zu ändern, da dieses Format seit den Anfängen von Windows bekannt ist.
Sicher könnte man den Weg über XML wählen, nur ist dort die manuelle Wartbarkeit zu kompliziert.
INI.WSC ist nun dazu konzipiert, diese INI-Dateien über ein Skript zu pflegen, neue Bereiche anzulegen, alte zu löschen, festzustellen welche Bereiche existieren; Schlüssel anzulegen, zu lesen, zu finden und zu löschen.
So eine INI-Datei kann auch Kommentare enthalten ";". Ich habe dies nur insofern erweitert, dass jeder Schlüssel seinen eigenen Kommentar enthalten kann, der ebenfalls per Skript gesetzt, gelesen und gelöscht werden kann.
Ist diese Windows-Scripting-Component(WSC)-Datei installiert (z.B. über HTML-Generator) kann unabhängig von der Scripting-Umgebung (JScript, VBScript) diese benutzt werden. Unter VBScript z. B. so:
Dieses Script liest alle Bereichsnamen (Sections) aus einer Parameterdatei aus:
Option Explicit
Dim oINI
Dim sFileName
Set oINI = CreateObject("INI.WSC"
sFileName = InputBox("Geben Sie eine gültige INI-Datei mit vollständigem Pfad ein:"
If Len(sFileName) > 0 Then
oINI.FileName = sFileName
MsgBox "Bereiche:" & vbCRLF & oINI.Sections
End If
Set oINI = Nothing
Es gibt natürlich auch einen Pferdefuß, wo gibt es den nicht? Jeder Bereich darf in der Datei nur einmal definiert sein. Jeder Schlüssel darf pro Bereich nur einmal definiert sein. Somit darf z. B. die FixFoto.ini nicht bearbeitet werden, da Schlüssel mehrfach definiert sind, sowie FFScript.ini, da Bereiche mehrfach definiert sind. Auch würde ich die Finger von BS-Parameterdateien lassen, da die erweiterte Kommentarfunktion evtl. dort eine Menge Ärger einbringen kann, sowohl beim Lesen und Schreiben.
Ein weiterer "Pferdefuß" ist, dass die Dateien gecached werden, d.h. die Daten werden zum Bearbeiten zwischengespeichert, um die Festplatte bei intensiven Zugriff nicht "überzustrapazieren". Daher muß am Ende des Lebenszyklus der Objektvariable, sofern ein Schreibzugriff stattfand, mit "[Object].Flush" auf die Festplatte gebannt werden. Ein automatisches Schreiben beim Zerstören (Terminate) des Objekts ist leider bei Windows-Scripting-Components nicht vorgesehen, so dass "ordentlich" programmiert werden muss.
Da oft der Fehler im Detail von Dateizugriffen liegt, wollte ich in diesem Thread nur mal nachfragen, ob es vielleicht unter den FF-Scriptprogrammierern Leute gibt, die sich ein wenig Arbeit sparen wollen. Das ist alles.
Schönen Gruß,
Werner.
.