久しぶりにWindowsの仕事が入る。以前書いた認識結果出力モジュールの更にサブモジュールに関するドキュメントを書くというもの。本当はドキュメントをもっと早い時期に作っておかなくちゃいけないし、そもそも内部仕様書がないっていうのが今まで怠慢していた証拠なんだけど、まあ前任者が内部仕様に関してはほとんどドキュメントを残していなかったというのを言い訳にしておこう。(^_^;
ドキュメントを書いていると、その時にはその時で精一杯で思いつかなかったけど、今読み直してみると、あああそこはああ書けばよかったなぁとか、こんな風にまとめれば読みやすくなるだろうなぁというところがやたらと目につく。もっともその時は、もっとぐちゃぐちゃの状態をなんとか私でも理解可能なレベルにまで持っていくことを第一目標にしていたというのもあってのこと。本当はぐちゃぐちゃ状態をまとめた段階で、さらにまとめることが必要だったんだけど、あの時はその時間がなかったし、まさかあのモジュールがあんなに早く私の手元から離れるとは思わなかったので仕方がないか。(^_^;2時間ちょっとほどで、大体のドキュメント作成はカタが着いたがちょっとした気分転換になった。
ドキュメント作成が終って相変わらず、Mac版。そういえばファイル関連のU/Iで残っていたものがあるのを思いつく。これこそ典型的なNavigationサービスが使えるパターンだなと思ったのだが、実際にコーディングしてみるとポップアップメニューに「うんたら書類」というのが出てくる。本当は「ほにゃらら」とポップアップメニューに出したいのに。openリソースとかkindリソースとかをいじればいいらしいと分かったんだが、こっちがどういじっても思ったようにならない。う〜ん、なんでうまくいかないかなぁ。結局悪戦苦闘したあげく、この前までやったようにカスタムリソースを使ったりしてなんとか解決。解決はしたもののちょっと納得行かないので後でSさんに相談してみよう。
「カスタムポップアップに何が選ばれたのか分からない」とCodeWarrior MLに土曜日に聞いてみたら、NavCBRec構造体から3階層くらい降りたところにデータが入っているらしい。確かにそのメンバーはparamsだな。それを信じてコーディングしてみたら、完璧にうまくいった。
Navigationサービスを使った、画像ファイルのロードはこれで済んだのだが、MacOS7.xなどのNavigationサービスを使えない場合のコーディングでまた一苦労。以前、そのコア部分だけすごく苦労して書いてあったので、何とか今日のうちにコーディングが済んだ。ただ、Navigationサービスを使わない部分ってサンプルプログラムをそのまんま使って中身を理解していないんで、「ここを直せ」とか言われてもすぐには直せないんだな、これが。ま、これはとりあえず先送りしてもいいだろう。(^_^;
頭が痛いのが、画像ファイルのロード、セーブ、認識結果のセーブ。これそれぞれに対して、Navigationサービスを使える場合と、使えないバージョンとで2種類用意しなくちゃいけない。で、この3つが3つ、全部カスタムpopupとかカスタムコントロールとかを用意しなくちゃいけない仕様上の要求があって一筋縄じゃ行かない。半日くらいで何とかなると思った私は甘かったです。たっぷり一日かかりました。(;_;)もっとも、画像ファイルのロード、セーブはほとんど一日費やしたけど、認識結果のセーブについてはパターンが分かってきたので、20分くらいでコーディングできた。Navigationサービスを利用する場合のプログラムのパターンもかなり分かってきたので、この関連に関してはこれからは相当早く進むだろう…。もっとも今回のプロジェクトではNavigationサービスを使ったコーディングはもうないんだけどさ。(^_^;
何とかプログレスダイアログ関連のdebugが終る。もっとも最初に書いたコードはがあまりにも遅すぎたので、一部全面書き直しになったんだけど、書き直したのは100行程度だし、画像処理とかはあまりやったことがない部分なので仕方ないか。書き直したら、速度はそこそこ満足の行く程度になったので、やれやれ。
なんとかプログレスダイアログ関連が終ったので、ファイルの入出力ダイアログ。基本的にはNavigationサービスを使う。色々やってみたらカスタムポップアップじゃないと仕様的に駄目だと分かる。で、Appleから出ているドキュメントを読むと、NavigationサービスCallback関数に渡されるNavCBRec構造体のparamフィールドにどんなメニューが選択されているか入っているという。でもCBRecにはparamフィールドなんてのはないし、他のフィールドを見てもそれっぽい値が入っていない。う〜む、色々調べたけど、今日はこれでギブアップ。
前日のミーティングでIさんが抜けることが確定したので、Iさんの担当の部分で残ったプログレスダイアログの表示のコーディングを行う。Windows版はSendMessage()を使ってプログレスバーの更新を行っていたので、そこを全部Callback関数に書き直して、さらにそのCallback関数の本体を書いて、関連したモジュールでSendMessage()を使っている所も全部Callback関数への呼び出しに変えて、Callback関数の本体も一緒に書いて…、とやっていったら、一日じゃとてもdebugまで終らなかった。これって半日で書けるつもりだったんだけどなぁ。(;_;)
まだ結構動作がおかしい所があるが、何とかASCII文字を挿入したり、削除したりする部分の主要なところはうまく動いているようだ。IMを経由した文字入力が出来ないんで、日本語は入力できないんだけど、IM経由で未確定文字などの表示と文字列の取り込みが出来て(といってもこれはこれで大変な気がするんだけど(^_^;)、境界条件でおきるバグを駆逐できれば(こいつは再現性と原因となる部分がはっきりしているので、そんなに大変じゃなさそう)、1つ大きな山を超えたことになる。
私とNさんとIさんでミーティングをすることになっていたので、一通り動いている部分だけでもどれだけ動いているか試してみると、Iさんの書いていた画像編集のモジュールの動きが異常に鈍い。ロジックを聞いてみると「なるほど遅くなるよな」という感じだった。これはかなり手を入れないといけないかも知れないな、という予感がする。
で、私とNさんとIさんでミーティング。残作業を全部リストアップしていったら、まだ終っていない作業のほうが多い事が分かった。項目1つ1つを見ていくと今まで解決していった問題に比べれば、移植じゃなくて全部新規コーディングにすることを決意しているだけ、まだどれだけ時間がかかるか読みやすいんだけど、正直言って項目数が多すぎる(実際にはリリースまでに実装しなくちゃいけない項目はもっとあるだろう)。もう1つ、その項目1つ1つで、まだ使ったことがないあのAPIセット(Windowsで言えばOLEとかRASとかのまとめ方でのAPIセット)の使い方を憶えなきゃいけないなぁと思うともっと頭が痛い…。正直、かなりげんなりした。
スケジュールの都合上、IさんがMS-Windowsバージョンの方に回ることになった。Iさんが抜けるのはMac版の開発だけを考えれば痛いけど、Win/Macの両方を考えれば致し方ない。代わりといってはなんだけど、最近制定を終えたMacの師匠Sさんが入ってくる予感。これは心強い。神様、仏様、Sさま。どうか私をお救い下さいませ。(祈り)
BTRONの新しいバージョン、「超漢字」を購入。インストールしてみたら、インストールしたマシンのシリアルマウスをうまく認識しなかった。がっかり。
認識結果の編集画面へ文字を挿入したり、削除したり、範囲選択をしたり、といった関数の下請け関数をえんえんと作る。なんかここまで作るとワードプロセッサを作っているのとほとんど変わんない感じ。ただし、文字認識データのからみもあって、内部構造がひどくねじれたワードプロセッサなんだけどね。(^_^;この段階に来ると色々なからみが出てきて、単純な方針を取ると計算量が非常に多くなるし、複雑な方針を取るとプログラムが訳が分からなくなるので、その辺のさじ加減が難しくなってくる。まあ、ロジックを複雑にして計算量を減らすのは後でなんとでもなるからまあいいか。
初めてスキャナから画像が読み込めた。もっともカラー画像はまだ読めないし、白黒画像も反転して読みとられるんだけど、少しずつ動きだしたようでちょっとほっとする。
たまたまPICT->DIBのファイル変換をやらなきゃいけないことになって、それとほぼ同様のことをやっているIさんが作ったモジュールを見て絶句。
HANDLE foo()
{
…
return FALSE;
…
}
そりゃね、null handleだってFALSEだってマシン語レベルまで落とせば、(処理系依存だとしても少なくともWindowsやMacでは)0だけどさ、HANDLE返すって言っているのに、BOOLのFALSEを返すのはないんじゃない?
更にソースを読んでみると、PICTファイルかどうかの整合性を確かめるのにファイル全体を読んでいることが分かった。つまり整合性を確かめるためにヘッダーだけを調べるんじゃなくて、ファイル全体をロードしてしまうという「とほほ」なプログラムになっていた訳だ。で、アプリケーションがそのPictファイルを読む場合、(1)アプリケーションがファイルの妥当性を調べる(2)読み込みモジュールがファイルの妥当性を調べる(3)メモリに読み込むという手順を踏んでいる。このそれぞれのフェーズで馬鹿でかいファイルをメモリに読み込んでいる。いくらハードディスクが高速化されたとはいえ、この手順は馬鹿でかい画像ファイルを必要量の3倍読んでいる。勘弁してくれぃ…。
という訳で、Iさんにお説教。もっともモジュール分割やら諸般の事情を考えると、2回は読まなくちゃいけない感じだけれど、もうそろそろ自明な無駄は避けるようなプログラミングをしてほしいなぁ。ざっと目を通した私が、ちょっと機能分解して、それを組み合わせただけで、ファイルへのアクセス量が3回から2回に減るんだもんなぁ。
何とか上下・左右のキャレット移動、スクロール処理がうまく動くようになった。範囲選択、文字入力・削除などまだまだ山ほどやることがあって先が思いやられる。
何とか認識エンジンからまともにテーブルデータが出力されるようになったのはいいが、今度はテーブルがまともに描画できないことが分かった。何故かリソースから読み出すペンパターンが読み出す度に違っていてテーブルの分割線がうまく賭けない。１日中悩んでいたが、結局原因が分からず、仕方がないからリソースの中には一種類のペンパターンしか登録しないようにした。(^-^;
キャレットがテーブルにある場合のコーディングが終わってテストをしたかったので、いよいよ嫌だ嫌だと思いながら先延ばしにしてきたエンジン部分の調査に取り掛かる。エンジンは10万行近くあったのだが、１日かけて調べたらやっとおかしなところが見つかった。そこを直したら何とか正常にテーブルが出力されるようになった。同じようなバグがエンジン部分全体に波及していたらと恐れていたのだが、書き直しの途中で生じたエラーらしく、ほっと一息。
結構とんでもない動作をするだろうなと思っていたテーブル内でのキャレットの移動ルーチンも思いのほか順調に動いている。Windows版で何をやっているのか正確に把握できなかったにしては、結構うまく動いている感じ。う〜ん、あんなもんでいいんだろうか?
キャレットがテーブル内にある場合の前後左右移動に関するコーディング。ここは比較的最近になって開発された部分だけれど、もうWindows版とMac版は全然別物のコーディングになってしまっているので、ここもほとんど書き直し。もっとも今の所、エンジンがテーブル部分に関してきゃんと出力してくれないので、試してみるのはそれからになるのだが。
キャレットを１つ右、１つ左に動かす関数を書いてみる。Windows版の対応するソースを読んでみたが、キーディスパッチ関数(OnKeydown())をぱっと見たら妙に長い。行数を計ったら800行あった。むごい。むごすぎる。こんなものは問答無用で破棄。
あまりにあんまりだったので、がっくりしたが、気を取り直して１つ右、１つ左に動かすための下請け関数をぼそぼそと書いた。何とか左右移動に関するコーディングまでが終わったので、ビルドして試してみたら、何とか動いているようだ。延々とやってきてはじめてプログラムに動きが出てきた。ちょっとうれしい。
風邪を引いて具合が悪くて、３日間の間外に出ることはおろか、布団の中からさえもほとんど出られず。
キャレットを飛ばす関数をある程度短くして、少しはロジックを追えるように修正を続ける。途中でどれくらいまで動くんだろうと思って動かしてみたら、怪しいなりに何とか動いているみたいだ。
マウスでクリックした位置にキャレットを飛ばす関数をいじりはじめる。Windows版で対応する機能の中で中心的役割を果たしている関数はすぐに見つかったんだが、いつものとおり、この関数も長い、長い。(T_T)一生懸命作るのはいいけれど、力一杯書かれれば書かれるほど読むほうは辛くなるんだけれどなぁ。
というわけで、元の関数を無駄な所とか関数にまとめてしまえるような所はまとめたりして、何とかアルゴリズムが追えるくらいには短くなるように修正した。けど、多重ループからよく意味の分からない抜け方をしている部分があって、全体がよく分かんない。
Windows版のキャレットの描画ルーチンを読んでみる。なんでたかがキャレット位置を決定するだけのことなのに、200行近いスパゲッティー関数になってしまうのか、訳が分かんない。全く精一杯作るのは構わないが、力一杯書かれては読まなきゃいけないほうはたまらない。
Windowsの場合、SetCaret()とかのAPIを使えばよろしいのだが、Macの場合、タイマーを見ながら自分で線を書いたり消したりしなくちゃならない。大したことじゃないんだけど、ああ、面倒くさい。(^-^;おまけに、キャレットの線がコントロールからはみ出してスクロールバーにかかってしまう。クリッピング領域を再設定しないといけないらしい。う〜む、面倒。
何とかキャレットがうまく点滅できるようになったので、帰宅。
土曜日にシマンテックから来たNorton Utility for MacのNew Versionをwebで購入。MacOS9対応CD云々というのは年明けに2500円とって、CD配布という。確かG3が出た時も同じようにして2500円くらいとられたような気がする。で、その上MacOS9対応のCDで2500円といわれると、気分的には4000円くらい取られた気になってあんまりいい気分ではない。
でもこのシマンテックの戦略って、少なくとも過去においては、いかにアップルがMacOSを場当たり的にやってきたかということの証明なんじゃないかと思う。そうじゃなきゃ、メーカーにはOSのコア部分に関してはFinal相当のものが2ヶ月くらい前には来ているはずなんだから、検査できないってことはない「はず」で、それを考えたら年内にリリースできていいはずなんだけど、それができないのは何故か。私はシマンテックがが「過去のAppleの経歴からいってリリース直後のMacOSの出来に信頼が置けない」と考えているいうことの現れだと思うのね。そもそもファイルシステムは変わっていないのに、なんでMacOS9にはノートンの5.0じゃなきゃいけないんだ?それは過去にトラウマとなった苦い経験があるからに違いないと思うんだよね。まあ単なる想像なんだけど。
OCR for Mac。文字認識した結果がうまく表示されない。まず横スクロールバーの動作が変で、いくらでも右にスクロールしてしまう。何をやっているのかよく分からないソースを適当に(適切にとはとても言えない)修正しているので、動作が変だとなると本当に真剣に読み解かないといけない。泣けてくる。
表示ルーチンは、元のソースファイルは「描画速度を稼ぐために描画しなくていいところ(Viewの見えないところ)は徹底的に描画しない」戦略を取っていて、それが何やら複雑な条件判断を作り出し異常に長いwhileループを作り出す原因になっていた。そこで今回は「プログラム構造を単純化するために描画しなくてもいいところでも描画してしまう」という戦略を取った。どうせ認識エンジンが扱えるのが1万文字なので、全部描画しても今のコンピュータだったらあっという間だし、大体私の頭では400行もある関数は一旦構造を単純化しないと、ついていけないというのもある。
なお、あんまりプログラミングに詳しくない人、つまり私のような人むけに解説しておくと、普通のOSとかWindowマネージャーでは、全部描画するようにプログラムを書いても、実はWindowなどからはみ出した部分はシステムのほうで勝手に「ここははみ出しているな」と勝手に切り捨ててくれる。(これをクリッピングという。)頭が悪くて、複雑なことが分からなくて、楽をしたい私にとってはシステムが勝手に複雑そうなことをやってくれるんだったら、喜んでその恩恵に授かりたい。有り難いことである。
で、問題のルーチンの周辺を詳しく読んでみると、その戦略での作り直しがうまくいっていなくて、描画全領域の計算がおかしくなっていることが分かった。具体的には「この部分は縦の描画サイズの計算しかしていない」と思って関数分割したところが、実は横サイズの計算までしていて、描画領域の横サイズに全然デタラメの値が入っていたことが原因。横サイズを計算するのにnXsize、縦サイズを計算するのにwYなんて対象性のない変数名を使っていたので、すっかり騙されてしまった。(^_^;そのあたりを騙されにくいように書き直したらうまくいった。
もう1つは「スクロールバーの上に文字を描画してしまう」というバグ。コントロール1つ1つがデバイスコンテキストを持っているMS-Windowsと違って、MacはWindowsのデバイスコンテキストにあたるGrafPortはWindow1つに対して1つしかない。だからWindow一杯に文字が表示されてしまうなら話は分かる。しかし、スクロールバーから外れたところはちゃんとクリッピングされているようなのだ。しかも、Windowをスクロールさせる、一旦非表示にしてから、再表示する、サイズを変える、などという動作をさせると、ちゃんとView内部でクリッピングされて、まともに表示される。やっていることは全く変わらないのに、である。
仕方がないのでOffScreenに描画して、それをコピーするという手法でやってみたが、今度は縦のスクロールバーの色が変になってしまう、再描画させると画面が真っ白になってしまうなどの不具合が出た。もう訳が分かんない。困ってIさんに聞いてみたら、IさんはOffScreenから画面に表示させる時には私が使っていたCopyBitsじゃなくてDrawPictureを使ったとのこと。なるほど、とは思ったが、じゃあ最初に表示されるのは何故?とかスクロールバーの色が変になるのは何故?とか考え出すと訳が分からない。
クリッピング領域を変えてみたり、そもそも私がMacの描画システムに関してものすごい間違いをしているんじゃないかとか考えて、参考書を読み漁ったりと、さんざん試行錯誤した結果、Windowを作った直後だけ、DrawSelf()が呼び出されたら、描画全領域(SetImageSize())を設定した後、Refresh()を呼び出してから、一旦システムに制御を戻し、再びシステムからUpdateEventを受け取った時に全領域を描画すればうまくいくということが分かった。やれやれ。この2つのバグを潰すだけでほぼ1日。
で、その試行錯誤をしているうちに、今のところは表データを間違って文字認識させてしまった。表データの認識結果表示に関しては全然デバッグしていなかったので、案の定、全然デタラメの認識結果が表示された。が、あまりにひどかったので、どこがそんなに変なのか調べてみたら、認識エンジンから渡されたパラメータもひどくおかしいことに気がつく。が〜ん。もう認識エンジン周りはカタが着いたと思ったのにィ。失望 + 頭に血が上ったので帰宅することにする。え〜ん。(;_;)