Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

UNICODE version of AutoHotkey


  • This topic is locked This topic is locked
181 replies to this topic
jackieku
  • Members
  • 73 posts
  • Last active: Dec 26 2011 04:25 AM
  • Joined: 30 Nov 2008
@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.

neh neh pork
  • Guests
  • Last active:
  • Joined: --
awesome! please keep up the good work!

  • Guests
  • Last active:
  • Joined: --
very good news! I will have a try! :D

majkinetor
  • Moderators
  • 4512 posts
  • Last active: Oct 02 2013 02:33 PM
  • Joined: 24 May 2006
Somehow it doesn't work here. I tried msgbox & guiadd, text without any luck. Am I missing something ?

jackieku
  • Members
  • 73 posts
  • Last active: Dec 26 2011 04:25 AM
  • Joined: 30 Nov 2008
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.

  • Guests
  • Last active:
  • Joined: --
The sendinput function doesn't support Unicode characters, such as Chinese characters.

TodWulff
  • Members
  • 142 posts
  • Last active: Sep 15 2013 04:16 PM
  • Joined: 29 Dec 2007

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
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007

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


  • Guests
  • Last active:
  • Joined: --
@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
#encoding utf-8
might be a preferable solution.

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

Sean
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007

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
  • Members
  • 73 posts
  • Last active: Dec 26 2011 04:25 AM
  • Joined: 30 Nov 2008

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
  • Moderators
  • 7045 posts
  • Last active: Today, 06:27 AM
  • Joined: 18 Jun 2008
Looks like AutoHotkey window does not support unicode characters as well. (KeyHistory, ListVars, ListHotkeys, ListLines)
Can this be adapted?

Petru
  • Members
  • 236 posts
  • Last active: Jan 19 2012 06:47 PM
  • Joined: 17 Dec 2007
I'm afraid it doesn't support #includes. It says that the files are not found.

jackieku
  • Members
  • 73 posts
  • Last active: Dec 26 2011 04:25 AM
  • Joined: 30 Nov 2008
@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
  • Moderators
  • 7045 posts
  • Last active: Today, 06:27 AM
  • Joined: 18 Jun 2008

@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