如何在Richedit只读属性状态下实现ID号/条码扫描录入

绝大多数消费级/工业级扫码枪默认工作在键盘模拟模式，本质是向当前获得焦点的控件高速发送模拟按键消息，输入完成后自动追加回车符，单字符输入间隔通常在10~20ms区间，远低于普通人手动打字的按键间隔（普遍高于80ms），这是我们区分手动输入和扫码输入的核心判断依据，不需要依赖扫码枪的专用SDK就能实现需求。

方案1：临时切换只读状态写入（兼容性最高，推荐优先用） #

这个方案不用改你原有的只读属性设置逻辑，开发量最小，不会和Richedit本身的消息机制冲突：

• 维护一个全局的按键缓存队列和时间戳记录，每次Richedit收到键盘按键消息时，先记录当前按键值和按键时间。
• 做规则判定：如果连续收到的按键间隔都小于50ms，且最后收到扫码枪默认追加的回车符，就把缓存队列里的字符拼接成完整的扫码串，判定为有效扫码输入。
• 判定为有效输入后，先执行RichEdit.ReadOnly = false，将扫码串按业务需要插入到控件中（比如追加到文本末尾、替换选中内容），插入完成立刻执行RichEdit.ReadOnly = true恢复只读状态。
• 整个属性切换过程在内存中毫秒级完成，用户完全感知不到可编辑窗口，普通手动输入因为达不到连续高速按键的判定条件，永远不会触发只读状态解除，自然无法手动输入内容。

如果你的场景里可以把扫码枪配置为串口/HID原始数据模式，不需要模拟键盘，那连按键识别逻辑都不用写：直接从设备通信端口读到扫码数据后，按上面的逻辑临时取消只读、写入内容、恢复只读即可，稳定性更高。

方案2：消息拦截定向放行（无需切换只读属性） #

如果你不想反复修改ReadOnly属性，可以直接子类化Richedit控件，重写它的窗口消息处理过程：

• 正常拦截所有WM_KEYDOWN、WM_CHAR这类输入类消息，直接返回0不让控件默认处理，实现和设置ReadOnly一致的无法手动输入效果。注意不要拦截WM_COPY、右键菜单、滚动这类只读状态下允许的操作消息。
• 当检测到符合规则的连续高速扫码按键输入时，不对这部分WM_CHAR消息做拦截，直接传给Richedit的默认消息处理流程，让控件正常接收扫码输入的字符即可。

• 按键间隔判定阈值不要设得太低，建议留冗余设为50ms，部分老旧扫码枪的模拟按键速度偏慢，阈值设到20ms以下容易出现识别丢内容的问题。
• 最好给扫码串加一层格式校验，比如固定长度、符合ID/条码的字符规则，避免用户故意快速敲击键盘误触发扫码写入逻辑。
• 如果用方案1，记得写入内容后手动重置滚动位置到最新插入内容的位置，避免内容超出可视区域时用户看不到新录入的扫码信息。

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