Beiträge von Professor Bernd

    Falls dir langweilig ist und du eine Ini mit Zeichen in allen möglichen Sprachen angehen willst, sind im Anhang Beispieldateien. Wegen der Größe der Datei habe ich die Ausgabe in eine Datei gespeichert (in der 2.au3, Zeile 4: FileWrite("Ergebnis.ini", $sZusammen)).


    In der Ist.ini gibt es 4 Änderungen zur Soll.ini. Falls du WinMerge oder ähnliches hast, kannst du sie dir leicht anzeigen lassen. Ansonsten kannst du nach "Hallo Welt!" suchen, das ich an den 4 Stellen eingefügt habe.


    Edit: AspirinJunkie Bitte nur als Zusatzarbeit verstehen, es wird im konkreten Fall nicht wirklich benötigt (siehe vorheriges Posting).

    Dateien

    • 5.zip

      (157,43 kB, 1 Mal heruntergeladen, zuletzt: )

    Super Arbeit! :thumbup:


    Lediglich bei asiatischen, arabischen, bulgarischen, ... Zeichen macht der Code nicht mit. Woran es lag, konnte ich nicht rausfinden, ich habe eine Ini mit Sprachen geladen und die Ausführung blieb gleich stecken.


    Aber das ist nicht schlimm, ich habe nicht vor, Language.ini's auf diese Art upzudaten. Im Moment sind nur Settings beabsichtigt, das reicht.


    Vielen Dank für deine Mühe! :) ... Jetzt muss ich nur noch sehen, wie ich das auf VBScript umsetzen kann. :D

    Das 32 KB Limit scheint, zumindest ab Win7, also nicht mehr zu gelten.

    Dann wird sich das 32 KB Limit nur auf IniReadSection() beziehen. Und das wäre ja wirklich kein Problem. Wenn man davon ausgeht, dass die PSPad.ini bei 32 KB Gesamtgröße aus insgesammt etwa 1.500 Zeilen besteht und man das für eine einzelne Sektion benutzen könnte, ... ich kann da kein Problem sehen, die ganze PSPad.ini würde in 1 Sektion passen. Und man kann doch locker mehr Sektionen erstellen, usw.


    Danke fürs Testen!

    Aus den 16 Bit Windows Zeiten. Mit Einführung der Registry wurden die Ini Dateien durch MS im System selbst nicht mehr verwendet.

    Also kann das Limit in 64 Bit Windows Zeiten durchaus weggefallen sein? Aber selbst wenn das 32KB File Size Limit noch bestehen sollte, wäre das kein Problem. Ich denke nicht, dass Pau3 soviele Einträge erhält, dass das Limit überschritten wird. Und falls doch, gibts eine zweite Ini-Datei. 8o

    Du brauchst die User Datei niemals bearbeiten, das macht ausschließlich der Anwender.

    Hmm, ... sollte es mal irgendwann einen Settings-Dialog geben, wäre das gar nicht so schlecht. Im Settings-Dialog kann man die Infos unterbringen, die ich derzeit als Kommentare in die Ini schreibe.


    32k File Size Limit.

    Witzig, ich habe gerade nachgesehen, die PSPad.ini hat 32KB. Woher kommt das Limit? Ist das noch akutell?

    Du solltest evtl. das Konzept überdenken.

    Deshalb frage ich ja hier. 8o

    Ich finde die von SciTE gewählte Variante mit Global und User Properties sehr gut.

    Das hatte ich vor einiger Zeit auch schonmal überlegt. Aber bisher konnte ich das mit meinem Konzept nicht unter einen Hut bringen. Zum Beispiel soll Pau3 einen Settings-Dialog bekommen. Wo sollte der dann hinspeichern? Wahrscheinlich in die User Properties, dann bin ich soweit wie jetzt, oder? Das werde ich nochmal überdenken, ansich ist die Idee nicht schlech, Global... und User... zu trennen.

    Zum anderen soll eine vorgesehene Reihenfolge in der Ini eingehalten werden.

    Was ist der Nutzen davon?

    Ordnung. Schlüssel können aphabetisch sortiert werden und somit können zusammengehörende Schlüssel beisammen stehen und in einer sinnvollen Reihenfolge, wie z.B. im Beispiel oben


    ; Close the LogWin automatically if no errors occur ...

    AutoCloseIfNoError=1

    ; ... but not if debug messages occur.

    AutoCloseButNotIfDbgMsg=1


    BugFix Du postest schneller, als ich antworten kann. Ich schicke hier schonmal eine Teilantwort.


    Verabschiede dich von der Ini, da geht ins Auge (Limit).

    Welches Limit?

    Hab deine Info im ersten Post eingearbeitet.


    Ansonsten tun Beispieldateien gut.

    Meinst du Ini- oder Script-Dateien? Ein Script gibts noch nicht. Wollte erst Ideen sammeln.


    "Soll"-Ini
    "Ist"-Ini"gewünschtes Resultat"-Ini
    [Paths]
    AutoIt3_Dir=C:\Program Files (x86)\AutoIt3\
    SciTE_Dir=C:\Program Files (x86)\AutoIt3\SciTE\
    PSPad_Dir=

    [General]
    P4A3_FirstStartAfterInstallIsDone=True
    KodaFirstStartIsDone=True
    ProjPanelHiding_Use=1
    ReplaceMnuItmsInAllLangFiles_ToAutoIt3=False

    [Config]
    ; ColorSchemes 2020-07-19: White_Black_Red, Gray_White_Blue, auto
    ColorScheme=auto

    [LogWin]
    ShowAfterCompile=1
    AutoCloseDelay=2
    ; Close the LogWin automatically if no errors occur ...

    AutoCloseIfNoError=1
    ; ... but not if debug messages occur.
    AutoCloseButNotIfDbgMsg=1
    [Paths]
    AutoIt3_Dir=C:\Program Files (x86)\AutoIt3\
    SciTE_Dir=C:\Program Files (x86)\AutoIt3\SciTE\
    PSPad_Dir=

    [Config]
    ColorScheme=auto

    [General]
    KodaFirstStartIsDone=False
    ProjPanelHiding_Use=
    P4A3_FirstStartAfterInstallIsDone=True

    [LogWin]
    AutoCloseDelay=4
    ; Close the LogWin automatically if no errors occur ...

    AutoCloseIfNoError=1
    AutoCloseButNotIfDbgMsg=0
    [Paths]
    AutoIt3_Dir=C:\Program Files (x86)\AutoIt3\
    SciTE_Dir=C:\Program Files (x86)\AutoIt3\SciTE\
    PSPad_Dir=

    [General]
    P4A3_FirstStartAfterInstallIsDone=True
    KodaFirstStartIsDone=False
    ProjPanelHiding_Use=1
    ReplaceMnuItmsInAllLangFiles_ToAutoIt3=False

    [Config]
    ; ColorSchemes 2020-07-19: White_Black_Red, Gray_White_Blue, auto
    ColorScheme=auto

    [LogWin]
    ShowAfterCompile=1
    AutoCloseDelay=4
    ; Close the LogWin automatically if no errors occur ...

    AutoCloseIfNoError=1
    ; ... but not if debug messages occur.
    AutoCloseButNotIfDbgMsg=0



    Es geht darum, eine Ini-Datei zu aktualisieren, ohne deren Einstellungen zu verlieren.


    In Pau3 gibt es eine Main-Ini, mit der Einstellungen verwaltet werden. Wenn nun ein User ein Update über seine vorhandene Version kopiert, will er seine Einstellungen natürlich nicht verlieren. In einer reinen Ini wäre das recht einfach, indem man nur die Werte auf Vorhandensein und Gültigkeit prüfen und ergänzen würde.


    Zum einen handelt es sich hierbei aber um eine Ini mit gemischtem Inhalt, nämlich mit Kommentaren, die Infos zu Einstellungen geben. Z.B. zum Schlüssel FarbSchema könnte es einen Kommentar FarbSchema: hell, dunkel, auto geben.


    - Edit: Nach Info von AspirinJunkie sollten Kommentare keine Probleme machen.


    Zum anderen soll eine vorgesehene Reihenfolge in der Ini eingehalten werden.


    Es gibt also eine "Soll"-Ini und eine "Ist"-Ini.


    "Soll"-Ini (Script)
    "Ist"-Ini (User)
    Befindet sich als Code im Script.
    Befindet sich als Datei auf der Festplatte.
    Enthält alle Schlüssel und Kommentare in der gewünschten Reihenfolge und mit der gewünschten Formatierung (z.B. nur 1 Leerzeile vor einer weiteren Sektion, usw.).
    Enthält evtl. nicht alle Schlüssel, Kommentare sind vorhanden oder gelöscht, die Reihenfolge ist evtl. komplett durcheinander, die Formatierung ist Kraut und Rüben.
    Schlüssel enthalten die Standard-Werte.
    Schlüssel enthalten vom User eingefügte Werte, enthalten falsche oder keine Werte.


    Nun sollen die Werte der Schlüssel in der Ist-Ini aktualisiert werden, wobei vorhandene gültige Werte des Users erhalten bleiben. Neue Schlüssel und Kommentare sollen hinzugefügt, gelösche Kommentare und die gewünschte Reihenfolge wieder hergestellt werden. Ich denke, es ist klar wie's gemeint ist. :)


    Der Code wird beim Starten von PSPad geladen und sollte leicht geschwindigkeitsoptimiert sein, das heißt, es kommt zwar nicht auf Millisekunden an, aber wenn der Code flott ist, ist das gut für die Startgeschwindigkeit von PSPad.


    Meine Überlegung schwankt zwischen Arrays und Dictionarys. Auf jeden Fall könnte ich es mir so vorstellen, dass z.B. beide Inis zeilenweise (StringSplit()) in Arrays geladen und verglichen werden.

    • Das Soll-Array wird von Anfang bis Ende durchlaufen und jede einzelne Zeile mit allen Zeilen des Ist-Arrays verglichen.
    • Handelt es sich bei der Soll-Zeile um einen Kommentar, wird er übersprungen, denn die Kommentare werden am Schluss bei Schreiben an die richtige Stelle gesetzt.
    • Handelt es sich bei der Soll-Zeile um einen Schlüssel, werden alle Zeilen des Ist-Arrays durchlaufen, bis der Schlüssel gefunden ist. Ist der Schlüssel im Ist-Array NICHT vorhanden, wird die Soll-Zeile einfach übernommen. Ist der Schlüssel im Ist-Array vorhanden, wird der Wert auf Gültigkeit geprüft und entweder übernommen (wenn gültig) oder ersetzt (wenn UNgültig).
    • Evtl. als Geschwindigkeitsoptimierung die Zeilen aus dem Ist-Array löschen, die schon verarbeitet wurden. Das kann aber in die Hose gehen, denn wahrscheinlich ist das ReDim des Ist-Arrays langsamer, als wenn man nicht löscht.
    • Der Inhalt der Ist-Ini wird gelöscht und das Soll-Array in die Ist-Ini geschrieben.

    Die Main-Ini eines ausgewachsenen Programms, wie z.B. PSPad, kann leicht über 1.500 Zeilen beinhalten. Deshalb würde ich mich freuen, über Ideen und Verbesserungsvorschläge. :)

    Für die magic numbers bestehen noch keine Konstanten - ich habe sie daher belassen, aber vor den Funktionsaufruf entsprechende Kommentare eingefügt

    Finde ich ok und die Kommentare klasse! :thumbup:Zuerst dachte ich, man könnte zur besseren Veranschaulichung eigene, sprechende Konstanten benutzen, wie $eCOLORREF. Aber dann dachte ich, vielleicht ist das zuviel des Guten und die (magischen) Zahlen bringen mehr Übersicht.


    Beim Programmieren habe ich einfach die Erfahrung gemacht, dass man im ersten Moment versucht ist zu denken: "Was solls? Ist doch alles klar!" Aber nach drei, vier Monaten ist einem nicht mehr so klar, was man damals gedacht hat. Dann freut man sich, wenn man Kommentare dazu geschrieben hat. (Und pssst! Nur unter uns: In meinem Pau3 Projekt, das mittlerweile für mich recht große Ausmaße angenommen hat und über mehrere Programmiersprachen geht, bin ich über Kommentare richtig oft froh!) :)


    Die von Dir vorgeschlagene Formatierung habe ich übernommen

    Die ist scheinbar zwischendurch wieder verloren gegangen. 8o


    Da im Edit eine Monospace-Font benutzt wird, sollte man das zum Formatieren ausnutzen und die Werte im Edit schön untereinander ausrichten. Im Code unten habe ich das wieder hergestellt. Ich würde mich freuen, wenn es dir gefällt.


    Die meisten anderen Änderungsvorschläge sind Formatierungen. Den Code habe ich mit reichlich Kommentaren versehen, so sollte es verständlich sein. Meine Frage zu Param 2 soll weder Kritik, noch Aufforderung zur Änderung sein, sie ist rein informativer Natur.


    Vielen Dank für deine Mühe! :thumbup:

    Heißt das, dass dir mein Beispiel nicht gefällt? Und dass es nicht als Beispiel 2 aufgenommen wird? ;(


    Zu deinem Beispiel: Das finde ich um einiges besser, als das vorhandene! :)


    Richtig super finde ich die Kurz-Info zu COLORREF, BGR und RGB am Anfang des Codes, vorallem den Link zur MS-Docs-Seite! :thumbup:Ebenfalls gut gefällt mir die _ShowChoice UDF. Sie ist einfacher gestaltet und kommt ohne den Param $Type aus, der für Verwirrung gesorgt hat.


    Verbesserungsvorschläge:

    • Vielleicht die magic numbers in _ChooseColor(2, 255, 0, $hGUI) durch sprechende Konstanten ersetzen und die Farbvorwahl als Hex.
    • $idMemo durch $idEdit ersetzen. Das ist aber eigentlich egal.
    • Formatierung von $sMessage überarbeiten, z.B.:
    Code
    $sMessage = "COLORREF color of your choice - hex: " & $sCOLORREF & ", dec: " & Dec(Hex($sCOLORREF, 8)) & @CRLF & _
    "BGR color of your choice - hex: 0x" & $sBGR & ", dec: " & Dec($sBGR) & @CRLF & _
    "RGB color of your choice - hex: 0x" & $sRGB & ", dec: " & Dec($sRGB) & @CRLF

    Was haltet ihr davon? Bist du noch bei uns, Tweaky ? 8o