.NET 6 WinForm中SendKeys.SendWait向文本框发送PgUp/PgDn失效问题

这个问题的核心原因有两点：

• 物理键盘按PgUp时，系统会自动给生成的按键消息带上extended-key标记，TextBox原生逻辑只有识别到这个标记，才会触发翻页导航逻辑。从非UI线程调用SendKeys.SendWait("{PgUp}")发送的按键消息不会携带这个标记，TextBox会将其判定为普通输入按键，最终在光标位置插入换行——你看到的文本末尾新增空行，就是因为当时焦点在文本末尾，未被识别为导航键的消息被错误映射为回车输入。
• ^a（全选）能正常生效，是因为Ctrl类组合快捷键的处理逻辑不依赖扩展键标记，只要收到对应Ctrl+A的按键序列就能触发，所以不会出现识别异常。
• 你调用SendKeys.Send抛出的异常是设计使然：该方法依赖当前线程的消息循环，非UI线程本身没有消息泵，自然无法执行，官方文档也明确说明跨线程场景必须使用SendWait。

方案1：直接调用控件原生逻辑（推荐，稳定性最高） #

完全放弃模拟键盘输入的思路，直接给TextBox发送原生滚动消息，从根源规避跨线程、焦点、按键标记的所有问题：

• 所有涉及控件操作的逻辑全部封送到UI线程执行，符合WinForm的线程访问规则
• 直接发送Windows滚动消息给文本框，效果和手动按PgUp完全一致
  示例代码：

/// <summary>
/// 文本框向上翻页，支持从任意线程调用
/// </summary>
/// <param name="targetTextBox">目标文本框实例</param>
internal static void HelperPageUp(TextBox targetTextBox)
{
    // 跨线程调用时自动封送到UI线程
    if (targetTextBox.InvokeRequired)
    {
        targetTextBox.Invoke(new Action(() => HelperPageUp(targetTextBox)));
        return;
    }
    // 发送原生垂直滚动消息
    const int WM_VSCROLL = 0x115;
    const int SB_PAGEUP = 2;
    const int SB_PAGEDOWN = 3;
    Message scrollMsg = Message.Create(targetTextBox.Handle, WM_VSCROLL, (IntPtr)SB_PAGEUP, IntPtr.Zero);
    targetTextBox.WndProc(ref scrollMsg);
    
    // 需要向下翻页时，将上面的SB_PAGEUP替换为SB_PAGEDOWN即可
}

这个方案不依赖焦点状态、不依赖全局键盘锁，哪怕语音触发时文本框暂时没有获得焦点，也能正常执行翻页，不会出现按键串扰、输入错乱的问题。

方案2：修正SendKeys调用方式（备选） #

如果必须保留SendKeys的实现逻辑，需要做两个修正：

• 所有SendKeys调用全部封送到UI线程执行，不要在语音识别后台线程直接调用
• 发送按键前先确保目标文本框获得焦点
  首先在程序入口Program.cs中，在Application.Run之前添加SendKeys的兼容配置：

SendKeys.UseBeepOnFailure = false;

然后修改按键发送方法：

internal static void HelperPageUp(TextBox targetTextBox)
{
    if (targetTextBox.InvokeRequired)
    {
        targetTextBox.Invoke(new Action(() => HelperPageUp(targetTextBox)));
        return;
    }
    targetTextBox.Focus();
    SendKeys.SendWait("{PGUP}");
}

注意：该方案依然会受全局键盘状态、前台窗口切换的影响，稳定性弱于方案1。

不推荐方案：自定义KeyUp事件处理 #

你提到的新增KeyUp事件自行实现翻页逻辑的思路属于重复实现TextBox内置功能，需要自行计算滚动行偏移、同步光标位置，很容易出现滚动距离不准、光标位置错乱的问题，没有特殊自定义需求不建议采用。

你之前推测的「PgUp按键需要控件自定义处理」并不准确：TextBox本身已经内置了完整的PgUp/PgDn翻页逻辑，只是非UI线程SendKeys发送的消息缺少必要的扩展键标记，才导致控件没有触发内置导航逻辑，将其误判为普通输入。

内容的提问来源于stack exchange，提问作者Kevin