Winbiff メール内容の読み上げの不具合
nishimoto nishimoto 2014.1jp の修正版 (2014.1jp2) をリリースするかも知れないので、jp2014.1 ブランチで以下の作業を行いました。
[jp2014.1 09ea070] work around issue with Winbiff (nvdajp ti33555) 2 files changed, 8 insertions(+), 2 deletions(-)
検証したところ Winbiff と Visual Basic 6 テストアプリケーションの違いは editAPIVersion なので、editAPIVersion が 0 で Unicode ウィンドウでない場合にだけ、本件の不具合回避を実行するように変更しました。
不具合修正をカバーできないケースが発生するかも知れませんが、検証対象のアプリがいまのところ2種類しかないので、副作用を最小限にすることを狙っています。
また NVDA の設定ファイルに下記のオプションを追加して workAroundEncoding を false にすると、editAPIVersion に関わらず チケット #33260 の修正を無効にできるようにしました。
[language] workAroundEncoding = boolean(default=true)
修正版をリリースしなおすか、2014.2jp までこの修正を見送るか、ご意見をいただければ幸いです。
nishimoto 2014.1jp に本件に関する修正だけを加えたテスト版 jpbeta140322 を作りました。
https://dl.dropboxusercontent.com/u/62564469/nvda_jpbeta140322.exe
電子署名はしていません。
私の環境では Winbiff は正常に動くようになりましたが、特に日本で開発された複数行エディットを使うアプリケーションでのテスト報告を歓迎します。
nishimoto チケット #33260 の修正を有効にするかしないか（EM_GETSELなどがバイト単位と文字数単位のどちらで動作しているか）の判定を単純に行うことが難しそうです。
マイクロソフトの情報：
WindowsXP で Manifest ファイルを使用したアプリケーションで Common Control バージョン 6 を使用した場合、Edit コントロールへの EM_LIMITTEXT メッセージによる入力量制限を設定する際の単位が、バイト数単位ではなく文字数単位に変更されました。この動作は仕様です。
http://support.microsoft.com/kb/418099/ja
単純に上記の条件を判定すればいいのかと思ったのですが
という状況なので、この問題を正しく処理するにはもうすこし情報収集する必要があります。
方針案：
本家が技術的に困難としたのはスレッドのロケールを RPC で取得する必要がある、という話で、ここで書いているコモンコントロールのバージョンと環境に依存する話はまた別件です。
日本語チーム以上に本家から手を出しにくい（情報収集がしにくい）バグではないかとも思われます。
nishimoto jpbeta140322 で Winbiff の不具合が解決したというご報告をいただきました。
ただ、editAPIVersion による判定（実質的にウィンドウクラスの種類による振り分け）ではきちんと問題は解決できないようです。
この「ANSI 版エディットボックスの Unicode 動作」について、後述のいくつかの記事のように、アプリ開発者はこの環境依存の問題を、実際に CreateWindowA を実行して EM_SETSEL, EM_GETSEL の結果を見て判断する、といった実装をしているようです。 この方法は NVDA の実装方法としては参考になりません。
ANSI 版エディットボックスが Unicode 動作していれば IsWindowUnicode で判断できるという情報もあるので Winbiff について IsWindowUnicode を正しく取得できていない（エディットボックスそのもののハンドルを正しく使えていない）のかも知れません。
「ANSI 版エディットボックスの Unicode 動作」を判断する正しい方法がないとすると、
といったアプローチが考えられます。
最終的には EM_GETSEL などを使わないで edit.py を実装するように本家の実装をやり直す必要があるかも知れません。
以下、「ビジュアルスタイル ANSI 版エディットボックスの Unicode 動作」に関する記事：
nishimoto ダウンロードページ 2014.1jp のリリースノートに、本件を既知の不具合として記載しました。
nishimoto 2014.1jp を再修正したテスト版 jpbeta140324 を作りました。
https://dl.dropboxusercontent.com/u/62564469/nvda_jpbeta140324.exe
「日本語設定」に「改行位置の不具合対策」というチェックボックスを追加しました。
デフォルトでは有効で、ANSI 版エディットボックスで本家版の不具合を回避します。
ただし Winbiff のように「ANSI 版エディットボックスの Unicode 動作」では、不必要な処理を避けるためにチェックを外していただくことになります。
前述の記事によると実行環境の Windows のバージョンにも依存する可能性があるらしく、この対策の必要・不必要の判定は困難そうなので、このような実装が現状では安全と考えました。
nishimoto nishimoto nishimoto 本作業は完了と判断して、クローズします。
Screen Reader NVDA Japanese
Fork
NVDA 2014.1jp にバージョンアップしたら Winbiff の読み上げに不具合が発生したというご報告をいただきました。
私の環境 Windows 8.1 64ビットで現在ダウンロード可能な Winbiff without EditX Version 2.51 PL2 を使ってみました。
確かに表示されている改行位置と読み上げの改行位置が一致しない不具合が出ています。
2013.3jp に戻すと解決するというご指摘をいただいているので、下記の変更の影響という可能性もあります。
チケット #33260 Visual Basic 6 アプリケーションの複数行エディットで改行位置が正しく認識されない
Winbiff そのものはすでにサポートが終了したアプリケーションなのですが、他のアプリケーションにも不具合が出ているかも知れないので、引き続き検討させてください。