AutoHotkey Community

Hi all. I mainly use Autohotkey to quickly type accented and otherwise obscure Unicode glyphs not normally accessible via the keyboard (e.g. macrons and dots over or under characters, etc).

The basic syntax is like this:



This works perfectly for almost everything, with the exception of a handful of characters whose double-byte codes (the bit after uc =) end in a no-break space (U+00A0), in which case the keyboard input is replaced by nothing (i.e. it's deleted, not replaced).

I'm on XP. The behaviour occurs in AutoHotkey 1.0.48 (which I know is old), but also in the latest AutoHotkey_L (v1.1.00.00), with the following syntax:



Strangely, not all characters whose double-byte codes end in no-break space are affected. From my own list of several hundred substitutions, the only characters affected by this are those in the example above, namely Ạ Ġ Ṡ and Ḡ - all of whose doublebyte codes end in no-break space.

The problem is definitely not font-related.

Could someone please have a look at the double-byte code parser and see what it does with no-break spaces.

Many thanks

[Moved from Bug Reports. ~jaco0646]

Both scripts work for me on Windows XP and 7 - the first with AutoHotkey Basic, the second with AutoHotkey_L. The first script did not work in Notepad on XP (just gave squares), but it worked in Notpad on 7 and Wordpad on XP and 7. However, I did have to replace the space after Ạwith a non-breaking space (I presume your browser, my browser or the forum software screwed up).
Aside from the file-reading code in AutoHotkey_L (which you can verify is working correctly by simply using MsgBox), there is no "double-byte code parser". Besides, most of those characters are triple-byte UTF-8 sequences. AutoHotkey Basic doesn't do anything with your "UTF-8" string beside pass it to the operating system's conversion function. Since Transform Unicode in AutoHotkey Basic and hotstrings in AutoHotkey_L have very little in common, it seems more likely that the problem is with the program you're using or your system.

I'd suggest you should make sure your file is saved as UTF-8 when using AutoHotkey_L, but you'd probably have more broken hotstrings if it wasn't already.

Lexikos,

Your report of the script working fine prompted me to try it again today, and to my surprise it now works. I presume the code was broken in the older version of AutoHotKey I'd been using, bits of which hung about in memory after I installed AutoHotKey-L. One reboot later, voila...

Thanks for your swift reply, and my apologies for the wild goose chase.