条形码扫描到Swing文本字段有时会交换字符

Question

我们在Windows 7和jre8上看到了条码扫描器和Java Swing应用程序的极端怪异行为。这是一个超过1000台PC和几种不同条码模型的大型部署。我们扫描代表9个字符的字符串的条形码：H06AVKTI2

现在＆＃34;有时在某些装置上＆＃34;一些后来的字符以错误的顺序出现： H06AVKTI2 H06AVKI2T H06AVKTI2

• 当我们扫描到记事本或Outlook电子邮件时，我们永远不会在我们的Swing应用程序中看到问题。
• 它只发生在字符串的3-4个最后一个字符中，前4-5个字符始终是正确的。
• 大多数/所有条形码扫描仪型号和PC都会发生这种情况，但是在某些安装上，从不在其他设备上 - 到目前为止没有模式......
• 它无法100％重现 - 只是在某些PC上经常发生（超过50％的扫描是错误的）
• 当我们在同一台PC上启动我们的应用程序的两个实例时，我们看到它经常在一个实例中发生但从未在另一个实例中发生。
• 它似乎与特定扫描仪型号，条形码，用户或安装无关
• 当我们输入此字段时，没有网络流量，当此字段聚焦时按Enter键或任何其他键 - 我们使用Wireshark进行检查。

欢迎任何想法 - 我们绝望; - ）

Answer 1

我们最终解决了这个问题。事实证明，这个Java Swing应用程序允许配置可用于在特定条件下执行某些业务任务的键盘快捷键。有人将全局配置shift-t和其他一些shift-_作为业务交易的快捷方式。

现在，即使我们扫描条形码时上下文中没有这些业务交易，但只要收到shift-t，应用程序似乎就会中断几毫秒。当条形码扫描器扫描包含＆＃34; T＆＃34;的代码时，它会发送这些shift-t组合中的一种，软件需要很短的时间才能确定，这与此无关。捷径。在这些情况下，扫描的字符最终会被交换。因此，当我们扫描包含我们为...编写快捷方式的一个字符的代码时，这显然只会发生。

解决方案是将配置的快捷方式更改为ctrl-t而不是shift-t。

根本原因可能是该应用程序的框架开发人员实现这些全局快捷方式的方式，但这尚未得到验证。