Beiträge von BugFix

    Genauer gesagt, sollen im laufenden PSPad verschiedene VBScript-Funktionen von außen per AutoIt aufgerufen werden können, die dann auf interne Informationen von PSPad zugreifen.

    Diese Kommunikationsrichtung ist tatsächlich unter den gegebenen Voraussetzungen wohl nicht realisierbar.

    Wenn PSPad auf externe Nachrichten reagieren soll, ist das ja nur möglich, wenn intern kontinuierlich irgendein HTTP-Port oder eine Umgebungsvariable oder Event etc. abgefragt wird. Da du sagst, dass das nicht gegeben ist, sehe ich jetzt keinen erfolgversprechenden Ansatzpunkt. Das ist so, als ob du in ein Haus gehen möchtest, aber niemand macht die Tür auf, weil man dein Klingeln nicht hört.


    Du kannst doch eigene VBScripte in PSPad ausführen? - Dann solltest du versuchen, ob ein eigener Loop und Event installierbar ist (vielleicht nach diesem Bsp.), wenn der Autor nicht mag.

    Leider nicht. Wie gesagt, es gibt keine Browser-"Grundlage", somit keine Fenster, somit keine Events.

    Somit benötigst du ein eigenes Kommunikations-Interface in PSPad. Ich bin nicht firm in VBScript, somit weiß ich nicht, ob das realisierbar ist.

    Grundsätzlich brauchst du nur ein Fenster, das unsichtbar im Hintergrund dümpelt und mit dem du von externen Programmen (AutoIt) Nachrichten empfängst. In SciTE gibt es, wie schon bereits angesprochen, das SciTE Director Interface dafür. Vielleicht kann der Autor von PSPad das ja noch implementieren. Ist kein großes Hexenwerk und m.M. nach ohne große Probleme integrierbar.

    Das Fenster für die Kommunikation könnte man mit jeder beliebigen Anwendung erstellen. Aber die Möglichkeit die Nachricht WM_COPYDATA auszuwerten, muss in PSPad implementiert werden.

    Zitat von alpines

    Da ich persönlich keine Lua-Skripte nutze (und auch keinen Sinn darin sehe)

    Dann benutzt du nicht SciTE4AutoIt?

    Die gesamte Funktionalität dort wird mit Lua-Skripten realisiert. Bitnugger oder ich nutzen darüber hinaus nur weitere Möglichkeiten. Aber ohne Lua würde SciTE nicht funktionieren.

    So:

    :thumbup:

    Eigentlich seltsam, dass dieser Style nicht im Modul enthalten ist. Ebenso fehlt LVS_EX_TRACKSELECT.

    Ich habe mir mal noch 2 Funktionen erstellt um jeweils Spalten und Inhalt in einem Rutsch zu setzen.

    Um eine variable Anzahl von Elementen an eine Funktion zu übergeben ist (nur als Funktionsparameter) der Datentyp openArray vorhanden.

    Im Array bin ich aber grundsätzlich an Daten desselben Typs gebunden.

    Um hier flexibel zu sein kann man aber das Array mit Datentypen besetzen, die selbst gemischt sind. Tuple - für eine fixe Anzahl oder Sequencen für veränderliche Anzahl.

    Bsp.:

    Gridlines sind in den Styles für das ListCtrl nicht enthalten. Ich habe nun versucht den ExStyle zu setzen:

    Code
    import winim
    SetWindowLongPtr(list.mHwnd, GWL_EXSTYLE, cast[LONG_PTR](LVS_EX_GRIDLINES))

    Leider ohne Erfolg.

    Ideen?

    Da man Item im ListCtrl nicht einzeln einfärben kann, wollte ich zumindest über farbige Images in der Spalte 0 Markierungen signalisieren.

    Jedoch wird bei Verwendung des Styles: wLcIcon/wLcSmallIcon dann nur die erste Spalte der Liste angezeigt.

    Das Bsp. zeigt alle Spalten ohne den Icon-Style. Werden die auskommentierten Zeilen aktiviert und statt dessen die Zeilen mit der # ***** Markierung auskommentiert, ist der IconStyle aktiv und nur die erste Spalte (mit den Images) ist sichtbar. X/

    Den angehängten Ordner mit den Images runterladen und imgPath entsprechend anpassen.

    Fehler bei mir oder muss das so?

    Und eines ist mir noch aufgefallen:

    Die Header werden sinnloser Weise genauso ausgerichtet, wie die Item. Habt ihr da schon eine Lösung für?

    Bsp. für Einlesen einer JSON Datei.

    Verwendet wird die "\.nimble\packages_official.json", die auf jeden Fall bei allen vorhanden ist.

    Da stimmt etwas nicht bei nimgen... die 0.5.2 sollte dann ja eigentlich von nimble gefunden werden? Ein refresh hatte ich zuvor gemacht.

    "Sollte" ist hier das richtige Wort. ^^

    Refresh hat damit aber m.M.n. nichts zu tun, das ist wohl eher in der Search-Funktion begründet. Diese sollte eigentlich genauso vorgehen, wie ich in meinem Update-Check:

    - Repo url des benannten Pakets abfragen

    - dort aus "Paketname.nimble" die aktuelle Versionsnummer lesen

    Dabei hakt es wohl. - Gut, dass ich meinen Update Checker erstellt habe, der machts richtig. :P

    Da ich meine Module ausschließlich händisch verwalte, habe ich mir jetzt zumindest eine Routine zum Prüfen aller Packages auf vorhandene Updates erstellt.


    So schauts dann aus:




    EDIT:

    Ich habe noch ergänzt, dass alle installierten Versionen mit aufgelistet werden.

    EDIT zum EDIT: Einige Repo url enden auch auf ".nim". Habe das jetzt neben ".git" zur Korrektur der Adresse aufgenommen.

    Nur bei der Erstinstallation (1.44.2), alle weiteren Versionen (1.48.2, 1.49.0) mit scoop update vscodium.

    Das ist auch OK, genauso mache ich es auch.

    Die aktuelle Version:

    Code
    Version: 1.49.0
    Commit: e790b931385d72cf5669fcefc51cdf65990efa5d
    Datum: 2020-09-11T10:41:02.560Z
    Electron: 9.2.1
    Chrome: 83.0.4103.122
    Node.js: 12.14.1
    V8: 8.3.110.13-electron.0
    Betriebssystem: Windows_NT x64 6.1.7601

    So lief das Update bei mir (gerade ausgeführt):


    Notfalls kannst du ja erst mal auf die vorige Version zurückgreifen.

    Die neueste Version ist immer unter demselben Pfad: C:\Users\USER\scoop\apps\vscodium\current\VSCodium.exe zu finden und ist ein Link auf die jeweils höchste Installationsnummer.

    Der reale Pfad dahinter ist also (bei v1.49.0): C:\Users\USER\scoop\apps\vscodium\1.49.0\VSCodium.exe

    Wenn du dir einen Link auf C:\Users\USER\scoop\apps\vscodium\1.44.2\VSCodium.exe setzt, solltest du zumindest mit der vorigen Version problemlos arbeiten können. Da scoop alle Dateien ausschliesslich in seinem Unterordner apps ablegt, hast du hier auch keine Probleme mit irgendwelchen Abhängigkeiten.

    Naja, Du testest ja auch nur den Tag, aber mit getDaysInMonth geht's wirklich kürzer

    Obs ein Schaltjahr ist, prüft getDaysInMonth bereits. Und alle anderen Prüfungen der Jahreszahlen sind m. M. nach Humbug. In der Historie ist nicht wirklich bekannt wer wann und wo welchen Kalender genutzt hat und wann "die Zeit des Jahreszählens" begann. Wer weiß, vielleicht hatte ja einer meiner Ur-Ur-Ahnen eines Tages den Gedanken und sagte: "He Leute, ich hab eine brilliante Idee - wir zählen ab heute die Zeit und jetzt ist das Jahr Nummer 1.":rofl:

    Und für die ferne Zukunft ist es auch völlig schnuppe, ob es vielleicht in 3000 Jahren zu einer Schaltjahresverschiebung kommt oder nicht.

    Insofern kann jede Jahreszahl als valide angenommen werden. Tut keinem weh. :D