Skript für "erweiterte" Hilfe in SciTE

  • Mit der Hilfe von MrCreatoR ist es mir gelungen CHM-Hilfedateien zu erstellen, die der von AutoIt sehr, sehr ähnlich sind.

    Nun wäre es natürlich fein, wenn man diese Hilfe von SciTE aus aufrufen könnte - analog zur AutoIt-Hilfe.

    Was ich mir vorstellen könnte:

    • Ein Skript wird in SciTE auf eine Tastenkombination gelegt
    • Wenn es aufgerufen wird, stellt es fest, auf welchem Wort (Funktionsname etc.) der Cursor steht
    • Mit diesem Wort wird dann die entsprechende Hilfe (Active Directory, OutlookEX, Taskmanager ...) aufgerufen
    • Welche CHM-Datei aufzurufen ist, wird über eine INI-Datei konfiguriert (z.B. _AD_* ruft die AD.CHM auf, Ausnahmen sollten auch definiert werden können)
    • Wird nichts gefunden, dann könnte man die AutoIt.CHM aufrufen und somit mit einer Taste alle Hilfe-CHMs zusammenfassen

    Ich habe schon gesucht, aber leider nichts entsprechendes gefunden.

    Kann sich jemand vorstellen, dass diese Ideen überhaupt umsetzbar sind oder gibt es vielleicht schon was in die Richtung?

  • water 23. November 2021 um 21:33

    Hat das Thema freigeschaltet.
  • Da es für SciTE gedacht ist, sollte man die Umsetzung auch zwingend in Lua machen. Das erleichtert die Interaktion mit dem Editor.

    Demzufolge bieten sich hier auch Properties statt Ini-Datei an. Ist auch deutlich flexibler.

    Das umzusetzen ist auch nicht allzu kompliziert.

    Du kannst ja gerne mal eine Auswahl von Key-Words zusammenstellen mit einer Hilfedatei, die aufzurufen ist. (Aufruf, wie bekannt mit Suchbegriff als Parameter? - Am Besten, du lieferst mal eine Musterkommandozeile mit)

    Edit:

    Da am Ende der Hilfekette die Standard AutoIt-Hilfe steht, ist es natürlich sinnvoll, das Skript dann auch über F1 aufzurufen.

  • Nehmen wir die Active Directory Hilfe (AD.CHM) als Beispiel:
    Die UDF umfasst nur Funktionen. Daher genügt es, wenn mit allen Worten, die mit "_AD_" beginnen, die AD.CHM aufgerufen wird.
    Das würde dann für die Funktion _AD_Open so aussehen: hh.exe mk:@MSITStore:C:\local\ad.chm::/funcs/_AD_Open.htm

    Pro vom Benutzer "installierten" CHM-Datei müsste in der Konfiguration angegeben werden:

    • Pfad und Name der CHM Datei: z.B.: C:\local\AD.CHM
    • Liste von Funktionsnamen die in dieser CHM zu finden sind. Dabei ist * als Wildcard für eine beliebige Anzahl an Zeichen möglich.
  • Super! Vielen Dank!!

  • Nun wäre es natürlich fein, wenn man diese Hilfe von SciTE aus aufrufen könnte - analog zur AutoIt-Hilfe.

    So, ich habe das mal umgesetzt.

    Die Liste von Funktionsnamen brauchen wir nicht extra führen, die ist in ein paar ms aus der UDF ausgelesen.

    Der Standard-Hilfeaufruf wird umgeroutet über das Skript. Details sind in der alternate.help.properties beschrieben.

    • Die alternate.help.lua abspeichern
    • Die alternate.help.properties im Ordner C:\Users\_U_S_E_R_\AppData\Local\AutoIt v3\SciTE speichern (im Anhang habe ich .txt angehängt, damit die Datei hochgeladen werden konnte)
    • Pfade in den Properties anpassen

    Da UDF-Funktionsnamen immer nach dem Muster _Buchstaben_ & ... erstellt werden, frage ich dieses Prefix vom markierten Wort ab.

    Gibt es für das Prefix keine gespeicherte Hilfedatei, wird der Standard-Hilfeaufruf durchgeführt. Gibt es eine Hilfedatei, wird aus der UDF ein Table aller Funktionsnamen erstellt. Ist der markierte Begriff einer dieser Funktionsnamen, wird die UDF-Hilfe mit dem markierten Begriff aufgerufen. Wird der markierte Begriff nicht im Table gefunden erfolgt ebenfalls der Aufruf der Standard-Hilfe.

    Da hier Kommandozeilenaufrufe zum Einsatz kommen, ist es erforderlich (wie in der properties-Datei ersichtlich) die Property create.hidden.console=1 zu setzen.

    So, nun probier mal schön. ;)

  • Super! Ich schaue mir das an, sobald ich etwas Zeit finde!

  • Perfekt! Läuft wie geschmiert!

    Ein paar kleine Verbesserungswünsche/Fragen ans Christkind hätte ich noch ;)

    1. Wie kann ich angeben, dass z.B. die AD.au3 im User Include Directory liegt (wie über SciTEConfig konfiguriert)?
    2. Fein wäre es, wenn man noch Ausnahmen definieren könnte.
      Konkret habe ich die Outlook-Funktionen in 2 UDFs: OutlookEX.au3 und OutlookEX_Base.au3 (hier sind die Konstanten definiert und die Basisfunktionen wie _OL_Open etc.).
      Für beide UDF-Dateien gilt der selbe Prefix (hier "_OL_") und sie sollen auf die selbe CHM_Datei zeigen.
      In diesem Fall würde es genügen für die Ausnahmen die UDF nicht zu durchsuchen, sondern direkt die CHM aufzurufen. Nachteil: Die Ausnahmen müssten von Hand gepflegt werden
      Alternative wäre, dass man für den Prefix (_OL_) mehere UDFs angeben kann. Vorteil: keine manuelle pflege, Nachteil: Etwas längere Laufzeit.
    3. Das cmd-Fenster bleibt beim Aufruf der AutoIt-Hilfe offen bis die Hilfe beendet wird. bei AD und OutlookEX popt das cmd_Fenster kurz auf und verschwindet dann gleich wieder.
      Wenn man das noch abstellen könnte, dann wäre die Lösung perfekt!
    4. Was mir noch aufgefallen ist: Wird im Skript die AutoIt-Hilfe mehrfach aufgerufen, so wird in der bestehenden Hilfe-Instanz der nächste Suchbegriff angezeigt.
      Bei eigenen UDFs wird jedesmal eine neue Instanz des Hilfeprogramms gestartet.

    Vielen Dank für Deine Bemühungen! ich hätte nicht gedacht, dass es mit so wenig Code (aber dafür vermutlich mit viel mehr Hirnarbeit) zu realisieren ist.
    Ich denke, das ist ein großer Fortschritt für viele, viele Benutzer von AutoIt!

    :rock::klatschen::party::part: :love:

  • Vielen Dank für Deine Bemühungen! ich hätte nicht gedacht, dass es mit so wenig Code (aber dafür vermutlich mit viel mehr Hirnarbeit) zu realisieren ist.
    Ich denke, das ist ein großer Fortschritt für viele, viele Benutzer von AutoIt!

    :rock::klatschen::party::part::love:

    Dieser Danksagung möchte ich mich in vollem Umfang anschließen :thumbup: .

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Wie kann ich angeben, dass z.B. die AD.au3 im User Include Directory liegt (wie über SciTEConfig konfiguriert)?

    Da die Lösung ja allgemeingültig sein soll, wäre das etwas tricky. Denn:

    In der Property openpath.$(au3) sind die Includ-Pfade !! hinterlegt. Somit möglicherweise mehrere Ordner. Das wäre nicht so günstig zum Abfragen.

    Ist dort nur ein Pfad, kannst du die Variable $(openpath.$(au3)) als Verweis auf diesen Pfad nutzen. Oder du schreibst halt den realen Pfad zur Property.

    Fein wäre es, wenn man noch Ausnahmen definieren könnte.
    Konkret habe ich die Outlook-Funktionen in 2 UDFs: OutlookEX.au3 und OutlookEX_Base.au3 (hier sind die Konstanten definiert und die Basisfunktionen wie _OL_Open etc.).
    Für beide UDF-Dateien gilt der selbe Prefix (hier "_OL_") und sie sollen auf die selbe CHM_Datei zeigen.
    In diesem Fall würde es genügen für die Ausnahmen die UDF nicht zu durchsuchen, sondern direkt die CHM aufzurufen. Nachteil: Die Ausnahmen müssten von Hand gepflegt werden
    Alternative wäre, dass man für den Prefix (_OL_) mehere UDFs angeben kann. Vorteil: keine manuelle pflege, Nachteil: Etwas längere Laufzeit.

    OK, ich werde das mal einpflegen mit Zuweisbarkeit von mehreren UDF. (Ausnahmen wären dann nicht mehr erforderlich? - Falls doch kann ich ein Property der Form: chm.except._OL_=L_i_s_t  exceptions erstellen.) Glaub mir, der Laufzeitaufwand ist absolut vernachlässigbar. Dateien parsen mit Lua ist im Vergleich zu AutoIt um mehrfachen Faktor 10 schneller!

    Das cmd-Fenster bleibt beim Aufruf der AutoIt-Hilfe offen bis die Hilfe beendet wird. bei AD und OutlookEX popt das cmd_Fenster kurz auf und verschwindet dann gleich wieder.
    Wenn man das noch abstellen könnte, dann wäre die Lösung perfekt!

    Ich weiß jetzt nicht welche SciTE-Version du nutzt. Ich selbst nutze noch eine recht alte Version, die es erlaubt Dll in Lua zu laden (Geht ja aktuell und auf lange Sicht nicht mehr).

    Aber aus der History war ersichtlich, dass die Property create.hidden.console=1 eingeführt wurde, um das Aufpoppen der CMD-Windows zu unterbinden. Ich konnte das somit nicht selbst testen.
    Beim Standardaufruf hatte ich "start /B" vergessen, das sollte schon mal dasselbe Verhalten, wie bei den alternativen Aufrufen erzwingen.

    Aber ich werde mal an einer Kombinationslösung Lua-AutoIt testen. Die Geschwindigkeitsvorteile des Lua-Skripts nutzen, aber den Hilfeaufruf aus einer Kompilierten AutoIt.exe ausführen, um das CMD-Window Problem zu umgehen.

    Was mir noch aufgefallen ist: Wird im Skript die AutoIt-Hilfe mehrfach aufgerufen, so wird in der bestehenden Hilfe-Instanz der nächste Suchbegriff angezeigt.
    Bei eigenen UDFs wird jedesmal eine neue Instanz des Hilfeprogramms gestartet.

    Da gilt dasselbe, wie zum vorigen Punkt. Das erfordert Prozessmanagement in Windows, was mit den Standard Lua-Bibliotheken nicht realisierbar ist. Mit Alien-Lua wäre es machbar, aber das erfordert wieder das Einbinden von Dll's... s.o. :(

    Somit wird hier auch eine Kombination mit AutoIt erforderlich sein.


    Das Skript sollte auch erstmal nur einen Funktionstest ermöglichen.

    Wenn alle Funktionalitäten geklärt sind, werde ich die Umsetzung in "schön" in Angriff nehmen. :D

    Also überleg, was dir noch wichtig erscheint. Wie gesagt: Daten parsen geht rasend schnell, also auch kein Problem, statt einer z.B. 6 Dateien zu durchsuchen.

  • Hi BugFix,

    Du machst Deinem Namen mal wieder alle Ehre und bist ziemlich "fix".

    Ich habe meine Wunschliste oben durchnumeriert, da kann ich mich bessser darauf beziehen.

    Zu 1) Das können wir derzeit so lassen. Man ändert ja nicht laufend den Speicherort seiner UDFs. Derzeit läuft es ja und mehr fällt unter: Nice to have.

    Zu 2) Das wäre super, wenn man mehrere UDFs angeben könnte. Ausnahmen sind dann nicht notwendig, da ja alle Funktionen in beiden UDFs den selben Prefix haben.

    Zu 3) Ich habe auch schon an ein Auto-Skript gedacht. Da werde ich mich gleich dranmachen.

    Zu 4) Da habe ich an ProcessClose gedacht. Das obige AutoIt-Skript killt einfach alle HH Prozesse bevor es einen neuen startet.

    Generell denke ich, dass möglichst alles mit AutoIt-Bordmitteln umgesetzt werden sollte. So halten wir die Komplexität niedrig und die Akzeptanz hoch :)

    BTW: Habe gerade gesehen, dass Jos die AutoItHelp für SciTE "missbraucht". Vielleicht könnte man die auch für unsere CHMs verwenden und hätte somit das Instanzen-Problem erschlagen.
    Ich frage mal an.

  • BTW: Habe gerade gesehen, dass Jos die AutoItHelp für SciTE "missbraucht". Vielleicht könnte man die auch für unsere CHMs verwenden und hätte somit das Instanzen-Problem erschlagen.

    Das sollte sich erledigen, wenn ich als Main-Skript eine Exe nutze. Im SciTE - Command Aufruf wird dann die Laufzeitumgebung auf Windows (2) festgelegt und dann sollte das automatisch mit der Prozessverwaltung durch SciTE funktionieren.

  • Super :thumbup:

  • Zu 1) Das können wir derzeit so lassen. Man ändert ja nicht laufend den Speicherort seiner UDFs. Derzeit läuft es ja und mehr fällt unter: Nice to have.

    OK

    Zu 2) Das wäre super, wenn man mehrere UDFs angeben könnte. Ausnahmen sind dann nicht notwendig, da ja alle Funktionen in beiden UDFs den selben Prefix haben.

    Ist hiermit getan.

    Zu 3) Ich habe auch schon an ein Auto-Skript gedacht. Da werde ich mich gleich dranmachen.

    Zu 4) Da habe ich an ProcessClose gedacht. Das obige AutoIt-Skript killt einfach alle HH Prozesse bevor es einen neuen startet.

    Und nun auch das AutoIt-Skript zum Hilfeaufruf. Dadurch poppt kein Cmd-Window auf. Die alternativen Hilfefenster schließe ich, wenn ein neuer Aufruf der Art erfolgt.

    Es gibt dadurch Veränderungen in den properties, bitte genau beachten.

    Dieses ist das Aufrufskript, welches selbst erst das Lua-Skript startet und dann dessen Ergebnis (die Befehlszeile zum Aufruf) abfragt. Damit wird dann der erforderliche Hilfeaufruf gestartet.

    Ich nutze dazu das Interface mit SciTE ("DirectorExtension"). Dadurch ergibt sich eine minimale Verzögerung, aber nicht wirklich störend.

    Das Skript kompilieren und gemäß der Anweisung im Skript den Aufruf in die properties eintragen.

    EDIT

    Ich speichere jetzt die PID der aufgerufenen hh.exe in einer Property. Dadurch wird auch nur die von diesem Skript aufgerufenen PID gekillt und nicht evtl. eine später geöffnete hh.exe eines anderen Programms.

    Etwas unklar ist mir, wieso ich die AD-Hilfe maximieren kann, jedoch nicht die OL-Hilfe. - Vielleicht fällt dir ja was auf?

  • Wahnsinn!!

    Dein aktueller Code funktioniert perfekt :love::thumbup:<3

    Bei mir lassen sich sowohl die AD als auch die Outlook-Hilfe problemlos maximieren.

    Meine Dateiversion ist: HH.EXE 10.0.19041.1 vom 07.12.2019 10:09 unter Windows 10.

    Kann ich irgendwas für Dich testen?

  • Kann ich irgendwas für Dich testen?

    Nein, passt schon. ;)

    Im Skript hole ich mir ja über die PID der gestarteten hh.exe das zugehörige Fensterhandle und setze damit (bzw dem Fenster Titel - Verhalten ist identisch) das Fenster auf maximiert. Egal in welcher Reihenfolge (Ol dann AD oder umgekehrt) - AD wird maximiert, OL nicht.

    Aber daran hänge ich nicht meine Seligkeit. Wenn es bei euch funktioniert ist das prima.

  • Passt! Ich hätte die fehlende Maximierbarkeit auch nur als Schönheitsproblem gesehen :)

    Mir gefällt auch gut, dass für die AutoIt Hilfe und die UDF Hilfe jeweils ein eigenes Fenster geöffnet wird. So kannst Du gleichzeitig zu AutoIt und einer UD die Hilfe offen haben!

    Ich schreibe gerade eine Installationsanleitung in Deutsch und English.
    Poste ich hier, sobald ich mit dem ersten Entwurf durch bin :)

  • Hier mein erster Entwurf für die Doku.

    Ich habe noch die udf.mainfolder property analog zur chm.mainfolder property eingefügt, da sie ja den selben Zweck erfüllen. Dafür entfällt udf.path.base.

    Was hältst Du davon?

  • Fixe ich noch :)

    Dann mache ich mich mal an die engl. Version