【已截止】输入法插件开发日志

第十期
找到了不需要检测输入法也不需要用户主动选择的办法了，功能完成正式发布在群里了。
第九期
更换vvtts语音库之后，遇到了问题。获取输入法代码会导致每次打完字之后，就会读一遍输入法名称。
第八期
给NVDA的输入法切换回调打补丁，不用自己写dll就能拿到输入法名称了，这会奇怪问题没有了少加测试就可以发布了。
第七期
这一周继续修复智能检测问题，修复了几个内存泄漏问题之后稳定性好了一点，QQ和微信下面乱跳焦点的问题还是没有什么办法。
第六期
智能检测的方法虽然可以避免配置具体用的是什么输入法但是这几天测试的结果发现，严重影响NVDA的稳定性。甚至十几分钟崩溃一次。调试转储文件解决了一些问题。但是qq和微信下面还会出现奇怪的现象。如果下一个月截止日期之前还不能完全解决，只能暂时放弃智能检测这个功能了。
第五期
这一周主要是处理一些问题。
智能处理异常事件不能仅仅依靠状态机，需要获取其他信息比如当前输入法，虽然NVDA本身在更新事件里面提供了这个参数，但是Win8之后的系统里面的这个参数都是空的并不能拿到输入法，需要用其他方式处理。
切换输入法之后焦点没有跟上 导致打字读不了这个问题阴魂不散，又在Notepad++里面冒出来了。这回试了很多办法都不行，看来要好好研究这个过程，
第四期
这一周主要是处理新的输入法框架。
尝试了很多种方法， 包括自己写一个dll 仿照NVDA自己的方式接收事件，但是这样效果不好。
最后通过阅读NVDA源代码，找到了新输入法框架的解决方法。
第三期
这一期主要是处理Windows10预览版新添加的输入法。
这个输入法框架是基于之前添加的表情符号面板的，但是控件的具体结构略有不同 。
目前的输入法支持代码不支持这个框架。
首先尝试了类似的方式，但是用accevent工具发现
这个输入法没有发送In context 的 WinEvent 也没有 UIA的Element Selected事件
只有Out of context的OBJ_SELECTION事件，然而NVDA正好不接受这种事件。
这个事件本身的信息还不能，确定事件到底是不是输入法发出的。之前的输入法还有个 IME的windowClassName
要么更改NVDA主程序C++部分的代码 接受这种事件，要么自己写一个组件专门接受这种事件发给NVDA。

当然还可以向微软反馈，让这个新框架发送UIA事件，或者干脆实现 ITfUIElementSink这个接口，主动发送候选词列表。但是之前提过一次并没有什么效果，反馈内容链接
第二期
这一周主要是在写新的输入法事件修复方式
NVDA无条件信任输入法发过来的所有事件，问题是输入法发送的事件并不一定正确，这就是输入法朗读问题的来源。之前的方法是遇到一个问题，根据日志发现问题事件，做针对性检测然后处理。这种方法局限性很大，一次只能处理一种问题。问题多了会导致代码臃肿。新的修复方式采用状态机来智能检测事件，顺序不对的事件直接拒绝不响应。比如搜狗输入法会发送两次输入法结束的事件，内容也很奇怪有时候是第一个空的 有时候第一个是上一次输入的内容，还有时候，第二个是上一次输入的内容。新的方案会检测用户输入的字母，如果和结果对不上，而且是前一次内容的，就拒绝响应事件。微软输入法的读拼音问题也可以一样解决。
要是输入法不发送结果或者输入法发送的结果被QQ的安全模块一类的机制拦截了，那么插件还是没有办法获取到结果的。QQ窗口在NVDA启动之后打开可能会出现这种情况，Word有时候也会这样，重启一下qq或者word一般可以解决。

顺便了修复几个其他问题

搜狗输入法设置界面不朗读
这个设置界面非常奇怪，整个对话框只有一个对象。焦点移动到哪里，这个对象就是哪个控件的信息。发出的事件还全都是out of context的， NVDA不接受这种事件。 只能拦截tab和上下左右按键然后强制NVDA朗读一遍。

群里有人提出过一次ESC取消输入的时候出现的问题，虽然他的问题是插件造成的。日本版NVDA对ESC有特别处理，取消输入的时候，会朗读一条特别的消息比如“清除”来表示这次输入取消，不知道大家是否需要这个功能。

上一期提到的 焦点问题 有了个修复方案 但是会导致切换输入法之后的第一次输入存在延迟 再看看有没有更好的办法

第一期
上周输入法插件正式立项成功，到了发布具体进度的时候了。

这一周主要是一些前期工作。
1、修改了和Python3不兼容的语法，插件可以在NVDA测试版运行了。
2、按照NVDA的推荐做法，把设置保存到nvda.ini这个文件里面，这样可以在不同软件下，让输入法插件设置不同。
3、有一个已经修复的问题又冒了出来，就是切换输入法之后焦点没有跟上 导致打字读不了