AutoHotkey Community

[STEPHANVS]

Maybe I didn't search hard enough, but I didn't find this request

It'll be great to have UNICODE support in AutoHotKey, and probably not only for me. I am trying to make some text presentation script, and combining the script posibilities with some DllCalls it's quite fancy... Still more "mobile", and adjustable at any time, anywhere, then a programing language. Problem is, I can't display characters like "ő, Ő, ű, Ű", and it's quite unesthetic using "õ, ô, Õ, Ô, û, Û" instead.

I have tried AutoIt, but AutoHotKey has more funcions, posibilities, that'll be usefull for me...

Thanks.

[engunneer]

i think it is one of the primary planned features for AHK v2.0
_________________
Unless otherwise noted, all code is untested.
Common Answers: 1.(Loops, Viruses, etc.) 2. Search 3.RTFM

[Tuncay]

Yes, Unicode support for AutoHotkey would be one of the most needed and useful "features".

I was about to use AutoIt as my primary "language", only because Unicode support. But I dont like AutoIt and so... I am still with AutoHotkey. Hope v2 will support this.

[STEPHANVS]

v2.0? Cool, v1.1 still not out yet

Anyway, I hope it's on the to do list

Regards,
Istvan

[riopapa@paran.com]

AutoHotKey is fantastic, and it give me much productivity.

But, myself including Asian user who use double byte characters have no way to generate our own text.

send, 한글로 입력 (Korean Charactors)
is changed to
send,한글로 ìž…ë ¥

It is critical especially for searching words....
Is there anybody who can help me?

[PhiLho]

See Function for sending Unicode text
_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

[automaton]

Seriously, it should be on top of the todo list. This is year 2008.
All Microsoft's OSes starting from Win2000 (or maybe even NT4) not just support unicode, they are unicode in their core - ansi versions of all API functions are just wrappers of their unicode counterparts. Like it or not, this isn't going to change back.
AHK needs to keep up with the times and go global. AU3 did it a year ago, and I think that gave them a pretty big boost.
Without this AHK will remain very niche software, with a lot of its features, which you keep on adding, not utilized to their full potential.
Even filepaths with non-ansi characters are not so rare nowadays, and unicode text data is simply commonplace. So what use are these filepattern loops, if the lack of unicode support makes them buggy? What use are all these string manipulation functions? GUIs? Limited use, that's what.
It's a shame, really, because AHK has a lot of nice things going compared to the competition - hotkey system, working with binary data, built in sorting, accessible vars, performance - all better.

[joehtg]

I fully agree with automaton.

BTW. there is another wish list thread referring to Unicode, last comment December 2006!
http://www.autohotkey.com/forum/topic8327.html&highlight=unicode

It is a severe restriction that Autohotkey is limited to the handful languages supported by the local ANSI codepage. On a western european installation, Autohotkey cannot spell correctly České Budějovice (Budweis), because Autohotkey is a Non-Unicode installation, not to mention Cyrillic, Greek...

Reminds me of the cold war and the iron curtain.

I agree with majkinetor on the old thread above that internal processing should be done in UTF-16 with the help of TCHAR macros, as required by the Win32-API. With the help of TCHAR macro you get from a single source either a Unicode version (if _UNICODE and UNICODE are defined) as well as the current single codepage version otherwise. Unfortunately, the library PCRE (Perl-compatible regular expressions) only has an option for UTF-8, not for UTF-16. Maybe ICU functions could be used or adapted? (ICU stands for International Component for Unicode, Opensource, see www.icu-project.org)
In my opinion, UTF-16 is the best choice for internal processing. First it is the native character representation of Win32, but there are other good examples like Java, Oracle OCI, ICU.

[Azerty]

Even though I agree on the benefits of native unicode support, I really think that it's a shame is too much.

I really don't know if Chris made Autohotkey for fame, but should it be "a niche", so long... We're still 7889 forum users, and probably many more AHK users... not as much as MS Office users, but not so low a number...

Chris posted several times to have help in coding AutoHotkey... When you lack support, open source code, make it unicode compatible, give it back to Chris, I'm sure he'll be happy to integrate it in next version with apropriate credit to the coder. It might even become v1.50 !!!

I believe the spare time he spends on AHK is already a great benefit for all of us users who don't enter the difficulties of making AHK go faster toward it's 2.0 version. Think of it when choosing your words, please.

BTW, if AU3 is unicode aware, for those who really lack unicode support, AU3 is an option until AHK v2.0

(no flame meant)