Win10 strange behaviour regarding vovel mutations, umlaut

[Jovannb]

Hi,

I got a new PC (Win10, 2004), installed it with AHK (1.1.30.01-32-Ansi) as my former and all other PC's too (they are win10, 1909).

We use many hotstrings in our .ahk-based-Systems, one like that

Code: Select all

::#ffw::
send, Für Fragen und weitere Informationen stehen wir gerne jederzeit zur Verfügung.{enter 1}
return

When I use it on my old PC or one of our other PC's I get:
Für Fragen und weitere Informationen stehen wir gerne jederzeit zur Verfügung
as expected.
When I do the same on my new PC I get:
F?r Fragen und weitere Informationen stehen wir gerne jederzeit zur Verf?gung
there is an umlaut-problem.

Windows-Keyboard, Speech- and Regionalsettings are identical on both (former and new Win10-PC)
I tried the newest AHK-Release (1.1.33.02), same problem. I cant and and i will not change away from AHK-Ansi because of so many of my scripts need that.
How about that issue, who has similar troubles or, better, knows a solution ?

regards
J.B.

[boiler]

What in your other scripts requires ANSI instead of the Unicode version?

[boiler]

Note the following from this post by Lexikos:

Unicode and ANSI versions of AutoHotkey have exactly the same requirements for script file encoding; UTF-8 is recommended, but not required by either version. How the file must be encoded depends on the textual data (source code) of the script, not the version of the executable. All current AutoHotkey versions accept text files ...

• containing only ASCII source code, with neither UTF-8 nor other non-ASCII characters.
• encoded as UTF-8 with BOM.
• encoded as UTF-8 without BOM - or any other codepage - provided that the correct codepage is specified on the command line.
• encoded as ANSI (specifically, the system's current ANSI codepage) when no BOM is present and no codepage is specified on the command line.

[...]

If the file worked with the ANSI version of AutoHotkey (i.e. characters in the source code were read/decoded correctly), then it should be read correctly by the Unicode version of AutoHotkey, without any changes. If there are issues or differences in behaviour, it is not due to how the script source file is encoded.

However, a file which works with the Unicode version might not work with the ANSI version; not because of the file encoding, but because the source code contains characters which cannot be represented in the current ANSI code page.

[Jovannb]

What in your other scripts requires ANSI instead of the Unicode version?

Hi,

I've appr. 80 different scripts, some are new, some are up to 7-8 years old. I remember that I once tried to change to AHK-Unicode, but then I had to stop unsuccessfully.
My scripts eg. read/write access-Databases, write to/from servers via Curl, communication via WMI and so on and many other things and Im sometimes confronted with character encoding.

But thats not the issue now, now I cant understand, why my AHK-Script work proper on Win10-1909 and not so proper on Win10-2004 with obviously the same regional settings.

regards

JB

[Jovannb]

Hi

i did some more tests, with interesting results:
my Code:

Code: Select all

#SingleInstance force
#Persistent
::#xxx::
sendxxx, Für Fragen und weitere Informationen stehen wir gerne jederzeit zur Verfügung.{enter 1}
return

results if I changed to the different send (replaced "sendxxx" with one of the commands below) commands:

Code: Select all

send .. umlaut are missing and ü is shown as question mark
sendraw .. OK, but {enter} is shown as Text
sendinput .. OK
sendplay .. No, nothing appears
sendevent .. OK

It looks like, that "send" causes that problem, sendraw, sendinput, sendevent work as intended.

J.B.