按住CTRL键时PostMessage发送WM_KEYDOWN消息异常处理方法

你遇到的发送异常并非系统自动为消息附加CTRL组合键，核心逻辑如下：

• 包括记事本原生Edit控件在内的标准Windows控件，处理WM_KEYDOWN/WM_KEYUP这类原始键盘消息时，不会仅依据消息携带的wParam、lParam参数判断按键组合，会主动调用GetKeyState接口查询CTRL、SHIFT、ALT等修饰键的全局实时按下状态。
• 你运行代码时物理按住CTRL键，系统维护的全局键盘状态中CTRL即为按下状态，无论你怎么构造WM_KEYDOWN的lParam参数，控件查询到CTRL处于按下状态，就会把普通按键识别为Ctrl组合键，触发对应快捷键逻辑（比如Ctrl+a全选、Ctrl+z撤销），不会执行普通字符输入逻辑。
• PostMessage属于异步消息投递函数，投递的键盘消息不携带独立的键盘上下文，无法覆盖系统全局维护的按键状态。

根据实际使用场景选择对应方案即可：

• 文本输入场景直接投递WM_CHAR消息
  若需求是向编辑类控件输入文本，无需发送原始WM_KEYDOWN/WM_KEYUP消息，直接投递WM_CHAR消息即可。控件处理WM_CHAR时直接接收转换完成的字符，不会额外查询全局修饰键状态，完全不受发送端当前按键状态影响。
  对应你提供的示例代码，把循环内的按键发送逻辑替换为如下内容，就算运行时按住CTRL，记事本也会正常输入a-z：

  for (char ch = 'a'; ch <= 'z'; ch++) // 向记事本输出a-z
  {
      // lParam按普通字符输入的常规参数填充即可
      PostMessage(hEdit, WM_CHAR, ch, 0x00000001);
      Sleep(200);
  }
  

• 必须发送原始键盘消息的特殊场景
  如果目标窗口不响应WM_CHAR，必须处理原始键盘消息，可以通过低层键盘钩子，在目标窗口处理你投递的消息的时间窗口内，临时修改GetKeyState返回的修饰键状态，让控件认为CTRL未按下。该方案实现复杂度较高，仅适用于无替代方案的特殊场景。
• 无后台发送需求时优先使用SendInput
  如果你不需要在窗口处于后台状态时发送按键，优先使用SendInput接口模拟输入。该接口会构造完整的独立输入上下文，只要构造输入结构时不加入CTRL等修饰键的按下事件，就不会受物理按键状态干扰，兼容性远高于PostMessage投递键盘消息的方案。

补充：你原代码中构造lParam的逻辑本身存在参数填充不完整的问题，但这不是导致CTRL按键干扰发送效果的核心原因。

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