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

Question

在Windows7和jre8上，我们看到了条形码扫描器和Java应用程序的异常奇怪的行为。这是一个大规模部署1000多台个人电脑和几个不同的条形码模式。我们扫描用9个字符表示字符串的条形码: H06AVKTI2

现在，“有时在某些安装上”，后面的一些字符出现在错误的顺序: H06AVKTI2 H06AVKI2T H06AVKTI2

• 当我们扫描记事本或outlook电子邮件时，我们从来没有看到过这个问题，只有在我们的Swing应用程序中。
• 它只发生在字符串的最后3-4个字符中，前4-5总是正确的.
• 它发生在大多数/所有条形码扫描仪模型和个人电脑，但在一些安装从来没有，在另一些经常-至今没有模式.
• 它没有100%的可重复性--只是在一些个人电脑上经常发生(超过50%的扫描是错误的)。
• 当我们在同一台PC上启动应用程序的两个实例时，我们看到它经常发生在一个实例中，但在另一个实例中却从未出现过。
• 它似乎与特定的扫描仪模型、条形码、用户或安装无关。
• 当我们键入这个字段，点击enter或任何其他键时，这个字段是集中的，没有网络流量-我们检查了Wireshark。

任何想法都是受欢迎的--我们绝望了;-)

Answer 1

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

现在，尽管当我们扫描条形码时，这些业务事务在上下文中是不可用的，但当应用程序接收到shift-t时，它似乎会中断几毫秒。当条形码扫描器扫描一个包含"T“的代码时，它会发送其中一个shift-t组合，软件只需要很短的时间就可以确定这个快捷方式没有任何用处。在这种情况下，扫描的字符最终会被交换。因此，这显然只发生在我们扫描一个包含我们配置的快捷键的字符的代码时.

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

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