AutoHotkey Community

Hi people,
ähnlich wie hier gezeigt: https://www.autohotkey.com/boards/viewtopic.php?p=339730#p339730
gruppiere ich die Parameterangaben einer AHK-gui in "Spalten" um die Übersichtlichkeit zu erhöhen.
Dies sollte gerade AHK-newbies helfen eine Gui-Struktur zu durchschauen, sowie Positions-/Koordinaten-Parameter einfacher zu warten.
Quasi @toralf 's Auto-Syntax-Tidy für Gui-Parameter

Manuell verwende ich dafür im Editor Tabs statt Spaces (Ausrichtung funktioniert dann auch mit variable-width fonts).
Idee ist es, einen (ClipBoard/File) Parser für die Parameter-Sektion eines Gui-Code-Blocks zu bauen.
GUI-Befehl-Transformationskandidaten: Gui, Add sowie Gui, Show da diese Befehle Positions/Koordinaten-Parameter enthalten ...

(M)eine vermutete Hürde, AHK's Format-Befehl. Dieser scheint mir jedoch am geeignetsten zu sein, um eine fixe Spaltenbreite je Parameter zu generieren, ausgehend vom jeweils "längsten" Parameter einer Befehlszeile, wie einem gLabel ("gIchBinEinLangesLabel"), oder der längsten Koordinatenangabe ("w%A_ScreenWidth%") ...
Vielleicht kann mir jemand mit einen angepassten Format-Befehl unter die Arme greifen? Merci

BTW, habe gerade gesehen das toralf (vor Jahren) die "banner-style"-indentation in seinem Auto-Syntax-Tidy "BoBo-style" genannt hat , wahrscheinlich weil ich seit Jahrzehnten der Einzige bin der diese benutzt.

Hallo BoBo,

Das kann ich dir erklären. Damals haben sich Rajat und Du jeweils andere “Styles” gewünscht, und da ich keine Namen für diese Styles kannte habe ich eure Namen verwendet.

Zu deinem Problem: das Format() wird dir alleine nicht helfen, denn es setzt voraus, dass jede Zeile analysiert bzw. Geparsed werden muss, um zu erkennen welche Optionen pro Zeile gesetzt sind.
Und wie sollen die Optionen angeordnet werden, wenn sie je Zeile eine andere Reihenfolge haben?
Soll dann nur die Einrückungen einheitlich sein, oder die Optionen wie in deinem Beispiel “neu” angeordnet werden mit teilweise “Leerstellen”?
Und sollen gui,add innerhalb von gui,tab eingerückt sein? Sind dann auch die Optionen dieser gui,add etwas weiter rechts?
Bzw wie weit dürfen gui,adds auseinanderliegen, das ihre Optionen die identische Einrückung haben?

toralf wrote: ↑

04 Jul 2020, 16:58

Hallo BoBo,

Das kann ich dir erklären. Damals haben sich Rajat und Du jeweils andere “Styles” gewünscht, und da ich keine Namen für diese Styles kannte habe ich eure Namen verwendet.

Zu deinem Problem: das Format() wird dir alleine nicht helfen, denn es setzt voraus, dass jede Zeile analysiert bzw. Geparsed werden muss, um zu erkennen welche Optionen pro Zeile gesetzt sind. Confirmed
Und wie sollen die Optionen angeordnet werden, wenn sie je Zeile eine andere Reihenfolge haben? Nach pattern/Mustervorgabe
Soll dann nur die Einrückungen einheitlich sein, oder die Optionen wie in deinem Beispiel “neu” angeordnet werden mit teilweise “Leerstellen”? Die options sollen nach 'eigener' Spalte/type ausgerichtet werden, trotz etwaiger Leerstellen.
Und sollen gui,add innerhalb von gui,tab eingerückt sein? Sind dann auch die Optionen dieser gui,add etwas weiter rechts? Hab ich noch garnicht auf dem Schirm gehabt!?? Ähm, ...???
Bzw wie weit dürfen gui,adds auseinanderliegen, das ihre Optionen die identische Einrückung haben? Soll(t)en für den jeweiligen Gui-Block ausgerichtet sein. Ausrichtung, wie in meinem Codebeispiel vom 'längsten' (# chars) vorhandenen subcommand ausgehend (hier "ComboBox").

Danke für dein Interesse. Anmerkugen im Zitat oben.

Ich habe zwar immer auch mal ein paar gui,add direkt untereinander. Aber gelegentlich füge ich leer Zeilen oder Comments ein. Auch gelegentlich ein paar Zeilen mit If’s um Optionen zu bestimmen. Manchmal auch Folgen functions Aufrufe (zB um tool tips für das Control zu setzen.
Daher bin ich mir nicht sicher wie ein Solch loser Block GUI,add sauber erkannt und einheitlich orientiert werden kann.

Auch kann der User vor jedem Komma einen Zeilenumbruch einfügen. Was ich gelegentlich auch tue, um die Zeilen nicht zu lang werden zu lassen.

Alles in allem glaube ich, dass ein solches Unterfangen sicherlich machbar wäre aber der Nutzen nur sehr eingeschränkt ist. Vor allem weil die User Präferenzen sehr unterschiedlich sind.

Moin BoBo,

diesen Ansatz gab es ja schon. Ich war und bin nicht überzeugt, dass das wirklich hilfreich ist. Ich finde die 'aufgespreizte' Darstellung der Optionen mit zum Teil breiten Lücken eher verwirrend, aber das ist wie immer eine Frage der persönlichen Vorlieben.

Bedenken muss man allerdings, dass es viele controlspezifische Optionen gibt, die sich schwer in ein solches Schema integrieren lassen. Außerdem ist es beliebter geworden und manchmal auch angebracht, die Optionen als 'erzwungenen Ausdruck' zu definieren. Das kann ein 'Spaltenmodell' gewaltig aufblähen. Für mich ist das deshalb nichts.

ich schreibe script gerne so wie's BoBo vorgeschlagen hat , zumindest x y w h

Moin,
danke für euer Feedback. Ja, "forced expression" ist für dieses Konzept eher ungeeignet, und Nein, Gui-'Blockbuster'-Scripte mit multiplen Layern von verknüpften Oberflächen, zumal mit eingebettetem Code macht dann wahrscheinlich auch keine Freude. Die Intention zielt auf eine einzelne Oberfläche (den 'besseren' InputBox-Ersatz) mit der Ausrichtung der "Famous6": x/y/w/h/vVar/gLabel ... , insbesondere für den Noob, welcher beim Gui-building die (Positionierungs)Abhängigkeiten der Gui-Controls zueinander verstehen soll(te). IMHO resultieren aus 'geordnetem' Gui-Code auch geordnete/intuitivere Benutzeroberflächen.

Und yep, das dem Ansinnen die geballte Kraft individualistischer Coder entgegensteht ist mir durchaus bewusst

Just for the records:
https://autohotkey.com/board/topic/74885-tabalign-function-to-tab-align-columnar-data/
https://autohotkey.com/board/topic/42547-tf-text-file-variablesstring-library-v34-lib/page-11?&#entry389136

Frage: wie würde der Format-Befehl aussehen, welcher für Gui-Befehlsteile mit unterschiedlicher Anzahl an Zeichen/chars eine einheitliche folgende Spalten-/Startposition ergäbe?

Ich würde gerne etwas Hilfe bekommen bei der RegEx:
Um diesen Code mit einer RegEx zu zerlegen habe ich folgende RegEx Needle verwendet:i)Gui\s*,?\s*Add\s*,?\s*[\w]+\s*,?(\s*((Hwnd[\w#$@]+)|(g[\w#$@]+)|(v[\w#$@]+)))*(?!,) Leider findet die RegEx nur die Hwnd, aber nicht die anderen zwei. Wie kann die RegEx anderes geschrieben werden, dass alle Werte von der RegEx auf einmal erkannt werden?

EDIT: Habs gefunden ein * hatte gefehlt