微光互联 TX800-U 扫码器无法输出中文到光标的问题( 七 ) _生活百科

与之前版本相比，除了 printf 变为 my_printf，最大的变化是在结尾部分：使用 WM_CHAR 消息代替 WM_SETTEXT 。这样做是为了更好的模拟光标行为，毕竟不能假设用户光标一定位于 windows edit 控件上，有可能位于绘制界面框架 (Qt) 或描述界面框架 (Electron) 生成的 App 的控件上，这个消息可以实现字符被一个个输入编辑框的效果，兼容上述所有控件。
满怀期待的启动应用后，出现和 console 程序一样的行为——光标下没有任何输出，且不打印任何调试日志，遇到中文字符还会崩溃：

文章插图
看崩溃点没什么头绪，表现还不如 console 呢，这下把我整不会了，最终这个方案宣告失败。不过留着还是有意义的，万一有人基于它实现了光标输出呢…
结语本文尝试解决扫码器在遇到中文时不输出字符的问题，总体上解决了这个问题，优雅的解决方案因技术问题没有实现，不优雅的解决方案针对检测场的需求来说也够用了。
最早想的技术方案其实是不想动 demo 程序的，当时想通过在外面包一层 shell 脚本来解决，熟悉的读者知道我喜欢用这种方式解决一些问题，当时主要有两个原因导致想这样干：

家里的 windows 笔记本没装 VS，安装 VS2015 一来比较慢，二来拖累机器运行速度，不想装
demo 程序已经比较完整，只缺一个编码转换的工作，而用脚本调用 iconv 一行就能搞定，何必费力写 c++ 呢？

后面亲自试过后，发现有两个问题 shell 脚本无法绕开：

demo 的输出在经过 msys2 处理后，无法正确断行，导致无法从输出信息中提取扫码器读取的数据，对于这个问题

开始怀疑是管道重定向后 stdout 不再是行缓冲的，而在 shell 层面无法改变一个程序的 stdout 缓冲类型
后来修改 demo 源码，增加 setvbuf 调用 (参考《[apue] 标准 I/O 库那些事儿》中缓冲一节)，重新编译但不起作用
最终定性是 msys2 与 demo 之间的兼容性问题，不好搞，放弃

想要将数据复制到系统剪贴板，可以直接在 msys2 中使用 windows 的 clip 命令接收要放置的数据 (echo "${data}" | clip)，但是如果想将数据输出到光标，对不起办不到。这个必需用 c++ 进行系统开发 (后来也没走通，不过这是后话)

最终是将公司的 windows 本带回来专门搞这个事情，那个开发环境配置的比较全面，不用浪费时间再配了。说到这里，突然想到为何没有人搞在线的 VS 开发环境？linux 上的 gcc 这种环境一搜一大把，提交个文件或直接在 web 界面里写 c++ 代码，就能编译出可执行文件，而免费的 VS 线上开发环境却几乎没有！如果有人搞个 VS 的在线编译环境，肯定能火，哪怕编译一次收个十元二十元的，我估计也有人用。
上面说了一些解决过程中的探索，下面谈谈这个扫码器的问题，如果它能将编码转换功能集成在硬件里，通过配置来决定如何进行编码转换，那么这个场景就不需要二次开发 sdk 了！只要运行下 VguangConfig 并做一些勾选工作就可以了，如果再将常用的几种编码转换做成二维码配置放在文档中，直接扫对应的码就搞定了！后续给厂家反馈时，厂家表示可以考虑，其实就是增加一个 iconv.dll 的事儿，不难！
最后说一下系统升级导致扫码器不能用的问题，这就是典型的没做系统集成测试案例啊！新系统没有兼容老系统的一些隐性规则，导致下游出问题，其实完全可以让升级系统的软件厂商改进一下它这个二维码的生成方式，是用 utf8 还是 gb2312，搞成可配置的，操作人员通过配置来保持以前的编码方式不变，这个问题也能得到解决。