使 Send 等同于 SendEvent 或 SendPlay, 而不是默认的(SendInput). 也使 Click, MouseClick, MouseClickDrag 和 MouseMove 使用指定的模式.
PrevMode := SendMode(Mode)
类型: 字符串
指定以下单词之一, 即可更改后续出现的 Send, SendRaw, Click, MouseClick, MouseClickDrag 和 MouseMove 的发送模式:
Event: 切换到传统的 SendEvent 模式.
Input: 默认模式. 切换到 SendInput 模式, 这是发送模拟按键操作和鼠标点击的最快且通常也是最可靠的方法.
Play: 切换到 SendPlay 模式, 此模式比 SendEvent 更快, 并且在其他模式无法正常工作的情况下, 例如某些游戏或具有特殊输入处理方式的应用程序中, 仍能发挥作用.
InputThenPlay: 与 Input 相同, 但当 Input 不可用时, 它并不会退回到 Event, 而是恢复为 Play. T这也会导致 SendInput 函数本身在 Input 不可用时, 会恢复到 Play.
类型: 字符串
函数返回以前的设置.
以下部分将介绍 AutoHotkey 使用的三种发送模拟按键操作和鼠标点击的操作方式: SendEvent, SendInput 和 SendPlay. 每种模式都有其各自的优点和局限性, 且应用程序的响应方式也会因输入的生成方式而有所不同. 了解这些差异有助于为特定脚本或目标应用程序选择最有效的模式
SendEvent 发送键击和鼠标点击的传统方法. 然而, 与其他发送模式相比, SendEvent 的速度较慢; 它永远无法达到 SendInput 或 SendPlay 的速度.
SendEvent 会遵循由 SetKeyDelay 和 SetMouseDelay 设置的延迟时间. 默认延迟时间为 10 毫秒.
当 SendInput 不可用时, 也会自动使用 SendEvent, 除非 InputThenPlay 生效.
SendEvent 函数可用于通过 SendEvent 模式显式地发送键击.
一般情况下, SendInput 是发送按键和鼠标点击的首选方法, 因为它的速度和可靠性都很高. 在大多数情况下, SendInput 几乎是瞬间完成的, 即使是发送长字符串时也是如此. 由于 SendInput 的速度如此之快, 它的可靠性也更高, 因为这样其他一些窗口更没有机会出乎意料地弹出并打断按键. 用户在 SendInput 过程中输入的任何东西都会被推迟到之后再进行, 从而进一步提高了可靠性.
与其他发送模式不同, 操作系统限制 SendInput 每次只能发送大约 5000 个字符(此限制可能因操作系统版本和性能设置而有所不同). 超过此限制的字符和事件不会被发送.
注意: SendInput 会忽略 SetKeyDelay 和 SetMouseDelay, 因为在这种发送模式中操作系统不支持延迟. 但是, 在后面描述的情况中, 当 SendInput 恢复到 SendEvent时, 它会使用 SetKeyDelay -1, 0(但如果 SendEvent 的按键延迟为 -1,-1 时, 则使用 -1,-1). 当 SendInput 因为 InputThenPlay 的原因恢复为 SendPlay 时, 它使用 SendPlay 的按键延迟.
如果脚本安装了底层键盘钩子, SendInput 会在执行之前自动卸载它, 并在执行后重新安装. 因此, SendInput 通常不能触发脚本自己的钩子热键或 InputHooks. 之所以暂时卸载钩子, 是因为它的存在会使 SendInput 的所有优势失效, 使其不如 SendPlay 和 SendEvent. 然而, 这只能对脚本自己的钩子执行, 如果检测到外部钩子, 则不会执行, 如下所述.
当 SendInput 使用像 {Click}, 这样的方式发送鼠标点击, 并且 CoordMode "Mouse", "Window" 或 CoordMode "Mouse", "Client" 有效时, 则每次点击都会相对于发送开始时的那个活动窗口. 因此, 如果 SendInput 有意地激活另一个窗口(通过类似 alt-tab 的方法), 那么这个命令中后续点击的坐标将变成错误的, 因为它们仍然相对于原来的活动窗口而不是新的.
SendInput 函数可用于通过 SendInput 模式显式地发送键击.
已知限制:
SendEvent "!{Left}" 或 SendInput "{Backspace}".过时的: 如果启用了用户账户控制(UAC), 即使脚本以管理员身份运行, SendPlay 无法正常工作. 有关详情, 请参阅 FAQ. 在 Windows 11 或较新的系统中, SendPlay 可能根本没有效果.
比起其他模式 SendPlay 最大的优势是具有在相当多种游戏中 "play back" 键击和鼠标点击能力. 例如, 某种特殊的游戏可能仅接受带有 SendPlay 选项的 热字串.
在三种发送模式中, SendPlay 是最不常用的, 因为它本身并不模拟键击和鼠标点击. 作为替代, 它制造一系列事件(消息) 直接流向活动窗口(类似于 ControlSend, 但在更低的层面). 因此 SendPlay 不会触发热键或热字串.
和 SendInput 一样, SendPlay 的键击与用户键入的按键互不干扰. 因此, 如果用户在 SendPlay 期间碰巧输入了一些东西, 这些键击会被推迟到之后.
A虽然 SendPlay 比 SendInput 要慢很多, 但它通常比传统的 SendEvent 模式要快(即使 KeyDelay 为 -1 时, 也是如此).
如果安装了键盘钩子, 则在 SendPlay 发送期间会自动屏蔽 Windows 键(LWin 和 RWin). 这样避免了在发送期间当用户无意按了 Windows 键时显示开始菜单. 与之相比, LWin 和 RWin 之外的其他按键不需要屏蔽, 因为操作系统会自动把它们延迟到 SendPlay 执行完后(通过缓冲).
如果 SetKeyDelay 和 SetMouseDelay 存在 Play 参数, 则 SendPlay 会遵循这些函数所设定的延迟时间. 与 SendEvent 不一样, SendPlay 默认值为 -1(完全不设置延迟).
SendPlay 无法打开或关闭 CapsLock, NumLock 或 ScrollLock 键. 同样, 它也无法改变 GetKeyState 所看到的键的状态, 除非按键被发送到脚本自己的一个窗口. 即使如此, 任何对左/右修饰键(例如 RControl) 的改变也只能通过它们的中性对应键(例如 Control) 来检测.
与 SendInput 和 SendEvent 不同, 用户可以通过按下 Ctrl+Alt+Del 或 Ctrl+Esc 来中断 SendPlay. 当这种情况发生时, 剩余的按键不会被发送, 但是脚本会继续执行, 就像 SendPlay 已经正常完成一样.
虽然 SendPlay 可以发送 LWin 和 RWin 事件, 但是它们会直接发送到活动窗口, 而不是执行它们的在操作系统中的原生功能. 要解决这个问题, 请使用 SendEvent. 例如, SendEvent "#r" 将显示开始菜单的运行对话框.
SendPlay 函数可用于通过 SendPlay 模式显式地发送键击.
已知限制:
SendEvent "{Click 6 52 Down}{Click 45 52 Up}".SendEvent "{WheelDown 5}".SendMode "Play" 时, 会影响所有的重映射按键并可能失去它们的某些功能. 有关详情, 请参阅 SendPlay 重映射限制.默认的模式为 Input.
由于 SendMode 也改变了 Click, MouseMove, MouseClick 和 MouseClickDrag 的模式, 所以您有机会为特殊的鼠标事件使用不同的模式. 实现这种操作最便捷的方法是使用 {Click}. 例如:
SendEvent "{Click 100 200}" ; SendEvent 使用更老更传统的点击方法.
如果在脚本启动中使用了 SendMode, 那么它还会影响键盘和鼠标重映射. 特别是, 如果你将 SendMode "Play" 与重新映射一起使用, 请参阅 SendPlay 的重映射限制.
内置变量 A_SendMode 包含当前的设置, 可以直接赋一个新值, 而无需调用 SendMode.
每个新运行的线程(如 热键, 自定义菜单项或定时子程序) 都会以此函数的默认设置开始. 这个默认设置可以通过在脚本启动中使用此函数来改变.
Send, SetKeyDelay, SetMouseDelay, Click, MouseClick, MouseClickDrag, MouseMove