The sequence of keys to send. As with other commands, the comma in front of the first parameter is optional.

By default (that is, if neither SendRaw nor the Raw mode or Text mode is used), the characters ^+!#{} have a special meaning. The characters ^+!# represent the modifier keys Ctrl , Shift , Alt and Win . They affect only the very next key. To send the corresponding modifier key on its own, enclose the key name in braces. To just press (hold down) or release the key, follow the key name with the word "down" or "up" as shown below.

Note: As capital letters are produced by sending Shift , A produces a different effect in some programs than a . For example, !A presses Alt + Shift + A and !a presses Alt + A . If in doubt, use lowercase.

The characters {} are used to enclose key names and other options , and to send special characters literally. For example, {Tab} is Tab and {!} is a literal exclamation mark.

[v1.1.27+] : Enclosing a plain ASCII letter (a-z or A-Z) in braces forces it to be sent as the corresponding virtual keycode, even if the character does not exist on the current keyboard layout. In other words, Send a produces the letter "a" while Send {a} may or may not produce "a", depending on the keyboard layout. For details, see the remarks below .

Send variants

Send: By default, Send is synonymous with SendEvent; but it can be made a synonym for SendInput or SendPlay via SendMode .

SendRaw: Similar to Send, except that all characters in Keys are interpreted and sent literally. See Raw mode for details.

SendInput and SendPlay [v1.0.43+] : SendInput and SendPlay use the same syntax as Send 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.

SendEvent [v1.0.43+] : SendEvent sends keystrokes using the same method as the pre-1.0.43 Send command. The rate at which keystrokes are sent is determined by SetKeyDelay .

Special modes

The following modes affect the interpretation of the characters in Keys or the behavior of key-sending commands such as Send, SendInput, SendPlay, SendEvent and ControlSend . These modes must be specified as {x} in Keys , where x is either Raw, Text, or Blind. For example, {Raw} .

Raw mode

The Raw mode can be either enabled with {Raw} , SendRaw or ControlSendRaw , which causes all subsequent characters, including the special characters ^+!#{} , to be interpreted literally rather than translating {Enter} to Enter , ^c to Ctrl + C , etc. For example, both Send {Raw}{Tab} and SendRaw {Tab} send {Tab} instead of Tab .

The Raw mode does not affect the interpretation of escape sequences , variable references and expressions . For example, SendRaw ``100`% sends the string `100% . When using ControlSend , it is also necessary to escape literal commas ( `, ).

Text mode [v1.1.27+]

The Text mode can be enabled with {Text} , which is similar to the Raw mode, except that no attempt is made to translate characters (other than `r , `n , `t and `b ) to keycodes; instead, the fallback method is used for all of the remaining characters. For SendEvent, SendInput and ControlSend , this improves reliability because the characters are much less dependent on correct modifier state. This mode can be combined with the Blind mode to avoid releasing any modifier keys: Send {Blind}{Text}your text . However, some applications require that the modifier keys be released.

`n , `r and `r`n are all translated to a single Enter , unlike the default behavior and Raw mode, which translate `r`n to two Enter . `t is translated to Tab and `b to Backspace , but all other characters are sent without translation.

[v1.1.29+] : Like the Blind mode, the Text mode ignores SetStoreCapsLockMode (that is, the state of CapsLock is not changed) and does not wait for Win to be released . This is because the Text mode typically does not depend on the state of CapsLock and cannot trigger the system Win + L hotkey. However, this only applies when Keys begins with {Text} or {Blind}{Text} .

Blind mode

The Blind mode can be enabled with {Blind} , which gives the script more control by disabling a number of things that are normally done automatically to make things work as expected. {Blind} must be the first item in the string to enable the Blind mode. It has the following effects:

The Blind mode is used internally when remapping a key . For example, the remapping a::b would produce: 1) "b" when you type "a"; 2) uppercase "B" when you type uppercase "A"; and 3) Ctrl + B when you type Ctrl + A .

{Blind} is not supported by SendRaw or ControlSendRaw ; use {Blind}{Raw} instead.

The Blind mode is not completely supported by SendPlay , especially when dealing with the modifier keys (Ctrl, Alt, Shift, and Win).

Key names

The following table lists the special keys that can be sent (each key name must be enclosed in braces):

Sends an Alt +nnnnn keypad combination, which can be used to generate special characters that don't exist on the keyboard.

To generate printable ASCII characters or other characters from the system's OEM (DOS) code page, specify a number between 1 and 255. DllCall("GetOEMCP", "UInt") returns the current OEM code page number, such as 437 (United States) or 850 (Western Europe) .

To generate ANSI characters (standard in most languages), specify a number between 128 and 255, but precede it with a leading zero, e.g. {Asc 0133} . DllCall("GetACP", "UInt") returns the current ANSI code page number, such as 1252 (United States, Western Europe, etc.) .

Unicode characters may be generated by specifying a number between 256 and 65535 (without a leading zero). However, this is not supported by all applications. For alternatives, see the section below.

[AHK_L 24+] : Sends a Unicode character where nnnn is the hexadecimal value of the character excluding the 0x prefix. This typically isn't needed in Unicode versions of AutoHotkey, where Send and ControlSend automatically support Unicode text.

SendInput() or WM_CHAR is used to send the character and the current Send mode has no effect. Characters sent this way usually do not trigger shortcut keys or hotkeys.

{vkXX}
{scYYY}
{vkXXscYYY}

Sends a keystroke that has virtual key XX and scan code YYY. For example: Send {vkFFsc159} . If the sc or vk portion is omitted, the most appropriate value is sent in its place.

The values for XX and YYY are hexadecimal and can usually be determined from the main window 's View-> Key history menu item. See also: Special Keys

Warning: Combining vk and sc in this manner is valid only with Send. Prior to [v1.1.27] , hotkeys permitted but ignored any non-hexadecimal characters following XX.

Sends a mouse button event at the cursor's current position (to have control over position and other options, use {Click} above). The delay between mouse clicks is determined by SetMouseDelay . WheelLeft/Right require [v1.0.48+] , but have no effect on operating systems older than Windows Vista.

LButton and RButton correspond to the "physical" left and right buttons when used with Send, but the "logical" left and right buttons when used with hotkeys. In other words, if the user has swapped the buttons via system settings, {LButton} performs a logical right click, but a physical left click activates the RButton:: hotkey. Likewise for {RButton} and LButton:: . To always perform a logical click, use {Click} instead.

Repeating or Holding Down a Key

To repeat a keystroke: Enclose in braces the name of the key followed by the number of times to repeat it. For example:

Send {DEL 4}  ; Presses the Delete key 4 times.
Send {S 30}   ; Sends 30 uppercase S characters.
Send +{TAB 4}  ; Presses Shift-Tab 4 times.

To hold down or release a key: Enclose in braces the name of the key followed by the word Down or Up . For example:

Send {b down}{b up}
Send {TAB down}{TAB up}
Send {Up down}  ; Presses down the up-arrow key.
Sleep 1000  ; Keeps it down for one second.
Send {Up up}  ; Releases the up-arrow key.

When a key is held down via the method above, it does not begin auto-repeating like it would if you were physically holding it down (this is because auto-repeat is a driver/hardware feature). However, a Loop can be used to simulate auto-repeat. The following example sends 20 tab keystrokes:

Loop 20
    Send {Tab down}  ; Auto-repeat consists of consecutive down-events (with no up-events).
    Sleep 30  ; The number of milliseconds between keystrokes (or use SetKeyDelay).
Send {Tab up}  ; Release the key.

By default, Send will not automatically release a modifier key (Control, Shift, Alt, and Win) if that modifier key was "pressed down" by sending it. For example, Send a may behave similar to Send {Blind} {Ctrl up}a{Ctrl down} if the user is physically holding Ctrl , but Send {Ctrl Down} followed by Send a will produce Ctrl + A . DownTemp and DownR can be used to override this behavior. DownTemp and DownR have the same effect as Down except for the modifier keys (Control, Shift, Alt, and Win).

DownTemp tells subsequent sends that the key is not permanently down, and may be released whenever a keystroke calls for it. For example, Send {Control DownTemp} followed later by Send a would produce A , not Ctrl + A . Any use of Send may potentially release the modifier permanently, so DownTemp is not ideal for remapping modifier keys.

[v1.1.27+] : DownR (where "R" stands for remapping , which is its main use) tells subsequent sends that if the key is automatically released, it should be pressed down again when send is finished. For example, Send {Control DownR} followed later by Send a would produce A , not Ctrl + A , but will leave Ctrl in the pressed state for use with keyboard shortcuts. In other words, DownR has an effect similar to physically pressing the key.

If a character does not correspond to a virtual key on the current keyboard layout, it cannot be "pressed" or "released". For example, Send {µ up} has no effect on most layouts, and Send {µ down} is equivalent to Send µ .

General Remarks

Characters vs. keys: By default, characters are sent by first translating them to keystrokes. If this translation is not possible (that is, if the current keyboard layout does not contain a key or key combination which produces that character), the character is sent by one of following fallback methods:

Note: Characters sent using any of the above methods usually do not trigger keyboard shortcuts or hotkeys.

[v1.1.27+] : For characters in the range a-z or A-Z (plain ASCII letters), each character which does not exist in the current keyboard layout may be sent either as a character or as the corresponding virtual keycode (vk41-vk5A):

If the letter exists in the current keyboard layout, it is always sent as whichever keycode the layout associates with that letter (unless the Text mode is used, in which case the character is sent by other means). In other words, the section above is only relevant for non-Latin based layouts such as Russian.

Modifier State: When Send is required to change the state of the Win or Alt modifier keys (such as if the user was holding one of those keys), it may inject additional keystrokes ( Ctrl by default) to prevent the Start menu or window menu from appearing. For details, see #MenuMaskKey .

BlockInput Compared to SendInput/SendPlay: Although the BlockInput command can be used to prevent any keystrokes physically typed by the user from disrupting the flow of simulated keystrokes, it is often better to use SendInput or SendPlay so that keystrokes and mouse clicks become uninterruptible. This is because unlike BlockInput, SendInput/Play does not discard what the user types during the send; instead, such keystrokes are buffered and sent afterward.

When sending a large number of keystrokes, a continuation section can be used to improve readability and maintainability.

Since the operating system does not allow simulation of the Ctrl + Alt + Del combination, doing something like Send ^!{Delete} will have no effect.

Send may have no effect on Windows Vista or later if the active window is running with administrative privileges and the script is not. This is due to a security mechanism called User Interface Privilege Isolation.

SendInput [v1.0.43+]

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 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 , 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.

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.

When SendInput sends mouse clicks by means such as {Click} , and CoordMode Mouse, Relative is in effect (the default), 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 command will be wrong because they will still be relative to the old window rather than the new one.

SendPlay [v1.0.43+]

Warning: SendPlay may have no effect at all if UAC is enabled, even if the script is running as an administrator. For more information, refer to the FAQ .

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).

Both Win (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 Win 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 does not use the standard settings of SetKeyDelay and SetMouseDelay . Instead, it defaults to no delay at all, which can be changed as shown in the following examples:

SetKeyDelay, 0, 10, Play  ; Note that both 0 and -1 are the same in SendPlay mode.
SetMouseDelay, 10, Play

SendPlay is unable to turn on or off CapsLock , NumLock , or ScrollLock . 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). Also, SendPlay has other limitations described on the SendMode page .

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.

Related

SendMode , SetKeyDelay , SetStoreCapsLockMode , Escape sequences (e.g. `%) , ControlSend , BlockInput , Hotstrings , WinActivate

Examples

Types a two-line signature.

Send Sincerely,{enter}John Smith

Selects the File->Save menu (Alt+F followed by S).

Send !fs

Jumps to the end of the text then send four shift+left-arrow keystrokes.

Send {End}+{Left 4}

Sends a long series of raw characters via the fastest method.

SendInput {Raw}A long series of raw characters sent via the fastest method.

Holds down a key contained in a variable .

MyKey := "Shift"