I'm sorry, but I still can not reproduce these problem here. Were the scripts placed in "working directory" ?#Include c:\Temp\Script.ahk ;works #Include Script.ahk ;does not work #Include .\Script.ahk ;does not work
UNICODE version of AutoHotkey
Started by
jackieku
, Oct 29 2009 08:33 AM
181 replies to this topic
#31
-
Posted 31 October 2009 - 12:55 PM
Host script saved in c:\Temp, as well as Script.ahk.
#32
-
Posted 31 October 2009 - 01:22 PM
So how did you launch the autohotkey.exe, by double click the script file? from command line?Host script saved in c:\Temp, as well as Script.ahk.
#33
-
Posted 31 October 2009 - 01:39 PM
My fault, I was dropping the file onto AutoHotkey.exe, so working directory was wrong.
I thought working directory for #include is always scripts directory :oops:
I thought working directory for #include is always scripts directory :oops:
#Include %A_ScriptDir%\Script.ahk ;works fine :)
#34
-
Posted 31 October 2009 - 01:49 PM
#35
-
Posted 31 October 2009 - 02:13 PM
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).The sendinput function doesn't support Unicode characters, such as Chinese characters.
However, I'll try to work on it since the SendInput() Windows API seems to support this case.
ok, thank you for your quick reply! I'll keep tring to have more fun.
#36
-
Posted 31 October 2009 - 04:37 PM
:shock:
Just awesome. The power of open source code!
Just awesome. The power of open source code!
#37
-
Posted 31 October 2009 - 06:42 PM
My fault, I was dropping the file onto AutoHotkey.exe, so working directory was wrong.
I thought working directory for #include is always scripts directory :oops:#Include %A_ScriptDir%\Script.ahk ;works fine :)
That was my mistake too. My bad. But I guess that compiled scripts' applications won't be using Unicode. Someone should also make a AutohotkeySC.bin to support Unicode.
Hope I'm not demanding too much. And yes, that's why I love open source coding!
#38
-
Posted 31 October 2009 - 06:52 PM
Ok, here's my first AutoHotkeyU script. It calls a Unicode-only API directly without any kind of conversions.
EDIT: Small bugfix.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; THIS SCRIPT REQUIRES AutoHotkeyU ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; #NoEnv ; Sample text here text = ( This is just a demo that shows off AutoHotkeyU and the Vista/7 TaskDialogs. There's not much at the moment but this will support more controls! Hello World in Japanese: こんにちは、世界! Hello World in Chinese: 你好,世界! Hello World in Greek: Γεια σου, κόσμος! Hello World in Russian: Здравствуй, Мир! Hello World in Arabic: مرحبا ، العالم! ) Loop{ var := TaskDialog("AutoHotkeyU TaskDialog demo", "Hello World", text, "ok|cancel|yes|no|retry|close") MsgBox You clicked on %var% if(var = "Cancel" or var = "Close") ExitApp } ; TaskDialog function TaskDialog(title, instruction, text, buttons=0x01, icon=0){ /* http://msdn.microsoft.com/en-us/library/bb760540(VS.85).aspx HRESULT TaskDialog( HWND hWndParent, HINSTANCE hInstance, PCWSTR pszWindowTitle, PCWSTR pszMainInstruction, PCWSTR pszContent, TASKDIALOG_COMMON_BUTTON_FLAGS dwCommonButtons, PCWSTR pszIcon, int *pnButton ); */ if A_OSVersion not in WIN_VISTA,WIN_7 ; WIN_7 put in for possible future implementation in AutoHotkey { MsgBox, 16, %A_ScriptName%, This script requires Windows Vista or later. OnExit ExitApp } If buttons is not integer buttons := TaskDialog_ParseButtons(buttons) If icon is not integer icon := TaskDialog_ParseIcon(icon) ErrorLevel := DllCall("comctl32\TaskDialog", "uint", 0, "uint", 0, "str", title, "str", instruction, "str", text, "uint", buttons, "uint", icon, "int*", ret) Return TaskDialog_GetReturnString(ret) } ; Internal TaskDialog function TaskDialog_ParseButtons(but){ var := 0 StringLower, but, but Loop, Parse, but, |, %A_Space% { if A_LoopField = ok var |= 0x01 else if A_LoopField = yes var |= 0x02 else if A_LoopField = no var |= 0x04 else if A_LoopField = cancel var |= 0x08 else if A_LoopField = retry var |= 0x10 else if A_LoopField = close var |= 0x20 } return var } ; Internal TaskDialog function TaskDialog_ParseIcon(ico){ StringLower, ico, ico ico = %ico% if ico = return 0 else if(ico = "info" or ico = "information") return 0xFFFF - 2 else if ico = warning return 0xFFFF else if(ico = "stop" or ico = "error") return 0xFFFF - 1 else if ico = sec_warning return 0xFFFF - 5 else if ico = sec_error return 0xFFFF - 6 else if ico = sec_success return 0xFFFF - 7 else if ico = sec_shield return 0xFFFF - 3 else if ico = sec_shield_blue return 0xFFFF - 4 else if(ico = "sec_shield_gray" or ico = "sec_shield_grey") return 0xFFFF - 8 else return 0 } ; Internal TaskDialog function TaskDialog_GetReturnString(but){ static IDOK = 1 static IDYES = 6 static IDNO = 7 static IDCANCEL = 2 static IDRETRY = 4 static IDCLOSE = 8 if(but = IDOK) return "OK" else if(but = IDYES) return "Yes" else if(but = IDNO) return "No" else if(but = IDCANCEL) return "Cancel" else if(but = IDRETRY) return "Retry" else if(but = IDCLOSE) return "Close" else return "" }
EDIT: Small bugfix.
#39
-
Posted 31 October 2009 - 07:47 PM
Yes I totally agree:shock:
Just awesome. The power of open source code!
#40
-
Posted 01 November 2009 - 06:22 AM
A new version is uploaded. See the changelog and some outlines at the first post.
#41
-
Posted 01 November 2009 - 02:35 PM
Yesterday I ended up forking your version
I'm currently trying to get RegExes working with non-ASCII characters.
Currently this is what I have:[*:cz79i94m]Fixed IniWrite, it wasn't outputting Unicode files.
[*:cz79i94m]Asc(), Chr() and Windows 7 fixes (although you fixed them in the latest release).
[*:cz79i94m]Added A_IsUnicode which returns 1 if the script is running under AutoHotkeyU.
[*:cz79i94m]UTF-8 was enabled in PCRE although it still doesn't work right.
[*:cz79i94m]get_compiled_regex() now uses native Unicode strings and converts to UTF-8 when calling PCRE.
[*:cz79i94m]Disabled function_order_for_linker_optimization.txt because it was issuing warnings.
[*:cz79i94m]Added a ReleaseANSI target in the project files although the ANSI versions fails at startup.PD: I have VC++ 2008 Express.
I'm currently trying to get RegExes working with non-ASCII characters.
Currently this is what I have:[*:cz79i94m]Fixed IniWrite, it wasn't outputting Unicode files.
[*:cz79i94m]Asc(), Chr() and Windows 7 fixes (although you fixed them in the latest release).
[*:cz79i94m]Added A_IsUnicode which returns 1 if the script is running under AutoHotkeyU.
[*:cz79i94m]UTF-8 was enabled in PCRE although it still doesn't work right.
[*:cz79i94m]get_compiled_regex() now uses native Unicode strings and converts to UTF-8 when calling PCRE.
[*:cz79i94m]Disabled function_order_for_linker_optimization.txt because it was issuing warnings.
[*:cz79i94m]Added a ReleaseANSI target in the project files although the ANSI versions fails at startup.PD: I have VC++ 2008 Express.
#42
-
Posted 01 November 2009 - 04:23 PM
I have been struggling with finding a free mono-spaced unicode compliant font that provided complete coverage for all of the character sets that one might have to code for - either in a multi-lingual script, or in a web-app, without having to resort to the use of multiple fonts.
While coding for western, asian, eastern-block character sets in applications is not insurmountable, having all characters represented accurately in an editor such as Notepad++, in a mono-spaced font (vs. arial unicode ms), proved to be a bit of a challenge.
I present a font set that I just stumbled upon, Unifont, a gnu unicode implementation with a plethora of (dare I say adequate - it is acknowledged that the arabic rendering is not as some might desire/expect.?.) character/glyph coverage.
This font allowed me to have all of the characters in the following code, be rendered as expected in my editor (as depicted here) in an easily readable, mono-spaced font.
Enjoy!
-t
While coding for western, asian, eastern-block character sets in applications is not insurmountable, having all characters represented accurately in an editor such as Notepad++, in a mono-spaced font (vs. arial unicode ms), proved to be a bit of a challenge.
I present a font set that I just stumbled upon, Unifont, a gnu unicode implementation with a plethora of (dare I say adequate - it is acknowledged that the arabic rendering is not as some might desire/expect.?.) character/glyph coverage.
This font allowed me to have all of the characters in the following code, be rendered as expected in my editor (as depicted here) in an easily readable, mono-spaced font.
Hello World in Japanese: こんにちは、世界! Hello World in Chinese: 你好,世界! Hello World in Greek: Γεια σου, κόσμος! Hello World in Russian: Здравствуй, Мир! Hello World in Arabic: مرحبا ، العالم!
Enjoy!
-t
#43
-
Posted 01 November 2009 - 07:37 PM
When replying, please feel free to address me as Tod. My AHK.net site...
I'm feeling rather unfortunate to have to test separately two new big features, Object and Unicode. Anyway, may I ask why you chose the function name StringGet, instead of e.g., StrGet etc? StringGet appears to me rather out of tune with current naming scheme of AHK, either NumGet/NumPut or InStr/SubStr. I'm just becoming concerned/curious about the opinions of Chris and/or Lexikos and/or other developers, under the assumption that someday these big features are incorporated into the official build.
And, personally, I hope characters like ? [ ] disabled in variable names as in AutoHotkey_L.
And, personally, I hope characters like ? [ ] disabled in variable names as in AutoHotkey_L.
#44
-
Posted 02 November 2009 - 12:36 AM
Me tooAnd, personally, I hope characters like ? [ ] disabled in variable names as in AutoHotkey_L.
#45
-
Posted 02 November 2009 - 12:43 AM
Never lose.
WIN or LEARN.
WIN or LEARN.