扫描到 Swing 文本字段中的条形码有时会交换字符
Barcode scanning into Swing textfield sometimes swaps characters
我们在 Windows 7 和 jre8 上看到条形码扫描器和 Java Swing 应用程序的异常行为。这是 1000 多台 PC 和几种不同条码模型的大型部署。我们扫描代表具有 9 个字符的字符串的条形码:H06AVKTI2
现在"sometimes on some installations"后面的一些字符出现顺序错误:
H06AVKTI2
H06AVKI2T
H06AVKTI2
- 当我们扫描记事本或 outlook 电子邮件时,我们从来没有发现问题,只是在我们的 Swing 应用程序中。
- 它只发生在字符串的最后 3-4 个字符上,前 4-5 个字符总是正确的。
- 它发生在 most/all 条形码扫描器型号和 PC 上,但在某些安装上从未安装过,在其他安装上经常出现 - 到目前为止没有模式...
- 它在任何地方都无法 100% 重现 - 只是在某些 PC 上它经常发生(超过 50% 的扫描是错误的)
- 当我们在同一台 PC 上启动应用程序的两个实例时,我们发现它经常在一个实例中发生,但在另一个实例中却从未发生过。
- 似乎与具体的扫描器型号、条码、用户或安装无关
- 当我们在此字段中键入内容时没有网络流量,当此字段获得焦点时按回车键或任何其他键 - 我们已使用 Wireshark 检查。
欢迎任何想法 - 我们很绝望 ;-)
我们最终解决了这个问题。事实证明,这个 Java Swing 应用程序允许配置可用于在特定条件下执行特定业务任务的键盘快捷键。有人全局配置 shift-t
和其他一些 shift-_
作为业务交易的快捷方式。
现在,即使我们扫描条形码时这些业务交易在上下文中不可用,应用程序似乎也会在收到 shift-t
时中断几毫秒。当条形码扫描仪扫描包含 "T" 的代码时,它会发送这些 shift-t
组合之一,并且软件会花费很短的时间来确定此快捷方式无需执行任何操作。在这些情况下,扫描的字符最终会被交换。所以这显然只发生在我们扫描包含我们为其配置快捷方式的字符之一的代码时...
解决方案是将配置的快捷方式更改为 ctrl-t
而不是 shift-t
。
根本原因可能是应用程序的框架开发人员实现这些全局快捷方式的方式,但这尚未得到验证。
我们在 Windows 7 和 jre8 上看到条形码扫描器和 Java Swing 应用程序的异常行为。这是 1000 多台 PC 和几种不同条码模型的大型部署。我们扫描代表具有 9 个字符的字符串的条形码:H06AVKTI2
现在"sometimes on some installations"后面的一些字符出现顺序错误: H06AVKTI2 H06AVKI2T H06AVKTI2
- 当我们扫描记事本或 outlook 电子邮件时,我们从来没有发现问题,只是在我们的 Swing 应用程序中。
- 它只发生在字符串的最后 3-4 个字符上,前 4-5 个字符总是正确的。
- 它发生在 most/all 条形码扫描器型号和 PC 上,但在某些安装上从未安装过,在其他安装上经常出现 - 到目前为止没有模式...
- 它在任何地方都无法 100% 重现 - 只是在某些 PC 上它经常发生(超过 50% 的扫描是错误的)
- 当我们在同一台 PC 上启动应用程序的两个实例时,我们发现它经常在一个实例中发生,但在另一个实例中却从未发生过。
- 似乎与具体的扫描器型号、条码、用户或安装无关
- 当我们在此字段中键入内容时没有网络流量,当此字段获得焦点时按回车键或任何其他键 - 我们已使用 Wireshark 检查。
欢迎任何想法 - 我们很绝望 ;-)
我们最终解决了这个问题。事实证明,这个 Java Swing 应用程序允许配置可用于在特定条件下执行特定业务任务的键盘快捷键。有人全局配置 shift-t
和其他一些 shift-_
作为业务交易的快捷方式。
现在,即使我们扫描条形码时这些业务交易在上下文中不可用,应用程序似乎也会在收到 shift-t
时中断几毫秒。当条形码扫描仪扫描包含 "T" 的代码时,它会发送这些 shift-t
组合之一,并且软件会花费很短的时间来确定此快捷方式无需执行任何操作。在这些情况下,扫描的字符最终会被交换。所以这显然只发生在我们扫描包含我们为其配置快捷方式的字符之一的代码时...
解决方案是将配置的快捷方式更改为 ctrl-t
而不是 shift-t
。
根本原因可能是应用程序的框架开发人员实现这些全局快捷方式的方式,但这尚未得到验证。