BoBo wrote:Bedauerlicherweise wurde der ursprüngliche Ansatz von Chris (KISS - keep it stupid simple) als vernachläßigbar betrachtet und fiel einigen Egos zum Opfer.
Na ja, als ich anfing, mich mit AHK zu beschäftigen, habe ich einmal sinngemäß gesagt: "Eine Sprache, die dermaßen auf die Funktion
DllCall() angewiesen ist, ist einfach nur unvollständig." Und das lag schlichtweg daran, dass die Foren schon damals voll von solchenen Skripten waren, und ich mit den dahinter liegenden API-Funktionen nichts anfangen konnte.
Auch der Syntax-Mischmasch innerhalb der Gui-Anweisungen (und Guis waren der Grund für mich, mich mit AHK zu beschäftigen) hat mich anfangs abgeschreckt: Kommandos für die meisten Controls, aber Funktionen (mit ihren völlig anderen Parametern und der Expression-Syntax) für ListView, TreeView und Statusbar. Es hat einige Zeit gebraucht, bis ich mich an mein erstes ListView Control gewagt habe. So gesehen, ist KISS sicherlich relativ und abhängig vom Standpunkt und den Fähigkeiten des jeweiligen Anwenders. Und letztlich hat Chris selbst - wenn vielleicht auch schweren Herzens - AHK_L / AHK 1.1 zum offiziellen Nachfolger von 1.0.48.05 erklärt.
Die aktuellen AHK 1.1 Versionen ergänzen AHK 1.0. Die Liste der Inkompatiblitäten zwischen AHK 1.0 und AHK 1.1 ANSI ist wirklich kurz und kann, wie ich aus eigener Erfahrung weiß, für einfache KISS Skripte fast immer vernachlässigt werden. Man kann also, wenn man will, auch mit AHK 1.1 Skripte in AHK 1.0 Syntax schreiben. Wozu braucht es dann ein AHK Basic, dessen Code zudem seit dem Jahr 2009 nicht mehr gewartet wurde?
fredchf wrote:Das Versionskoas(Basic, 1.1.+, V2, AHK_H) hilft weder Einsteigern, noch engargierten Supportern.
In Bezug auf AHK_H würde ich zustimmen. Es ist bedauerlich, dass AHK_H und AHK_L nicht zusammengeführt werden können. Und es ist oft - doch so viele Supportanfragen zu AHK_H gibt es nun auch wieder nicht - nicht gleich zu erkennen, dass der Fragesteller AHK_H nutzt.
v2 hat hier einen eigenen Bereich und sollte deshalb keine Verwirrung stiften. Ich habe mich da übrigens nach den letzten Änderungen erst mal wieder abgekoppelt, weil mir die Menge der für das Testen notwendigen versionsabhängigen Codeänderungen für meine Lieblingsskripte zu groß geworden ist und mich die letzten Entscheidungen nicht immer überzeugt haben.
Zum Thema AHK Basic habe ich mich ja schon oben ausgelassen. Ich sehe hier keine Notwendigkeit zur Unterscheidung, würde den Basic Anwendern aber immer empfehlen, ihre Basic Skripte mit AHK 1.1 zu schreiben. Es ist wohl so, dass AHK 1.0 performanter sein kann. Doch dank der Prozessorentwickler der Fa. Intel haben diese Performanceunterschiede nur noch in absoluten Ausnahmefällen eine Bedeutung.
Im englischen Teil sehe ich die Tendenz, erkennbare Anfänger z.B. für relativ einfache Stringoperationen immer sofort mit der RegEx-Keule zu beglücken. Das könnten wir hier vielleicht anders machen. Den Unterschied zwischen
Var%A_Index% und
Var[A_Index] halte ich dagegen nicht für überfordernd, auch wenn die deutsche Tastatur für die zweite Version AltGr braucht.
[quote="BoBo"]Bedauerlicherweise wurde der ursprüngliche Ansatz von Chris (KISS - keep it stupid simple) als vernachläßigbar betrachtet und fiel einigen Egos zum Opfer.[/quote]Na ja, als ich anfing, mich mit AHK zu beschäftigen, habe ich einmal sinngemäß gesagt: "Eine Sprache, die dermaßen auf die Funktion [c]DllCall()[/c] angewiesen ist, ist einfach nur unvollständig." Und das lag schlichtweg daran, dass die Foren schon damals voll von solchenen Skripten waren, und ich mit den dahinter liegenden API-Funktionen nichts anfangen konnte.
Auch der Syntax-Mischmasch innerhalb der Gui-Anweisungen (und Guis waren der Grund für mich, mich mit AHK zu beschäftigen) hat mich anfangs abgeschreckt: Kommandos für die meisten Controls, aber Funktionen (mit ihren völlig anderen Parametern und der Expression-Syntax) für ListView, TreeView und Statusbar. Es hat einige Zeit gebraucht, bis ich mich an mein erstes ListView Control gewagt habe. So gesehen, ist KISS sicherlich relativ und abhängig vom Standpunkt und den Fähigkeiten des jeweiligen Anwenders. Und letztlich hat Chris selbst - wenn vielleicht auch schweren Herzens - AHK_L / AHK 1.1 zum offiziellen Nachfolger von 1.0.48.05 erklärt.
Die aktuellen AHK 1.1 Versionen ergänzen AHK 1.0. Die Liste der Inkompatiblitäten zwischen AHK 1.0 und AHK 1.1 ANSI ist wirklich kurz und kann, wie ich aus eigener Erfahrung weiß, für einfache KISS Skripte fast immer vernachlässigt werden. Man kann also, wenn man will, auch mit AHK 1.1 Skripte in AHK 1.0 Syntax schreiben. Wozu braucht es dann ein AHK Basic, dessen Code zudem seit dem Jahr 2009 nicht mehr gewartet wurde?
[quote="fredchf"]Das Versionskoas(Basic, 1.1.+, V2, AHK_H) hilft weder Einsteigern, noch engargierten Supportern.[/quote]In Bezug auf AHK_H würde ich zustimmen. Es ist bedauerlich, dass AHK_H und AHK_L nicht zusammengeführt werden können. Und es ist oft - doch so viele Supportanfragen zu AHK_H gibt es nun auch wieder nicht - nicht gleich zu erkennen, dass der Fragesteller AHK_H nutzt.
v2 hat hier einen eigenen Bereich und sollte deshalb keine Verwirrung stiften. Ich habe mich da übrigens nach den letzten Änderungen erst mal wieder abgekoppelt, weil mir die Menge der für das Testen notwendigen versionsabhängigen Codeänderungen für meine Lieblingsskripte zu groß geworden ist und mich die letzten Entscheidungen nicht immer überzeugt haben.
Zum Thema AHK Basic habe ich mich ja schon oben ausgelassen. Ich sehe hier keine Notwendigkeit zur Unterscheidung, würde den Basic Anwendern aber immer empfehlen, ihre Basic Skripte mit AHK 1.1 zu schreiben. Es ist wohl so, dass AHK 1.0 performanter sein kann. Doch dank der Prozessorentwickler der Fa. Intel haben diese Performanceunterschiede nur noch in absoluten Ausnahmefällen eine Bedeutung.
Im englischen Teil sehe ich die Tendenz, erkennbare Anfänger z.B. für relativ einfache Stringoperationen immer sofort mit der RegEx-Keule zu beglücken. Das könnten wir hier vielleicht anders machen. Den Unterschied zwischen [c]Var[color=#BF0000]%[/color]A_Index[color=#BF0000]%[/color][/c] und [c]Var[color=#BF0000][[/color]A_Index[color=#BF0000]][/color][/c] halte ich dagegen nicht für überfordernd, auch wenn die deutsche Tastatur für die zweite Version AltGr braucht.