Hi Folks,
Maybe I'm just not understanding what "buffer" means(??) Please try running the below code... Now, with your right hand, "strum" the mnbv keys (which are in a row). This lets you press them in succession very quickly. My text string has 50 characters, and seems to take approx 1 sec to type out. I'm using SendInput, so I expect that the m should activate the code, then the nbv should be "held" in memory, and typed after the string is sent. Thus resulting in. 12345678901234567890123456789012345678901234567890nbv. Instead, I'm getting what you see in the block comment. The letters are interspersed with the numbers.
Am I misunderstanding what "buffer" means, or maybe doing something wrong??
I'm using RaptorX's Live Code tool, which appears to be running AHK v2.0.2.
Well, according to the docs, you are interpreting it correctly:
SendInput and SendPlay: SendInput and SendPlay use the same syntax as SendEvent but are generally faster and more reliable. In addition, they buffer any physical keyboard or mouse activity during the send, which prevents the user's keystrokes from being interspersed with those being sent. SendMode can be used to make Send synonymous with SendInput or SendPlay. For more details about each mode, see SendInput and SendPlay below.
Yeah, the doc files for SendPlay also suggest my interpretation is correct...
Like SendInput, SendPlay's keystrokes do not get interspersed with keystrokes typed by the user. Thus, if the user happens to type something during a SendPlay, those keystrokes are postponed until afterward.
Regarding using SendPlay, I'm not having any luck at all there... This (screenshot) means that my UAC is off -- correct?
Also, I'm an Admin, but the string doesn't get sent. The hotstring trigger does disappear though... So the script is playing. Maybe my Windows installation has just gone wacky.
Joe Glines on the Automator group suggested just using paste.
EDIT: Just posted there. @RussF do you get a similar effect with the code?
An interesting thing... Not sure if that means anything, but if I start one key to the right, such that I'm pressing ,mnb then I do reliably get the expected ,12345678901234567890123456789012345678901234567890nb
Nope - just tried it in V2 - works as it should - in Notepad at least. I see @lexikos replied in the bug forum. Perhaps there is something else going on in your PC.
Thanks for checking, Russ. It certainly is a strange thing. Based on Lexikos' comments it occurred to me to try exiting all my other apps (including several ahk scripts), and trying again. The effect is way way less, but still occurs. It's strange, but when I do something like exit another app, or restart the above script, I'll often get several correct executions, followed by several with the characters interspersed.
I changed the script to use x as a trigger, and 'strummed' xcvb, since I'm actually left-handed. Also, I replaced the digits with 50 lower L characters to make the misfires easier to see. The below sample was typed into Notepad. The rate was a little over a second per line.
you can see how it starts with several correct executions, then consistent misfires that are interspersed with correct executions.
I also tried in Adventure, VSCode, TED Notepad, and an Outlook email. The effects were similar in all. Also updated my keyboard driver and restarted Windows.
EDIT: I asked ChatGPT4 for advice. The results were actually pretty good! For entertainment purposes, here is my meandering prompt, and the ai feedback:
Prompt:
Spoiler
Regarding Windows 10, are the keyboard hook and the mouse hook that same thing? I am trying to diagnose an issue with AutoHotkey. When I use the SendInput command in an AHK script, the Windows keyboard input should get buffered and "held" to play back after the string of text is sent from the SendInput command. I'm finding that this buffering is not happening though. Instead, the manual keyboard input from my typing, gets interspersed with the text string that is sent via SendInput. Is it possible that some other application that is running on my computer is interfering with the keyboard hook? If another application is accessing the mouse hook, would it have the same effect? Can you think of any other things to try, in diagnosing this problem?
Feedback:
Spoiler
In the context of Windows and scripting or automation tools like AutoHotkey, keyboard hooks and mouse hooks are not the same thing, but they serve similar purposes: capturing and manipulating input events.
1. **Keyboard Hook**: A keyboard hook is a mechanism that allows an application or script to monitor and intercept keyboard events, such as key presses and key releases. AutoHotkey often uses keyboard hooks to capture keyboard input and perform actions based on the input.
2. **Mouse Hook**: A mouse hook, on the other hand, allows an application or script to monitor and intercept mouse events, like mouse clicks and movements. It's used when you want to perform actions based on mouse input.
Regarding your specific issue with AutoHotkey and the SendInput command, the behavior you described suggests that there might be interference with the keyboard hook or other issues related to input handling. Here are some steps to diagnose and troubleshoot the problem:
1. **Check for Other AutoHotkey Scripts**: Ensure that you don't have other AutoHotkey scripts running concurrently that might be conflicting with the one causing the issue.
2. **Check for Other Input Manipulation Software**: Other applications, such as macro recorders, gaming utilities, or accessibility tools, could potentially interfere with keyboard input. Try disabling or closing any such applications temporarily to see if the issue persists.
3. **Check for Antivirus or Security Software**: Some antivirus or security software can interfere with keyboard hooks for security reasons. Temporarily disabling or configuring these programs to exclude AutoHotkey scripts can help diagnose the problem.
4. **Update or Reinstall AutoHotkey**: Ensure you are using the latest version of AutoHotkey. Consider reinstalling AutoHotkey to rule out any potential corruption of the software.
5. **Test in Safe Mode**: Boot your computer into Safe Mode and run your AutoHotkey script to see if the issue still occurs. This can help determine if a third-party application or driver is causing the problem.
6. **Check for Conflicting Hotkeys**: Review your AutoHotkey script for any conflicting hotkey assignments or SendInput commands that might be causing unexpected input.
7. **Use Different Send Methods**: Instead of SendInput, try using other Send methods in AutoHotkey, such as Send, SendRaw, or SendEvent, to see if the issue persists with these methods.
8. **Debugging Tools**: AutoHotkey provides debugging tools and logging capabilities. Use these tools to track the execution of your script and identify any unusual behavior.
9. **Consult AutoHotkey Forums**: The AutoHotkey community forums are a valuable resource for troubleshooting and getting help with script-related issues. Others may have encountered similar problems and can provide guidance.
10. **Consider Hardware Issues**: In rare cases, hardware issues with your keyboard or mouse may cause input problems. Test with a different keyboard and mouse to rule out this possibility.
By following these steps, you should be able to diagnose and resolve the issue you're experiencing with AutoHotkey and ensure that the keyboard input buffering behaves as expected.
Additional Update: I restarted Win 10 in Safe Mode, then double-clicked the script (which opens it for editing in VScode, per my settings). Then ran it from there. It worked 100% flawlessly! I then increased the length of my string from 50 to 300. With the longer string, the keyboard buffer took a couple of "pushes" to "push out" and send all of the text, but again, the three manually-typed characters appeared after the string on 100% of many trials. (Tried in VSCode and in TED Notepad).
So presumably I have another app that is "winning" in the battle for the keyboard hook (???) I dunno. I'll post again if I learn more.
----------
Another update: Well I exited everything I could on the Win Systray, then opened Task Manager and killed all the Google stuff, Windows Defender and several "Windows Security" things... Still the misfires persist. I dunno..
----------
Update: Just some notes for the curious... I restarted in safe mode again. The script then worked as exprected (again). I wanted to take a screenshot of what was in Task Manager, so I could compare it with Task Manager after a normal restart. Apparently neather the Windows Snipping Tool, nor SnagIt will take a screenshot of TaskMan when in safe mode -- Arghhhh....
Then (still in safe mode) I started running different apps, and systematically tried to see if any would cause propblems with the SendInput test script. I have two "MasterScripts" which contain tons of little (on not so little) sub-scripts. One of them is v1 code and contains the sub-scripts which I haven't gotten around to converting to v2, to put in my v2 MasterScript. Anyhow... Running either one of these would "break" the test script (presumably "stealing" the keyboard hook). I then systematically started commenting-out different portions of my v1 masterscript, to see if there was some particular section that was problematic. I eventually commented-out everything but the autoexe section (about 5 lines at the top), but the test script was still broken. At that point, exited the v1 masterscript, but the keyboard hook problem was still there. Then I got frustrated and quit.
Running either one of these would "break" the test script
Of course.
If a script other than the one executing SendInput has a low-level keyboard hook installed, SendInput automatically reverts to SendEvent (or SendPlay if SendMode "InputThenPlay" is in effect). This is done because the presence of an external hook disables all of SendInput's advantages, making it inferior to both SendPlay and SendEvent. However, since SendInput is unable to detect a low-level hook in programs other than AutoHotkey v1.0.43+, it will not revert in these cases, making it less reliable than SendPlay/Event.
I eventually commented-out everything but the autoexe section (about 5 lines at the top)
In practice, input is not buffered if any keyboard hooks are present. This is why AutoHotkey uninstalls its own keyboard hook, or falls back to SendEvent/SendPlay if it can detect that another script has a keyboard hook.
I eventually commented-out everything but the autoexe section (about 5 lines at the top)
Something like #InstallKeybdHook?
LOL. A logical conclusion, but no. I don't think #InstallKeybdHook or InstallKeybdHook is used in any of my scripts. Your reply did prompt me to try both in my own (v1, then v2) scripts. Alas, no joy.
Lexikos (or others), regarding:
However, since SendInput is unable to detect a low-level hook in programs other than AutoHotkey v1.0.43+
Does this imply that AutoHotkey is generally able to detect keyboard hooks in other AutoHotkey scripts, and uninstall them when needed?
Also, should restarting a script (one which uses keyboard hooks), usually cause it to again take precedence with respect to sending instructions to the windows keyboard hook? (Assuming that the other script does not utilize a loop to constantly reestablish a keyboard hook, or somehow establish the hook at a 'lower level').
Hopefully these are not dumb questions... I'm actually not a programmer at all.
Does this imply that AutoHotkey is generally able to detect keyboard hooks in other AutoHotkey scripts
Yes.
and uninstall them when needed?
No.
The documentation explicitly states what happens when there are hooks installed by other scripts. It's emphasized in the quote I posted.
Also, should restarting a script (one which uses keyboard hooks), usually cause it to again take precedence with respect to sending instructions to the windows keyboard hook?
The script does not "send instructions to the windows keyboard hook". There is not one "windows keyboard hook". Each script may have its own keyboard hook, to which the system sends events. The most recently installed hook is called first for each event, and then if it calls CallNextHookEx, the next hook is called. As for the reliability of SendInput, the order that the hooks are called in is not relevant.
)