AutoHotkey in der c't - Ausgabe 10 - 2019-04-27

[BoBo]

Tipp-o-matik

Windows automatisieren mit AutoHotkey ist eine beliebte Skriptsprache für Windows, die anderen einiges voraus hat.
So kann man damit nicht nur beliebig viele Befehle mit einer einzigen Tastenkombination ausführen, sondern auch Fenster manipulieren. [...]

Artikel von Hajo Schulz in der c't (aktuellen) Ausgabe 10 (vom 27.04.2019, Seite 156 ff).
Beispielcode des Artikels unter: ct.de/yuya

Dank an Hajo, das er unsere anfängerfreundliche Lieblingsskriptsprache (wieder) einmal zurück ins Licht der Öffentlichkeit befördert hat

[Guest]

Ich bin seit 2006 begeisterter Nutzer von activaid, welches noch auf AuoHotkey Version 1.0.47.06 basiert. Es wäre schön wenn es eine Anleitung gäbe, wie man das aktuelle AutoHotkey in activaid oder die Skripte von activaid in das aktuelle AutoHotkey integriert.

Hat da jemand der wissenden eine Idee?

[just me]

Moin,

activaid ist ein ziemlich komplexes 'Gesamtkonzept'. Im einfachsten Fall wirft AHK 1.1 Fehlermeldungen aus. Dann kann man sich gezielt ansehen, woran es liegen könnte. Wenn man damit durch ist, bleibt nur noch der 'große Funktionstest'. Wenn etwas nicht so funtioniert, wie es soll, schaut man sich die beteiligten Skripte gezielt an und versucht herauszufinden, wo der Fehler steckt. Die meisten Fehler werden sich in DllCalls bzw. den beteiligten Strukturen finden. NumGet/Put() sind auch beliebte Kandidaten. Wegen der Codierung von 'Nicht-ASCII-Zeichen' (Zeichencodes > 127) sollte man die Skripte im Format 'UTF-8-BOM' speichern. Vielleicht besteht Interesse daran, das als 'Projekt der deutschen Community' zu realisieren?

Grüße,
just me

[jNizM]

Sollte man mal bei Heise anfragen, ob wir das unter GitHub weiterentwickeln dürfen. Und am Besten hier (https://github.com/ahkscript) damit es nicht wieder unter einer Person liegt.

Heise-Artikel: https://www.heise.de/ct/artikel/Windows-weitergedacht-ac-tivAid-284115.html
Die offizielle Downloadseite: https://www.heise.de/download/product/activaid-24593

[just me]

Moin jNizM,

ich habe mir mal die aktuelle Version 1.3.1 heruntergeladen und einen Blick in die Skripte geworfen. Man sieht deutlich, dass die Masse der Skripte vor AHK 1.0.48 entwickelt wurde. Wenn man das nach AHK 1.1 mit den aktuellen Möglichkeiten portieren möchte, sollten eigentlich auch die neuen Möglichkeiten wie Arrays bzw. Objekte eingesetzt werden. Das würde aber wegen der 'besonderen Verzahnung' des Masterskripts mit den eigentlichen Toolskripten ziemlich viel zusätzliche Arbeit bedeuten. Schon die zwingend notwendigen Anpassungen, damit das unter allen AHK 1.1 Versionen (ANSI, U32, U64) läuft, scheint auf den ersten Blick einiges an Aufwand zu bedeuten. Wegen der Systemänderungen unter Win 8 und 10 habe ich auch Zweifel, ob alle mitgelieferten Tools überhaupt lauffähig sind.

Lange Rede, kurzer Sinn, das ist ein großer oder auch gewaltiger Berg an Arbeit. Am Versuch würde ich mich aber dennoch beteiligen.

just me

[hoppfrosch]

Darüber bin ich neulich gestolpert: https://github.com/ewerybody/a2

[hheckner123]

ich nutze activeaid seit vielen jahren. bislang habe ich auch keine alternativen gefunden, oder kennt jemand etwas vergleichbares?
wegen der portierung: das müsste halt schritt für schritt passieren , lohnenswert wäre es in jedem fall

[BNOLI]

Vielleicht wäre ein "Versions-Parser" keine generell schlechte Maßnahme, heisst, alle Code-Zeilen, welche potentiell invalide Code-Segmente enthalten könnten, werden als Report ausgegeben. Nach meinem laienhaften Verständnis wären das wohl zuerst 'deprecated commands', also alles Befehle für die AHK ggfs nicht mehr abwärtskompatibel interpretiert?? Final ließen sich damit auch Schätze aus den AHK Archiven einfacher konvertieren. Wieviele Zeilen Code hat denn ac'tiveAid ??
Fleißarbeit wäre bei mir drin, DllCall's fixen (noch) nicht.

EIn DllParser? Der die Dll's mit Zeilennummer retourniert, diese in ein Snippet übernimmt, welches auf korrekte/sinnige Rückgabe überprüft?

[gregster]

Vielleicht wäre ein "Versions-Parser" keine generell schlechte Maßnahme, heisst, alle Code-Zeilen, welche potentiell invalide Code-Segmente enthalten könnten, werden als Report ausgegeben. Nach meinem laienhaften Verständnis wären das wohl zuerst 'deprecated commands', also alles Befehle für die AHK ggfs nicht mehr abwärtskompatibel interpretiert??

"Deprecated commands" sind ja gerade Kommandos, die für Rückwärtskompatibilität noch immer mitgeschleift werden und (grundsätzlich) noch immer wie früher funktionieren.
Windows 7 wurde überhaupt erst 2009 eingeführt Die Änderungen in Windows werden wahrscheinlich das noch größere Problem sein als die Änderungen in AHK.

Für die meisten Funktionen von ac'tivaid gibt es wahrscheinlich funktionierenden oder zumindest aktuelleren Code im Forum. Ob man das jetzt unbedingt zu einem Tool zusammenstricken muss? Für den reinen Anwender, der sich nicht mit AHK auseinandersetzen will, wäre das wahrscheinlich vorteilhaft - aber wahrscheinlich nicht besonders attraktiv für AHK-Gurus, die noch andere Projekte verfolgen. Wobei ein Motivierter, der mal ordentlich vorlegt, vielleicht ausreicht, um andere zu ac'tivieren.

edit: Einige Redundanz gekürzt.

[BNOLI]

"Deprecated commands" sind ja gerade Kommandos, die für Rückwärtskompatibilität noch immer mitgeschleift werden und (grundsätzlich) noch immer funktionieren.

Umso besser also "lediglich" potentielle Austauschkandidaten

Wie wäre es damit die AHK-Hilfe-Befehls-Angabe einmal auf Versionsnummer zu parsen (StrPut() [v1.0.90+]) um mal eine Befehls-Historie Tabelle zu erstellen, damit ließe sich IMHO ermitteln bis/ab welcher Version scripte (noch) lauffähig sein sollten? An die 32/64bit Thematik wage ich noch nicht mal zu denken

http://activaid.rumborak.de/ (dort gibt es dann auch noch die letzten compile'ten "originalen" betas zum download, oben rechts)
https://activaid.telgkamp.de/ (eine andere (Nachfolge)Version)

PS. wer die Version 2020 schon mal ansehen möchte, bitte hier entlang: https://www.youtube.com/watch?v=fnW73WZwsWo
PPs. Wobei ein Motivierter, der mal ordentlich vorlegt, vielleicht ausreicht, um andere zu ac'tivieren.
Ich denke deshalb eher daran ob es Sinn macht (ein) Tool/s zu bauen, welche/s generell die Identifikation im Vorfeld vereinfacht, den potentiellen Aufwand aufzeigt, und damit auch ggfs eine Zuordnung nach Schwierigkeitsgrad erlaubt, geeks für 'rocket science' und tralala für Bnoli's oder ähnliches

[gregster]

Wie wäre es damit die AHK-Hilfe-Befehls-Angabe einmal auf Versionsnummer zu parsen (StrPut() [v1.0.90+]) um mal eine Befehls-Historie Tabelle zu erstellen, damit ließe sich IMHO ermitteln bis/ab welcher Version scripte (noch) lauffähig sein sollten?

Das wäre vielleicht wichtiger, wenn man aktuelle Skripts auf 1.0 zurückportieren wollte (aber da hätte wahrscheinlich eh niemand Lust zu )

Ich befürchte, dein Tool würde selbst ein großes Projekt (und ohne die Berücksichtigung der Änderungen in MS Windows wenig aussagekräftig) - letztendlich muss sich doch jemand den alten Code ansehen und analysieren, wo es jeweils hakt. Ob das sinnvoll automatisiert werden kann, bin ich skeptisch.

[BNOLI]

Würde mir der 'jüngste' Befehl innerhalb eines scripts nicht ergeben, ab welchem Interpreter ich überhaupt erst zu Testen beginnen sollte?

[nnnik]

Das Problem hierbei ist, dass AHK vollkommen abwärtskompatibel ist.
Das heist Activ'aid sollte solange es korrekt programmiert ist, noch vollkommen funktionieren.
Was jedoch die AHK Anwender der ersten Tage gerne gemacht haben ist schrottig zu programmieren so, dass es eventuell kaputt gehen muss.
Dementsprechend kann AHK dir keinerlei Hilfestellung geben. Es sind Fehler in der Programmierung nicht AHK dass das Problem ist.

[BNOLI]

Interessant woraus das ac'tiveAid bug-tracker-portal (oben verlinkt) gefrickelt ist: [FliegenSpray]

Und wer nochmal in Vergangeheit schwelgen möchte ... https://www.heise.de/download/specials/ac-tivAid-Forte-3149034