AutoHotkey Community

Ich habe seit Jahren mit Windows 7 32 Bit und AHK_H a32 gearbeitet. Jetzt bin ich auf Windows 10 64 Bit umgestiegen und lasse dort mein benötigtes Windows 7 32 Bit samt AHK_H a32 auf einer virtuellen VMWare-Maschine laufen. Auf dem Windows 10-Host läuft AHK_H nach wie vor problemlos. Nur auf meinem Windows 7 32 Bit-Guest habe ich plötzlich mit demselben AHK_H und den gleichen Skripts ein Umlaute-Problem. Z. B. Löst die Variable %RückG% die Fehlermeldung aus The following variable name contains an illegal character: "R?ckG". Was ist da los? Kann bitte jemand helfen?

Reflexartig (Versuch macht klug) würde ich auf die "Speichere das Script in UTF-8/16 BOM Encoding ab" Thematik tippen. Ist aber lediglich ein Verdacht
PS. Hast du vorab bereits mal bei @HotKeyIt im AHK_H-Forum angefragt?

@BoBo, danke! Ich fürchte die Umstellung auf UTF-8/16 BOM Encoding, nachdem ich schon so lange (aus Kompatibilitätsgründen!) mit ANSI gearbeitet habe. Damit werde ich noch etwas warten.
Bei HotKeyIt im AHK_H-Forum werde ich auf hier verlinken.

Ich sehe hier gerade, dass man in VMWare die Codepage verändern könnte. Aber die voreingestellte Codepage windows-1252 scheint schon richtig zu sein, vgl. hier, insbesondere auch für ANSI.

Benutzt du die ANSI Version von AHK_H?
Das muss definitiv mit Systemeinstellung zu tun haben, wenn du magst können wir mal über TeamViewer uns anschauen.

Edit:
Du kannst auch gerne AHK_L probieren, sollte das Problem auch kommen.

@HotKeyIt, ja, die ansi-Version AHK_H a32.

Ist der Virtual PC auf Deutsch eingestellt?

Edit:
Was bekommst du hier: MsgBox GetACP()

Ja, der Virtual PC ist Deutsch.
MsgBox % GetACP() ergibt auf dem Virtual PC die Zahl 1252

AHK_L v1.1.33.10 hat das gleiche Problem. Kein Unterschied. Gerade getestet.

MsgBox % GetACP()?

MsgBox % GetACP() ergibt sowohl auf dem Windows 7-Guest als auch auf dem Windows 10-Host die Zahl 1252.

Moin,

wenn ich richtig verstehe, speicherst Du Deine Skripte nicht im UTF-8 Format. Wenn Du AHK in der virtuellen Maschine neu installiert hast, hast Du vielleicht versehentlich die Option "Default to UTF-8" aktiviert?

-> Zeichensatz einer Skript-Datei

@just me, Deine Frage war die ganz entscheidende Frage! Ich habe AHK_L unter Beachtung Deiner Frage diesmal bewußt jetzt ohne die die Option "Default to UTF-8" installiert, was sofort dazu geführt hat, dass das Umlaut-Problem behoben war. Als ich dann wieder auf AHK_H umgestellt habe, war das Problem auch dort behoben. DANKE!

Sollte man diese Option nicht automatisch deaktivieren, wenn ANSI-AHK installiert wird? Im Anschluss daran frage ich mich, wo in der Registry sich die Option "Default to UTF-8" auswirkt, also wo sich das Problem gezielt beheben läßt. Ich frage mich auch, ob es noch andere undokumentierte AHK-Funktionen wie GetACP() gibt...

EDIT:
Ich denke, die richtige Registry-Einstellung lautet jetzt offenbar (etwas kryptisch) wie folgt:

Hi,

soweit ich gelesen habe, fügt der Installer in der Registry dem Aufruf für die AHK-Exe noch die Option /CP65001 hinzu.

GetACP() gibt es nur in AHK-H, weil @HotKeyIt einige API-Funktionen auch ohne DllCall() verfügbar macht. WinAPI

@just me, jetzt hatte ich das Problem bei einem anderen PC wieder. Wenn der von dir benannte Schalter /CP65001 entfernt wird, ist alles gut. Da liegt der Hase im Pfeffer. Viele Grüsse und noch einmal vielen Dank!