AutoHotkey Community

@Sean

It always puts "a character" at the tail of the buffers, hence it is 2 bytes in this version.

The bugs in NumGet() and NumPut() will be fixed in the next release, thank for your report. However, since AutoHotkey always set the capacity of a variable >= 4 bytes, there are some differences between original version and Unicode version in your examples. Because it attempts to read a "UInt" (4 bytes) from a variable but it set its capacity to 2 (AutoHotkey extends it to 4 bytes internally).

@JimKarvo

I'll add some options to File* to support files in different charsets.

awesome! please keep up the good work!

very good news! I will have a try!

Somehow it doesn't work here. I tried msgbox & guiadd, text without any luck. Am I missing something ?

_________________

There are some updates, please check them at the first post.

@majkinetor
The script files must be saved with a BOM if your scripts contain the characters outside your system codepage.

The sendinput function doesn't support Unicode characters, such as Chinese characters.

Could you please point to guidance that might explain to those of us new to using unicode how we might accomplish same? TIA.

-t

_________________
When replying, please feel free to address me as Tod. My AHK.net site...

How about checking next with IsTextUnicode API when there is no BOM? I suppose it can detect many scripts in UTF-16LE at least. BTW, it seems now have to specify the dll file name, even for kernel32 etc, in DllCall.

@Sean

I think UTF-16LE w/o BOM files are used rarely, and only few text editors support to edit them. The files in UTF-8 w/o BOM are used much more, but IsTextUnicode() cannot handle that if I didn't misunderstand the document.

I think something like

might be a preferable solution.

About the DllCall(), I'll take a look around it.

Yes, AFAIK, there exist no (direct) API to check against UTF-8 in Windows. However, I think can utilize (indirectly) MultiByteToWideChar API. The routine would look like

If it doesn't work I suppose can build a custom routine to detect UTF-8, as that's fairly straightforward for UTF-8, but, the problem is speed.

Because SendInput was intent to send a series of key events (not characters). When we type Chinese characters we need a software called input method engine (IME), but the keyboard is the same with the ones in U.S. (same keymap).

However, I'll try to work on it since the SendInput() Windows API seems to support this case.

Looks like AutoHotkey window does not support unicode characters as well. (KeyHistory, ListVars, ListHotkeys, ListLines)
Can this be adapted?

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun

I'm afraid it doesn't support #includes. It says that the files are not found.

@HotKeyIt
I tested it with the script below. (the string is in Japanese, whereas my system code page is traditional Chinese)

It display those characters properly, but I guess it is affected by the font used in that window. Anyway, could you provide a script for me to for testing?


But it works just fine here, please provide more details. (how to reproduce)

Very odd, on my system, the only program that can display your text is MSWord
So also AutoHotkey Main Window does not display it right.
Must be something system dependant.

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun