▼ なすこじさん
> 内容からすると目視チェックだけでも良いかなという感じですが、どうなんでしょうか？

レビュー作業ありがとうございます。

少なくともtrunkの場合はすべて動作チェックすべきなのかもしれません。
branchはある程度緩くても良い気はします。

なんにしろ今回は量が多いです。
ぜんぶ合わせるとメッセージボックスだけで100箇所以上変更がある気がします。


特に論拠は無いですが、方針を定めようと思います。
リファクタリングパッチに関しては、
・ソースコードの変更箇所は全部目を通す
・その過程で「ん？」と思ったところは実行して動作を確かめる
・「ん？」と思わなかった所でも、サンプリングとして変更量の1割程度は動作確認をする
という感じでどうでしょうか。


論拠が無い上に、解釈によってどうとでも取れる表現も見受けられますが(汗)、
何も無いよりはレビューの助けになるかと。

とりあえずtrunkへの合流を最優先事項とさせてください。
問題があったらあったでその後に軌道修正バグ修正すれば良いということで。

▼ なすこじさん
> #1880351について、ソースコードの確認と一部の動作を確認しました。
>
> 下記の箇所に %ls となっている箇所がありますが、%ts にすべきでしょうか？
> ANSI版が可能となった時に問題となるのかなと思いました。

レビュー作業ありがとうございます。

今のところはUNICODE動作さえ保障されれば良いので、
「%ts」対応は保留で良いかな、と思っています。
…というと随分軽い体制かと思われるかもしれませんが、重い理由として下記を考えています。

1つの理由としては、
数が多く、非常に時間がかかること。
(しらみつぶしにソースの整合性をチェックし修正することも、その動作チェックをすることも)

もう1つの理由としては、
TCHAR解決のための「%ts」の策自体が (個人的に) 最良では無いと思っていること。
trunkへ統合された後にでも、皆様との議論を交えて、
この策のままで行くか、別の策で行くかを検討するフェーズがあると思います。
「思います」というか、そういうフェーズを提供することを現実的に考えています。
つまり、今の時点で「%ts」を細かくチェックした場合、その労力は水の泡となる可能性があります。


ちなみに、自分は気が向いた所をちょこちょこ直していますが。。それはただの趣味です（落ち葉拾いのようなものです）。
(「気が付いた所」では無いところがミソ。気が付いてもあえて無視している所が多数です)


渡している型はTCHARのくせにprintfフォーマット指定は「%ls」かよっ、
という、ソースコード文脈的に「もやもやした」感じは残りますが、
branchプロジェクトの方針としては「基本放置。修正は禁止しない」で行きたいと思います。

よろしくお願い致します。

▼ なすこじさん
> #1880352について、ソースコードの確認と一部の動作を確認しました。
>
> というわけで「リファクタリング：メッセージとビープの整理」3部作はコミットOKと思います。
> > PatchUnicode#1880350
> > PatchUnicode#1880351
> > PatchUnicode#1880352

さっそくのＯＫサインありがとうございます。非常に助かります。
上の3パッチをまとめてコミットしました。(rev1221)


> >>unicode:145 の%lsの件了解しました。
> %tsに直している箇所とそのままの箇所があったので修正もれかと勘違いしたのですが、そういえばその様な議論を見た様な気がします (^^;

勘違いして当然です。orz
重要な情報はちゃんと整理して皆の目の付くところに
置かなきゃダメっすね。。週末にでも整理作業をしようと思います。