181 replies to this topic

[jackieku]

@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.

[majkinetor]

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

[jackieku]

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.

[TodWulff]

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

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

-t

[Sean]

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

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.

MsgBox % DllCall("RtlMoveMemory", "UintPtrP", x, "UintPtrP", 1, "UintPtr", 4) "|" ErrorLevel "|" x
MsgBox % DllCall("kernel32\RtlMoveMemory", "UintPtrP", x, "UintPtrP", 1, "UintPtr", 4) "|" ErrorLevel "|" x

[Sean]

but IsTextUnicode() cannot handle that if I didn't misunderstand the document.

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	DllCall("advapi32\IsTextUnicode", "Uint", pv, "int", cb, "Uint", 0)
{
	...
}
Else If	cch := DllCall("kernel32\MultiByteToWideChar", "Uint", 65001, "Uint", [color=red]MB_ERR_INVALID_CHARS[/color]:=8, "Uint", pv, "int", cb, "Uint", 0, "int", 0)
{
	...
}
Else If	cch := DllCall("kernel32\MultiByteToWideChar", "Uint", 0, "Uint", 8, "Uint", pv, "int", cb, "Uint", 0, "int", 0)
{
	...
}
Else
{
	Error!
}

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.

[jackieku]

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

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.

[HotKeyIt]

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

[Petru]

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

[jackieku]

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

#Persistent
var := "こんにちは"
ListVars

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?

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

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

[HotKeyIt]

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

#Persistent
var := "こにちは"
ListVars

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?

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

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.

#Include c:\Temp\Script.ahk ;works
#Include Script.ahk ;does not work
#Include .\Script.ahk ;does not work