Beiträge von Professor Bernd

Zitat von OttoEBs

Kleine Zusatzfrage - hättest du auch einen Tipp für eine einfache PORTABLE Versionsverwaltung?

Damit kann ich dir leider nicht helfen. Aber es gibt bestimmt andere User, die sich damit gut auskennen.

Zitat von OttoEBs

PSPad4AutoIt3 voll portabel - genau danach habe ich gesucht.
Vielen Dank!

Vielen Dank fürs Feedback!

Als der 1 Mio. User darfst du dir das nächste Feature wünschen, das in Pau3 eingebaut werden könnte. (Nicht alles ist möglich.) Schreib deinen Feature-Wunsch einfach hier, oder als PN oder an die E-Mail-Adresse auf der Pau3-Seite. Mal sehen, ob es machbar ist.

Inoffizielle Version nur für Tester. / Unofficial version for testers only.

Test version for RunParamsDialog 2021-05-17.zip entfernt / removed

Edit: "Relevant code places.txt" added to zip.

Edit: Tests beendet, Datei entfernt. / Tests finished, file removed.

PSPad4AutoIt3 v2.1.0 beta - Update (2021-05-02)

Update Pack mit neuer Funktion "LogWin AutoClose".

Für das LogWin (Output Console) können nun verschiedene Einstellungen vorgenommen werden.

• LogWin nach "Run, Compile, ..." anzeigen.
• LogWin nach "Run, Compile, ..." automatisch schließen, falls keine Fehler/Warnungen aufgetreten sind.
• LogWin nach "Run, Compile, ..." automatisch schließen, ..., aber nicht wenn es Debug-Msgs gibt.
• Verzögerung bis zum automatischen Schließen (0 - 10 Sekunden).

Diese Einstellungen kann man erreichen:

• über das PSPad Menü: "AutoIt3" / "Settings (AutoIt3)" / "Open PSPad4AutoIt3.ini"
• über den Windows Explorer: "...\<Pau3>\PSPad4Au3\PSPad4AutoIt3.ini"

Ansonsten gibt es wie immer einige Verbesserungen im Code wie z.B. den "IniRefresher", der dafür sorgt, dass die Pau3-Ini nach einem Update auf den neuesten Stand kommt und gleichzeitig die Einstellungen des Users behält. Dadurch kann man die Dateien und Ordner aus dem Update Pack einfach in den Ordner einer vorherigen Version kopieren und die vorherigen Einstellungen bleiben erhalten.

An dieser Stelle geht mein besonderer Dank an AspirinJunkie , der fast im Alleingang den Code für den IniRefresher entwickelt hat.

Eine Anleitung zum Update Pack findet man im Update Pack selbst ("ReadMe Ger.txt") und am Ende von Posting #1.

Viel Spaß beim Ausprobieren, und denkt an das Feedback.

Professor Bernd.

Download am Ende von Posting #1

water

Wie das hier abgelaufen ist, gefällt mir nicht und ich gönne meiner Hilfe zur DE Hilfe vorerst mal eine Pause.

Tweaky und alle anderen

Tut mir leid.

Tweaky

Wie ist deine Meinung?

Zitat von BugFix

Projektordner.

Nun kann es sein, dass du für dieses Projekt eine bestimmte Editorkonfiguration möchtest. Das kannst du dann mit einer Einstellungsdatei in diesem Ordner regeln. Deren Inhalt hat Vorrang gegenüber den User-Einstellungen.

In Pau3 liegt die User-Ini im Projektordner.

Was du beschreibst kommt mir bekannt vor von SciTE. Interessantes Konzept und recht flexible flexibel. (Scheiß Nicht-Autokorrektur am PC).

Zitat von BugFix

Was ich gerade nicht weiß: Erkennt PSPad den Wechsel auf ein anderes Editor Tab? - Dieses "OnChange" Ereignis ist erforderlich, um dann die Einstellungen on-the-fly zu aktualisieren.

Ich weiß gerade nicht mehr wer, aber vor kurzem hat das jemand schön formuliert, etwas mit PSPad und "hartes Brot!". Und das ist wahr! - PSPad erkennt vieles, auch Editor-Tab Wechsel. (Edit: Z.B. wird beim Tab Wechsel der CodeExplorer automatisch aktualisiert.) ... Leider gibt PSPad kein einziges Ereignis an Entwickler von Add-ons weiter. Keine Chance.

Das ist einer der Hauptgründe, weshalb ich langsam anfange mit SciTE zu liebäugeln. Wenn mir jemand für SciTE "mal eben so nebenbei" ein fertiges Grundgerüst zur Verfügung stellen würde, mit dem man den SciTE4AutoIt3 Editor in eine eigene MDI Umgebung einbinden könnte, würde ich wahrscheinlch sofort wechseln und SciTE mit all dem Komfort aufpeppen, den die eingefleischen SciTE Nutzer "nicht brauchen".

Zitat von BugFix

... projektorientierte Einstellungen vornehmen ...

Global und User würdest du einfach um eine Datei im Objektordner erweitern, die wiederum evtl. abweichende Werte aus der Userdatei überschreibt.

Was meinst du denn mit projektorientierte Einstellungen und Objektordner?

Zitat von BugFix

Trotzdem möchte ich nochmal einwerfen,

Genau darum geht es in diesem Thread, es sollen Ideen gesammelt und diskutiert werden. Also vielen Dank fürs "Einwerfen"!

Systemdatei, Systemeinstellung, Systemdaten, ... da stelle ich mir was vor, was hier nicht gemeint ist. Eher sehe ich es als ein 2-Dateien Konzept, bei dem Einstellungen in eine Global- und eine User-Datei gespeichert werden. Ich gebe dem Kind den Namen "Global/User-Konzept" (das schreibt sich auch leichter).

Auch wenn (glaube ich) sonst niemand etwas zum 2-Dateien Konzept gesagt hat, ich finde es gut. Für den Moment werde ich zwar das 1-Dateien Konzept benutzen, weil ich einfach nicht riskieren will, was alles schief gehen kann, wenn ich so viele Stellen im Code ändern würde. Aber später könnte das durchaus umgestellt werden.

Wie sieht es denn aus, wenn ein Programm das Global/User Konzept und einen Settings-Dialog benutzt (SciTE mach das doch so, oder?), werden dann die Einstellungen vom Settings-Dialog in der User-Datei gespeichert? - Hmm, ... ... jetzt wo ichs schreibe, kann ich es mir kaum anders vorstellen. Ok, ist klar. War also keine Frage, sondern laut gedacht.

Was gibt es denn an Nachteilen bei dem 2-Dateien-Konzept gegenüber dem mit nur 1 Datei? Wo Licht ist, muss es doch auch Schaten geben.

Zitat von AspirinJunkie

Um also einen Stringvergleich mit einzubauen muss man nur die Return-Zeile ändern zu: Return SetExtended($sRet <> $sIst, $sRet)

Dann kann man mit @extended prüfen ob es eine Änderung gab oder eben nicht.

Ich habs jetzt übernommen als Return SetExtended(Not ($sRet == $sIst), $sRet), damit auch Unterschiede in Groß-/Kleinschreibung festgestellt werden.

Zitat von AspirinJunkie

Zum Thema Unterschiede detektieren: So wie du es schreibst reicht es einen Stringvergleich (wie in Post 58) zu machen.

Gute Idee, mit dem @extended. Ich hatte eine zusätzliche ByRef Variable eingebaut, was auch funktioniert, deine Idee finde ich allerdings viel eleganter und werde sie einbauen.

Zitat von AspirinJunkie

Hier noch die Variante mit dem Text hinter den Section-Header und der ganzen Ini in einer AutoIt-Struktur:

Nachdem mir nun klar wurde, dass beim Ganze-Ini-Einlesen alle Schlüssel in ein Dict geschmissen würden und evtl. überschrieben würden, finde ich sektionsweises Einlesen richtig gut! Trotzdem danke für den Code zum Einlesen der ganzen Ini. Und ganz besonderen Dank für das RegEx Pattern für Sektions-Header mit Text dahinter. Es ist einfach ein gutes Gefühl, wenn du die Pattern machst!

AspirinJunkie

In manchen Inis kann man sowas wie einen Kommentar bzw. eine Erläuterung hinter den Sektionsnamen schreiben, z.B.:

[Config EN] - for english main program

; ColorSchemes 2020-07-19: White_Black_Red, Gray_White_Blue, auto

ColorScheme=auto

ProjPanel.RememberVisibility=1

ProjPanel.RememberBlaBla=1

ProjPanel_RememberFoo=1

Dann wird die Sektion nicht gefunden. Ist es viel Aufwand, den Code so erweitern, dass er auch damit zurechtkommt? Das ist jetzt nichts, was wirklich benötigt wird, aber falls es nicht viel Aufwand macht, ...

Hier mein Versuch. Es funktioniert zwar, aber das war eher ein Raten, als Wissen, das könnte also wer-weiß-was an Nebenwirkungen haben, z.B. den Code verlangsamen oder so. Kannst du mal drüber gucken?

Func _IniReadSection($sFilePath, $sSection, Const $bDic = False)

    ...

    ; Section komplett als String auslesen
;     Local $aSectionRaw = StringRegExp($sFile, '(?m)^\[' & _RegExEscape($sSection) & '\]\s*\R([^\[]+)', 1)
    Local $aSectionRaw = StringRegExp($sFile, '(?m)^\[' & _RegExEscape($sSection) & '\]\s*([^\[]+)', 1) ; <== hier mein Versuch
    If @error Then Return SetError(2, @error, False)

Die ganze Zeit habe ich mich gefragt, warum der Code die Sektionen einzeln einliest, statt eine ganze Ini in einem Rutsch. Nun weiß ich es.

Leider hatte ich diese Erkenntnis erst, nachdem ich den Code so umgeschrieben hatte, dass er eine ganze Ini eingelesen hat. Der Grund für das sektionsweise Einlesen ist ein ganz einfacher: In verschiedenen Sektionen können durchaus die gleichen Schlüssel vorkommen, insbesondere bei Sprach-Inis.

Ist das richtig, oder gibt es noch einen anderen Grund für das sektionsweise einlesen?

Ok, durch unsere Diskussion (das war das Ziel dieses Threads) ist mir das Ziel nun klarer geworden. Kürzer formuliert sähe es nun so aus:

Neue Namen: Soll.ini = Master.ini; Ist.ini = User.ini; Ergebnis.ini = Merged.ini - "Ini" ist hierbei sinnbildlich zu verstehen, es sind nicht zwingend Dateien auf der Festplatte, sondern können auch nur im RAM existieren.

• Die Master.ini wird zunächst 1:1 in die Merged.ini kopiert.
• Dann werden alle Schlüssel-Werte in der Merged.ini durch die in der User.ini ersetzt.
• User.ini und Merged.ini werden miteinander verglichen und falls es auch nur 1 Unterschied gibt, wird der Inhalt der User.ini durch den Inhalt der Merged.ini ersetzt.
• Als unterschiedlich wird gesehen, wenn die Inhalte nicht 1:1 stimmen, inkl. Groß- / Kleinschreibung.

Somit könnte man einfach alle Schlüssel und -Werte der User.ini in ein Dictonary laden, z.B. mit AspirinJunkies Code. Dann braucht man nur noch die Merged.ini zu durchlaufen und alle Schlüsselwerte zu prüfen, ob sie im Dictionary exitieren. Falls ja, wird der Schlüssel-Wert in der Merged.ini mit dem aus dem Dict ersetzt.

Am Schluss, wie gesagt, die Merged.ini mit der User.ini vergleichen, ob sie unterschiedlich sind und bei Bedarf in die User.ini schreiben.

.

Hinweis: Wer diesen Beitrag noch nicht gelesen hat: Im nächsten Beitrag ist eine kürzere Beschreibung.

.

Zitat von AspirinJunkie

Die Frage wäre: Sollen die beiden Ini-Dateien direkt zeichenweise gleich sein oder nur inhaltlich?

Z.B. richtet sich die Reihenfolge der Sections nach der aus der Soll.ini.

Solange mein Kopf noch halbwegs frisch ist, versuche ich's mal. ... Neue Namen: Soll.ini = Master.ini; Ist.ini = User.ini; Ergebnis.ini = Merged.ini

Das Maß aller Dinge ist die Master.ini, sie soll fast 1:1 identisch auf die Merged.ini abgebildet werden, lediglich vorhandene Schlüsselwerte aus der User.ini werden übernommen (wenn es diese Schlüssel in der Master.ini gibt).

Die Master.ini wird mit der User.ini wie oben beschrieben vermischt, das Ergebnis ist die Merged.ini. Danach wird die User.ini mit der Merged.ini verglichen. Sind beide nicht absolut gleich (inkl. Groß- / Kleinschreibung), wird der Inhalt der User.ini durch den Inhalt der Merged.ini ersetzt.

Im Detail

Das Konzept zum Vermischen soll so aussehen, dass alle Sektionen und Schlüssel nach dem Vermischen genau so in der Merged.ini stehen, wie sie in der Master.ini sind, ausgenommen die Schlüsselwerte. Die Merged.ini soll nach dem Vermischen so aussehen:

• Die Merged.ini enthält alle Sektionen, Schlüssel und Kommentare der Master.ini.
• In der User.ini vorhandene Schlüsselwerte wurden übernommen.
• Neue Schlüssel und -werte aus der Master.ini wurden übernommen.
• Elemente (Sektionen, Schlüssel, Kommentare) die in der User.ini fehlen, wurden in der Merged.ini ergänzt.
• Elemente (Sektionen, Schlüssel, Kommentare) die in der Master.ini fehlen, wurden in der Merged.ini gelöscht.
• Die Reihenfolge ist die der Master.ini, das heißt, alle Elemente stehen in der Merged.ini an der gleichen Stelle wie in der Master.ini, einschließlich Leerzeichen und Leerzeilen.

Danke für dein Testscript.

Edit: Rest gelöscht, war Quatsch.

Mach dir mal im Moment nicht weiter Arbeit, vielleicht funktioniert alles, aber ich kriege gerade nicht mehr auf die Reihe, wann die Ist.ini geändert wird und wann nicht und wann das in der Ergebnis.ini auftaucht und wann nicht und ... . Muss jetzt und morgen wieder frisch drangehen.

Problem: Ich habe die Soll.ini kopiert und umbenannt zu Ist.ini, dann lediglich ein Zeichen hinzugefügt => damit sind sie also unterschiedlich (was WinMerge auf anzeigt). Leider meint der Stringvergelich, dass beide identisch sind.

Ich habe nun mit großen (280 KB) Inis getestet und mit kleinen (1 KB), das Ergebnis ist immer "identisch". Was mache ich falsch?

Fällt mir gerade ein: Funktioniert ein case sensitive Stringvergleich auch bei ausländischen Zeichen? Zum Beispiel:

LogWinTitel=البحث في البرامج والملفات

Ich vertraue dir!

Zitat von Musashi

Also doch ein 'simpler' Vergleich .

Falls du das meinst:

Zitat von Musashi

Solange es nur grundsätzlich darum geht, ob sich die Soll.ini und die Ist.ini unterscheiden (nicht wo),

dann unbedingt ein simpler Vergleich. Nur dass nicht Soll.ini<>Ist.ini verglichen werden, sondern Ist.in<>Ergebnis.ini. Das hatte ich am Anfang übersehen.

Für Hashes sehe ich hier keinen Vorteil, eher einen Nachteil, weil die glaube ich nicht für Schnelligkeit stehen.

Zitat von Musashi

Ich habe testweise 2 Strings der Länge 500.000 Chars verglichen -> geht schnell und problemlos !

Um auch Groß/Kleinschreibung zu berücksichtigen solltest Du aber If $String_1 == $String_2 Then verwenden.

Das sollte hinhauen. Als Orientierung habe ich die schon etwas größere PSPad.ini genommen, die mit über 1.500 Zeile etwa 32.000 Zeichen "auf die Waage bringt". Das wären noch nicht annähernd 10% deiner getesteten 500.000 Zeichen, was also praktisch funktionieren sollte und sogar viel Luft nach oben hat.

Trotzdem nochmal die Frage, ob ein Vergleich mit anderen Methoden schneller wäre, wie z.B. die, die ich In Posting #43 aufgezählt habe.

Danke für den Tipp mit dem case sensitive Vergleich. Das hatte ich noch nicht bedacht.