I don't know enough about how AHK interacts with IME. It depends how the Input command catches the characters. You can set up a variable right after the input command that looks like the following:
aTrackChr .= "," . chr
Then after you type a few characters and choose the generated character, Open the AHK Window and look at the variable in the variable list. See if what you originally typed is in the list or if the generated character is there.
not a gadget, but a default software that comes with win7. 1.x does work.
I remembered saying something similar 2 days ago. could the history repeat itself?
I don't know why it wouldn't work, I'll check it out.
A small wordlist containing 6 phrases. But it's a slow, because it's on VirtualBox. hmmm.... Could this be the reason? Yes as I typed the 2nd time, a tooltip started to show, and in the 3rd, 4th, 5th, sometimes the tooltip did not show, then the word did not get learned.
I tried it on my PC with the 100,000 word list and I didn't have any more problems. I don't know why you are having issues. Please try typing very slowly to see if that alleviates the issue. Also I'd try it in native windows, not in a VM (although when I know it works fine in Windows Virtual PC, as I've used it there for testing).
I was able to send out ô, Ô with SendMethod 1 (in EN US keyboard layout) contrary to what AHK documentation claimed. But I faced the same problem as described by a user in page 2 or 3, i.e. it totally cannot send out any characters on my win7. So i switched to SendMethod=2 at the moment, and it should be made default, if there isn't a problem. So far so good, SendMethod=2 is the send method used in 1.x
I've had issues with both SendMethod 1 & 2 not sending characters not on my keyboard layout for some reason. 3 is the most reliable but doesn't buffer keys and is slow (and there are a few potential issue scenarios that are untested with 3). Probably the most reliable method would be one of the copy/paste methods.
Also, SendMethod 3 is what's used in the early versions of 1.X, not SendMethod 2.
There are actually more big issues with SendMethod 2... it uses SendInput which has a bug which prevents it from buffering keys. Pick a really long word (like 20 characters), and hit the button to AutoComplete it. Immediately afterwards (like, almost in perfect sync... it's best to try hitting the buttons at the same time), hit any key which prints a character or affects the output... like a letter or the shift key. You'll notice that your key press is interspersed when it's not supposed to be. This is a big issue with the shift key.
I think SendMethod 1 (SendPlay) is only going to have problems for people who are running other programs which do weird things with the keyboard. Most people shouldn't have any issues with it.
I played some with SetKeyDelay... When in SendMethod 3 setting it to 0 or -1 allows keys to be interspersed (even though I have BlockInput,Send set), but not when it's set to 1 or higher... interesting. This seems to be related to the SendInput bug.
I think SendMethod 1 is one reason we are having problems with backspaces as well. I wonder if we should make 2C, 3C, or 4C one of the dft methods (1C has the backspace issue too)? I would take a guess that most people aren't using programs that keep track of their clipboard.
Scratch that, waiting for data in the clipboard seems pretty unreliable. I'm having issues with it sending the data previously in the clipboard with some of the methods.
So for reliability I'm wondering if we should make SendMethod=3 default then? It would need some testing to make sure everything works ok (especially when hitting hotkeys but not autocompleting them). It has no key buffering, and is slow, but at least doesn't allow interspersion and seems to address the backspace bug.