Speeeeed Ver1.51
置換えリストエディタにバグがあったので修正です。
長い文字列を登録しても保存時に256バイト以降が勝手に削除されてました。
あと、ちょっとしたGUIのバグ修正も。
どうやらリストコントロールに問題がある感じ。
リストコントロールにLVM_GETITEMTEXTを投げ戻る値は通常ならLVITEM構造体のcchTextMaxで指定したサイズより文字列が大きい場合は、cchTextMax-1だけコピーし最後に\0を付加し戻り値としてcchTextMax-1が返りますが、2バイト文字が含まれる場合cchTextMaxコピーしcchTextMaxを返します。
そのため、MFCの実装でもし戻り値が用意したバッファ-1のサイズならサイズを確保しなおし再取得する訳ですが、一つ大きい値が返ってくるのでそこで処理が終わってしまい後ろが切れてしまいます。
# ただしUnicode版(W版)では発生しないと思われます。
この問題結構影響大きいですね。
Clipyも同様に後ろが切れるバグ抱えてます。
とは言えClipyにおいてNT系はW版のAPI使ってるので9x系でしか起きない問題ですが。
他に最近アセンブラで色々遊んでるので文字列検索のルーチンをアセンブラ化して更に高速化させようかと思ったけどVC++の最適化ってかなり凄いので下手に弄ったら余計遅くなるような気もしたのでこれはヤメ。
サイズの最適化なら上手くできてるか簡単に把握できますが速度の最適化は環境によっても変わるから確かめにくいですし。
では以下更新点の詳細です。
長い文字列を登録しても保存時に256バイト以降が勝手に削除されてました。
あと、ちょっとしたGUIのバグ修正も。
どうやらリストコントロールに問題がある感じ。
リストコントロールにLVM_GETITEMTEXTを投げ戻る値は通常ならLVITEM構造体のcchTextMaxで指定したサイズより文字列が大きい場合は、cchTextMax-1だけコピーし最後に\0を付加し戻り値としてcchTextMax-1が返りますが、2バイト文字が含まれる場合cchTextMaxコピーしcchTextMaxを返します。
そのため、MFCの実装でもし戻り値が用意したバッファ-1のサイズならサイズを確保しなおし再取得する訳ですが、一つ大きい値が返ってくるのでそこで処理が終わってしまい後ろが切れてしまいます。
# ただしUnicode版(W版)では発生しないと思われます。
この問題結構影響大きいですね。
Clipyも同様に後ろが切れるバグ抱えてます。
とは言えClipyにおいてNT系はW版のAPI使ってるので9x系でしか起きない問題ですが。
他に最近アセンブラで色々遊んでるので文字列検索のルーチンをアセンブラ化して更に高速化させようかと思ったけどVC++の最適化ってかなり凄いので下手に弄ったら余計遅くなるような気もしたのでこれはヤメ。
サイズの最適化なら上手くできてるか簡単に把握できますが速度の最適化は環境によっても変わるから確かめにくいですし。
では以下更新点の詳細です。
・長い置換え文字列を保存時、きちんと保存されないバグを修正。
・置換えパターンの追加ダイアログが有効にならない場合があるバグを修正。
・置換えパターンの追加ダイアログが有効にならない場合があるバグを修正。