Makes Send synonymous with SendEvent or SendPlay rather than the default (SendInput). Also makes Click, MouseClick, MouseClickDrag, and MouseMove use the specified mode.
PrevMode := SendMode(Mode)
Type: String
Specify one of the following words to change the sending mode for subsequent occurrences of Send, SendRaw, Click, MouseClick, MouseClickDrag, and MouseMove:
Event: Switches to the traditional SendEvent mode.
Input: Default mode. Switches to the SendInput mode, which is the fastest and generally the most reliable method to send simulated keystrokes and mouse clicks.
Play: Switches to the SendPlay mode, which is faster than SendEvent and can work in cases where the other modes fail, particularly in some games or applications with unusual input handling.
InputThenPlay: Same as Input except that rather than falling back to Event when Input is unavailable, it reverts to Play. This also causes the SendInput function itself to revert to Play when Input is unavailable.
Type: String
This function returns the previous setting.
The following sections describe the three methods AutoHotkey uses to send simulated keystrokes and mouse clicks: SendEvent, SendInput, and SendPlay. Each mode has different strengths and limitations, and applications may respond differently depending on how the input is generated. Understanding these differences helps in choosing the most effective mode for a particular script or target application.
SendEvent is the traditional method to send keystrokes and mouse clicks. However, compared to the other sending modes, SendEvent is slower; it will never match the speed of SendInput or SendPlay.
SendEvent obeys the delays set by SetKeyDelay and SetMouseDelay. The default delay is 10 milliseconds.
SendEvent is also used automatically when SendInput is unavailable, unless InputThenPlay is in effect.
The SendEvent function can be used to send keystrokes explicitly via SendEvent mode.
SendInput is generally the preferred method to send keystrokes and mouse clicks because of its superior speed and reliability. Under most conditions, SendInput is nearly instantaneous, even when sending long strings. Since SendInput is so fast, it is also more reliable because there is less opportunity for some other window to pop up unexpectedly and intercept the keystrokes. Reliability is further improved by the fact that anything the user types during a SendInput is postponed until afterward.
Unlike the other sending modes, the operating system limits SendInput to about 5000 characters (this may vary depending on the operating system's version and performance settings). Characters and events beyond this limit are not sent.
Note: SendInput ignores SetKeyDelay and SetMouseDelay because the operating system does not support a delay in this mode. However, when SendInput reverts to SendEvent under the conditions described below, it uses SetKeyDelay -1, 0 (unless SendEvent's KeyDelay is -1,-1, in which case -1,-1 is used). When SendInput reverts to SendPlay due to InputThenPlay, it uses SendPlay's KeyDelay.
If the script has a low-level keyboard hook installed, SendInput automatically uninstalls it prior to executing and reinstalls it afterward. As a consequence, SendInput generally cannot trigger the script's own hook hotkeys or InputHooks. The hook is temporarily uninstalled because its presence would otherwise disable all of SendInput's advantages, making it inferior to both SendPlay and SendEvent. However, this can only be done for the script's own hook, and is not done if an external hook is detected as described below.
When SendInput sends mouse clicks by means such as {Click}, and CoordMode "Mouse", "Window" or CoordMode "Mouse", "Client" is in effect, every click will be relative to the window that was active at the start of the send. Therefore, if SendInput intentionally activates another window (by means such as alt-tab), the coordinates of subsequent clicks within the same function will be wrong if they were intended to be relative to the new window rather than the old one.
The SendInput function can be used to send keystrokes explicitly via SendInput mode.
Known limitations:
SendEvent "!{Left}" or SendInput "{Backspace}".Deprecated: SendPlay does not tend to work if User Account Control (UAC) is enabled, even if the script is running as an administrator. For more information, refer to the FAQ. On Windows 11 and later, SendPlay may have no effect at all.
SendPlay's biggest advantage is its ability to "play back" keystrokes and mouse clicks in a broader variety of games than the other modes. For example, a particular game may accept hotstrings only when they have the SendPlay option.
Of the three sending modes, SendPlay is the most unusual because it does not simulate keystrokes and mouse clicks per se. Instead, it creates a series of events (messages) that flow directly to the active window (similar to ControlSend, but at a lower level). Consequently, SendPlay does not trigger hotkeys or hotstrings.
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.
Although SendPlay is considerably slower than SendInput, it is usually faster than the traditional SendEvent mode (even when KeyDelay is -1).
The Windows keys (LWin and RWin) are automatically blocked during a SendPlay if the keyboard hook is installed. This prevents the Start Menu from appearing if the user accidentally presses a Windows key during the send. By contrast, keys other than LWin and RWin do not need to be blocked because the operating system automatically postpones them until after the SendPlay (via buffering).
SendPlay obeys the delays set by SetKeyDelay and SetMouseDelay if their Play parameter is present. Unlike SendEvent, SendPlay defaults to -1 (no delay at all).
SendPlay is unable to turn on or off the CapsLock, NumLock, or ScrollLock keys. Similarly, it is unable to change a key's state as seen by GetKeyState unless the keystrokes are sent to one of the script's own windows. Even then, any changes to the left/right modifier keys (e.g. RControl) can be detected only via their neutral counterparts (e.g. Control).
Unlike SendInput and SendEvent, the user may interrupt a SendPlay by pressing Ctrl+Alt+Del or Ctrl+Esc. When this happens, the remaining keystrokes are not sent but the script continues executing as though the SendPlay had completed normally.
Although SendPlay can send LWin and RWin events, they are sent directly to the active window rather than performing their native operating system function. To work around this, use SendEvent. For example, SendEvent "#r" would show the Start Menu's Run dialog.
The SendPlay function can be used to send keystrokes explicitly via SendPlay mode.
Known limitations:
SendEvent "{Click 6 52 Down}{Click 45 52 Up}".SendEvent "{WheelDown 5}".SendMode "Play" during the script startup, all remapped keys are affected and might lose some of their functionality. See SendPlay remapping limitations for details.The default sending mode is Input.
Since SendMode also changes the mode of Click, MouseMove, MouseClick, and MouseClickDrag, there may be times when you wish to use a different mode for a particular mouse event. The easiest way to do this is via {Click}. For example:
SendEvent "{Click 100 200}" ; SendEvent uses the older, traditional method of clicking.
If SendMode is used during script startup, it also affects keyboard and mouse remapping. In particular, if you use SendMode "Play" with remapping, see SendPlay remapping limitations.
The built-in variable A_SendMode contains the current setting and can also be assigned a new value instead of calling SendMode.
Every newly launched thread (such as a hotkey, custom menu item, or timed subroutine) starts off fresh with the default setting for this function. That default may be changed by using this function during script startup.
Send, SetKeyDelay, SetMouseDelay, Click, MouseClick, MouseClickDrag, MouseMove