11 replies to this topic

[Harry Hirsch]

Ich habe mir gerade die aktuelle AHK-Version 1.1.09.03 installiert, ich benutze SciTE4AutoHotkey Version 3.0.02 - Based on SciTE 3.2.4 Jan 20 2013. Nun gibt es Probleme mit den deutschen Sonderzeichen äöüß. Diese lassen sich nicht mehr als Hotkey verwenden. Wenn ich den Send-Befehl benutze, werden die Sonderzeichen falsch ausgegeben. Wer weiß Rat?

 

Ich habe das Problem weiter eingegrenzt, es ist wohl ein Scite-Problem. Ich habe in der Datei SciTEUser.properties den Eintrag code.page=65001, wenn ich den lösche, lassen sich die Sonderzeichen wieder als Hotkey verwenden und werden mit dem send-Befehl richtig übertragen. Allerdings werden nun alle Sonderzeichen  in den bisherigen Skripten falsch angezeigt. Ich habe keine Lust alle per Hand zu ändern. Da muss es doch eine andere Lösung geben. Kann mir da jemand helfen?

 

Ich habe nun die Ursache des Problems entdeckt.

Mit der Version 1.1.08.00 - 14. Juli 2012 gab es folgende Änderung:

"Geändert: Standardzeichensatz des Scripts ist nun ANSI, da das vorherige Verhalten für die meisten irreführend war. UTF-8-Dateien müssen nun eine Bytereihenfolge-Markierung (BOM) haben, um richtig erkannt werden zu können. Zum Beispiel fügt der Windows-Editor in jede Datei eine BOM ein, sobald diese im UTF-8-Format gespeichert wird."

http://ragnar-f.gith...L_ChangeLog.htm

Man fragt sich was das soll? Wer wurde in die Irre geführt? Ich jedenfalls nicht. Erst mit der Änderung wurde ich in die Irre geführt. Das Problem liegt sowohl bei Scite als auch bei AHK. Man kann bei dem hochentwickelten Scite nicht angeben, dass er sich wie der primitive Windows-Editor verhalten soll und automatisch eine Markierung (BOM) einfügen soll. Und AHK erkennt nun eine UTF-8-Datei nur noch dann, wenn ein BOM eingefügt wurde.

Siehe http://de.wikipedia....Byte_Order_Mark

Hier wir deutlich, dass erst jetzt, mit dem Byte Order Mark viele in die Irre geführt werden: "Wird ein BOM verwendet, kann es jedoch auch zu Problemen mit Programmen kommen, die kein Byte Order Mark erwarten oder kennen." Man findet bei Google unter "utf-8 bom entfernen" 5390 Ergebnisse.

Ist das eine Verschlimmbesserung?

Um ältere Skripte auf UTF-8 mit BOM umzustellen muss man "Datei/Kodierung/UTF-8 mit Markierung" aktivieren und einmal speichern. Problematisch wird es, wenn man ein neues Skript schreibt. Dann muss man jedesmal "Datei/Kodierung/UTF-8 mit Markierung" aktivieren. Das nervt einfach nur! Früher konnte man das Problem elegant mit dem Eintrag code.page=65001 in die SciTEUser.properties lösen. Die Codepage-Nummer 65001 ist UTF-8

 

Siehe: http://de.wikipedia....chensatztabelle

 

Für weitere UTF-8-Informationen siehe hier:  http://de.wikipedia.org/wiki/UTF-8

 

Seit der Version 1.1.08.00 weigert sich AHK jedoch UTF-8 ohne BOM als UTF-8 zu erkennen, was nun dazu führt, dass der simple Hotkey ä:: send ae mit einer Fehlermeldung quittiert wird und auch alle anderen deutschen Sonderzeichen äöüß falsch interpretiert werden.

 

Wenig bis nicht hilfreich ist folgender Hinweis in der AHK-Doku, Zeichensatz einer Script-Datei: Nicht-ASCII-Zeichen sicher in Scripts verwenden:

 

http://ragnar-f.gith...ocs/Scripts.htm

 

Schaut man sich dann jedoch den vermeintlichen Lösungsvorschlag an,

 

http://ragnar-f.gith.../Scripts.htm#cp

 

wird nach längerem Nachdenken klar, dass sich das nur auf den Windows-Explorer, nicht jedoch auf Scite bezieht und eine Ausführung des dort vorgeschlagenen Scriptes mit der Registry-Eintragung nutzlos ist. Das ist nicht das erste Mal, dass die AHK-Doku zur allgemeinen Verwirrung beigetragen hat.

Es bringt jedoch dauerhaft nichts, sich darüber aufzuregen, sondern diesen Ärger als Motivation für eine Lösung zu nutzen. Ich habe nach längerer Recherche eine Lösung mittels eines LUA-Skriptes gefunden:

http://www.autohotke...20-2013/page-62

Save the following as NewAhk.lua in your user config folder:

if props["FileNameExt"] == "" and editor.Length == 0 and not buffer.templateLoaded then
    f = io.open(os.getenv("windir").."\\ShellNew\\Template.ahk", "r")
    if f then
        t = f:read("*all")
        if t:sub(1, 3) == "\239\187\191" then  -- UTF-8 BOM
            t = t:sub(4)
            scite.MenuCommand(IDM_ENCODING_UTF8)
        end
        editor:append(t)
        editor:EmptyUndoBuffer()
        editor:SetSavePoint()
        f:close()
    end
    buffer.templateLoaded = true
end

...and add the following to your user properties file:

extension.*.ahk=$(SciteUserHome)\NewAhk.lua

This will probably only work if default.file.ext=.ahk (this is set by default for SciTE4AutoHotkey).

Dadurch wird automatisch jedes neue Script als UTF-8 mit BOM gespeichert. (Es wäre doch schön, wenn mal jemand mit LUA-Druidenwissen uns Ahnungslosen in die Geheimnnisse der Scite-LUA-Programmierung einweihen würde.) In den "user config folder" kommt man übrigens elegant, wenn man unter "Optionen/Benutzereinstellungen öffnen" zunächst in die SciTEUser.properties den Eintrag "extension.*.ahk=$(SciteUserHome)\NewAhk.lua" einfügt, und dann mit der rechten Maustaste auf den Dateireiter "Open containing  Folder" klickt. Hier kann man nun mit dem Text-Editor das geforderte LUA-Skript erstellen und nach dem Speichern als Textdokument in NewAhk.lua umbenennen.

Abschließend möchte ich noch anmerken, dass AHK einerseits eine geniale Sprache ist, wenn es um Tastatur und Mausverwaltung geht, andererseits eine Bastelbaustelle ohnegleichen ist. Ich hatte schon öfter den Eindruck, dass man die Zeit, die man durch die Genialität von AHK spart 10fach durch die bastelhaften AHK-Strukturen zurückzahlen muss - sei es nun durch die mangelhafte Dokumentation oder durch dämliche Bugs, die einfach nicht sein  dürften.

 

M. E. fehlt es an der notwendigen Qualitätssicherung. Mit Sicherheit gibt es etliche Dokumentationsfehler und Software-Bugs von Scite und AHK, die bekannt sind, aber nicht geändert werden, weil wir User nicht motiviert sind, diese mitzuteilen. Hier sind auch die Betreiber dieses Forums gefragt sich zu überlegen, wie man uns User motivieren kann Unzulänglichkeiten mitzuteilen und wie man dann auch nachvollziehbar dafür sorgt, dass diese Bugs beseitigt werden. Vielleicht wäre es sinnvoll eine extra Rubrik anzulegen und Bug-Meldungen anerkennend zu würdigen.

Ich möchte hier noch einen weiteren Bug mitteilen: Aus unerfindlichen Gründen geht die Funktionalität "Open Include" mit der rechtem Maustaste über dem Include-Verweis zeitweise nicht und meldet, dass die Include-Datei nicht gefunden werden kann obwohl das Skript ausgeführt werden kann. Manchmal geht es, manchmal geht es nicht. Früher war dieser Bug nicht da. Die Funktion "Open Containing Folder" mit der rechten Maustatste über dem Datei-Reiter funktioniert jedoch immer. Das Problem bei diesem Bug ist, dass ich keine nachvollziehbaren Umstände aufzeigen kann, unter denen der Bug auftritt und dieser nur zeitweise sein Unwesen treibt.

[nnnik]

Ich weiss zwar nicht woran es liegt (bei mir gehts), aber du kannst ScanCodes benutzen.

Dazu nur eine Ahk Datei mit folgendem Inhalt Starten:

#InstallKeybdHook
#Persistent
KeyHistory
Sleep,10000
Send, {F5}

Du musst innerhalbvon 10 sekunden die gewünschte Taste Drücken dann wird diese nach 10 minuten Automatisch angezeigt.

Sonst musst du nach dem Tastendruck selber F5 drücken.

[SAPlayer]

Meines Wissens muss die Kodierung (also ANSI oder Unicode) von SciTE mit der von AHK übereinstimmen.

 

Wenn du also AHK ANSI installiert hast, musst du in SciTE auch ANSI einstellen, bei Unicode halt Unicode. Frag mich aber bitte nicht wo...

 

EDIT: Anscheinend unter Datei->Kodierung

[nnnik]

Du kannst auch einfach die Sprache von Scite falsch eingestellt haben.

[Harry Hirsch]

Du kannst auch einfach die Sprache von Scite falsch eingestellt haben.

Sowohl unter Sprache als auch unter Extras settings ist die richtige Sprache eingestellt.

[Harry Hirsch]

Meines Wissens muss die Kodierung (also ANSI oder Unicode) von SciTE mit der von AHK übereinstimmen.

 

Wenn du also AHK ANSI installiert hast, musst du in SciTE auch ANSI einstellen, bei Unicode halt Unicode. Frag mich aber bitte nicht wo...

 

EDIT: Anscheinend unter Datei->Kodierung

Ich habe AHK sowohl als Unicode- wie auch als ANSI-Version installiert, jedesmal dasselbe Problem.

[IsNull]

Speichere dein AHK Skript im Unicode (UTF-8) format, nutze den AHK Unicode build.

Du kannst das Format auch mit Notepad kontrollieren, und auch gleich ändern (->Speichern unter, Kodierung UTF-8)

 

Nach der Formatänderung musst du deine Sonderzeichen im Text korrigieren, da der Inhalt nicht zwingend geändert wurde. 

[Harry Hirsch]

Speichere dein AHK Skript im Unicode (UTF-8) format, nutze den AHK Unicode build.

Du kannst das Format auch mit Notepad kontrollieren, und auch gleich ändern (->Speichern unter, Kodierung UTF-8)

 

Nach der Formatänderung musst du deine Sonderzeichen im Text korrigieren, da der Inhalt nicht zwingend geändert wurde. 

Die AHK-Skripte werden im UTF-8 Format gespeichert, dafür sorgt der Eintrag code.page=65001 in der Datei SciTEUser.properties. Ich habe das auch mit Notepad kontrolliert, das ist UTF 8. Außerdem habe ich AHK-Unicode installliert. Irgendwie gibt es einen Kommunikationsfehler zwischen Scite und AHK.

[IsNull]

Irgendwie gibt es einen Kommunikationsfehler zwischen Scite und AHK.

Scite kommuniziert doch nicht mit AHK. Einzig der "F5" Knopf zum starten ruft eine spezifische AHK Interpreter auf. 

 

Aber wenn ein Doppelklick auf die ahk Datei den selben Effekt zeigt, hat das nichts mit Scite zu tun.

[Harry Hirsch]

Scite kommuniziert doch nicht mit AHK. Einzig der "F5" Knopf zum starten ruft eine spezifische AHK Interpreter auf. 

 

Aber wenn ein Doppelklick auf die ahk Datei den selben Effekt zeigt, hat das nichts mit Scite zu tun.

Ein Doppelklick auf die ahk Datei zeigt den selben Effekt. Aber wenn das nichts mit Scite zu tun hat, womit dann?

[ruespe]

Dann öffne sie doch mal im Notepad, speichere sie dort explizit als UTF-8 und ruf sie dann wieder mit Doppelklick auf.

[Harry Hirsch]

Dann öffne sie doch mal im Notepad, speichere sie dort explizit als UTF-8 und ruf sie dann wieder mit Doppelklick auf.

Das kann ich auch mit Scite machen. Man könnte auch ein kleines Skript schreiben, dass alle UTF-8-AHK-Files automatisch mit BOM erweitert. Mir geht es mit den obigen Ausführungen auch darum aufzuzeigen, dass AHK noch an vielen Stellen verbessert werden kann. Im Vergleich mit Autoit, Purebasic und Visual Basic steht AHK an vielen Stellen in Punkto Dokumentation, Zuverlässigkeit und Übersichtlichkeit zurück wobei AHK natürlich den 1. Platz in Punkto Tastatur und Mausverwaltung belegt.