Remove or alter the line "SendMode Input ; Recommended for new scripts due to its superior speed and reliability"

[evilC]

When using AHK for games (And some other applications), SendInput is the last thing you want, as it is immune to SetKeyDelay, and many things want a delay between press and release.
Can we maybe clarify this? As it stands, it causes confusion.

[Noesis]

I tend to think that a better solution to this would be a change to SetKeyDelay so the options for the last parameter could be Play|Input, instead of the current option of Play only, (and nothing being Event), and having Input mode obey the relevant settings. Not sure if that's been wished for before (probably has ?) but I do think it would be a good thing for either V1 or V2 or both.

Regarding the actual statement/comment "Recommended for new scripts due to it's superior speed and reliability" however IMO is accurate, it's just that with some applications (which happens to also be most games) the superior speed is what actually causes the issues, i.e it's too fast. I actually don't know any games that don't work, if you include manual sleeps between down/up sends when using Input mode, but there probably are some, while I have had quite a few instances of Event or Play not working at all. So in my mind it's also the most reliable.

[Helgef]

The following relates mostly to v2, where sendinput is the default sendmode.

I have been thinking about experimenting with the send concept, my rough plan would be to remove sendmodes, and only keeping send() and sendtext(), where both functions call sendInput()(windows function) and obey setkeydelay. sendplay would be removed as it is rarely working on modern systems, and by the time v2 is done it is likely even less modern. In the rare case where sendplay is needed, for a cheating script, one can simply use v1. Further, to increase reliablity, I'd also consider allowing the script to demand no revert to occur. The reverting of sendinput to sendevent is a source of confusion and unreliability imo. The postponing of input during the send is lost when reverting, I think that is more important than speed many times, eg, when sending text. And that relates to the topic, since when one open ones first ahk file, one sees the line "SendMode Input ; Recommended for new scripts due to its superior speed and reliability", and indeed, it is fast and reliable at first, so one doesn't think more about it, but later, one have more scripts running, and one of them is having a kbhook, and another is sending keys, and suddenly one is unknowingly not using sendInput anymore. And sometimes there are problems, which are hard to reproduce (and get help with), since the behaviour is dependent on wether other scripts are using kbhooks or not. So we get all the topics with script no longer working, but code didn't change.

Disregarding my loose ideas, the concept about reverting needs to be more emphasised, and the claims in the docs about most hotkeys not needing a keyboard hook needs to be removed, I think most hotkeys uses them. Especially since users tends to blindly throw in the $ prefix.

Cheers.

[jeeswg]

Perhaps adding in something like {Input} / {Play} / {Event} / {InputThenPlay} to change the modes (temporarily override the default setting) could be a good idea. I can't think of a good word for the traditional mode: {Basic} or something better. [EDIT: Perhaps {Normal}.] All of the modes have their uses. [EDIT:] Perhaps {Event} *is* what I intended by {Basic}/{Normal}, i.e. it's the AHK v1 default.

There are some related comments re. a possible A_SendModeMouse variable at the bottom of this post:
conversion logic, v1 = -> v1 := -> v2, two-way compatibility - Page 7 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 98#p203698

[lexikos]

SendInput ignores SetKeyDelay because the operating system does not support a delay in this mode

SendInput normally fills an array of events and passes the entire array to SendInput() to be sent at once. If there is no hook present, SendInput() postpones other events, which means that it does not need to compensate for physical changes in modifier state during the send. It cannot compensate, because the entire array of events is built at the start, and no AutoHotkey code executes until all events have been sent (but not necessarily "received").

SendEvent {Text} uses SendInput() for each individual character. With or without {Text}, SendEvent applies the key delay and adjusts (or may adjust) for changes in physical modifier state in between each event. This means it has neither the advantages nor disadvantages of SendInput()'s buffering, even if it is using SendInput() for some events. (The advantage of {Text} mode is that it sends character codes, not key codes.)

SendInput can be more reliable for sending sequences of keyboard shortcuts, not just text.

As for changing the template script, feel free to suggest a more specific alteration. If you want to change more than just the comment(s), I suppose there will need to be consensus.

[Helgef]

Thanks lexikos for your comments, I see I need to revert some part of my loose ideas. I guess the lost uninterruptability caused by the presence of a keyboard hook could be worked around by installing a new hook and record any interruptions, block them and resend them after the intended sequence has finished. One could call it blockInput "Postpone" or invoking it under the same circumstances as the current SI revert to SE or maybe make it in script . To excuse my ramblings, I think it is relevant to motivate the word reliability in the discussed comment, that is part of the thread topic.

Cheers.