Splash Windowが出てこない障害に対処。LWindow::CreateWindow()を呼び出しているだけなので、どうしてWindowが出てこないのかさっぱりわからない。Windowの設定をいろいろ変えても全然ダメ。ところが同じことをやるサンプルプログラムを作ってみたら、ちゃんとSplash Windowが出てくる。
結局クラスライブラリで通りそうなところを一通り読んだり、あきらめきれずにWindowの設定をいろいろ変えたりという堂々巡り。LWindow::CreateWindow()じゃなくて、APIを直接呼んでみたら、今度は真っ白なWindow。まあ何も出てこないよりマシ?
結局考えられることを次々試して、リソースをもう一度作りなおしたら、なぜか直った。なんで直ったのかは謎のままだが、いろいろ試すうちにFloting Windowはno boarderか、shadow boarderにするとWindow自体が表示されなくなるのが分かった。が〜ん、これじゃDocking可能なツールバーを真面目に実装しようと思ったら、Window Managerの真似をするようなLViewサブクラスを書かなきゃいけないってことじゃん。(+_+)やってられるかぁ〜。
で、次に対処した障害を対処するなかで見つけたのだが、"TextEdit" がクリエータで見つからない。結局 「filetype "TEXT" を処理できるアプリケーションを探す」ということでお茶を濁した。で、その中で発見したこと。
TextEditで拡張子無しの名前「abc」でセーブすると、ファイルが出来る。これは当然。で、これをFinderでみると「abc」という風に見える。ところがこのファイルをTerminalで見ると「abc.rtf」という風にみえる。おい、一体アクセスしたり、加工したりするファイル名はどっちなんだ?MacOS Xをみていると、それまでのファイル属性としてのクリエータによるfile openと拡張子によるfile open戦略がぐちゃぐちゃになっていて、すごく分かりにくい。これだったら拡張子一本の方がよっぽど分かりやすい。明確であるべきfile systemがこんな調子じゃMacOS Xの将来はすごく暗いと思わざるをえない。
MacOS X Carbonでドッキング可能なツールバーを実装するにはどうしたらいいのか調査。現時点でこのツールバーの一番難所はツールバーを移動させる時の処理。移動させるにはツールバーをドラッグするんだけれど、ドラッグ中のマウスの位置によって、ドラッグしている四角形の大きさを変形させなくちゃいけない所。MacOS 9以前はシステムグローバルなGrafPort(WindowsでいうDCみたいなもの)がGetWMgrPort()を使って取得出来たので、そこに直接書いていたけれど、MacOS Xではそれが取得出来ないので、さてどうするんじゃというのが話の始まり。
そもそもドッキング可能なツールバーを自前で実装しなきゃいけないという時点で、どこかが「ひじょ〜」に間違っているという気がするんだが、OEM提供しているクライアントからMacOS Xアプリケーションを作ってくれとリクエストがあって、ライブラリに実装されてないから、自前で実装するしかない。
S師匠からは「全部floating windowにしてしまえ」とアドバイスされていて、確かにそれだと256倍位は楽。ぐっと気分はそちらに傾いているんだけれど、今は工数見積もり段階なので、どうやったら実装出来るか位は調べないといけない。で、Acrobat Reader for Macがドッキング可能なツールバーを実装しているんで、どうにかこうにかすれば実装出来るはずということだけは分かっているという状態。まあさんざん調べて出来ないことが分かるよりはいい、工数が大きければ仕様を変えちゃうことも出来る、というのが慰め。
まずは、今までシステムグローバルなGrafPortを取得するAPIがあったWindow Managerのリファレンスを調べて、何か書いてありそうな所は片っ端から目を通したのだが、「そういうのはやっちゃ駄目」とは書いてあるものの、代わりにどうすればいいのかなんてのは全然書いてない。
あきらめて、Acrobat ReaderをCarbon Daterにかけてみることにした。これは使っているAPIを全部調べて、Carbon非対応のAPIが使われているか判定するツールなんだけど、あるアプリケーションで使っているAPIの一覧表を作ってくれるので、それを眺めてAPIのリファレンスを追っていけばヒントくらいは見つかるだろうという考え。ま、APIのリファレンスを全部調べてヒントをつかもうとするよりはよほど効率的だし、実際にはAPIの名前から、もっと絞り込みが出来る。で、使われているAPIの一覧表をリファレンスを追っていきながら、たどりついた結論。「ヒントなし」泣けてくる。
こうなったら残された手段をとるしかない。「Appleから出されているドキュメントを全部読む」。とはいっても、例えばUSB関係とかは読まなくていいから本当に「全部」読まなきゃいけないわけじゃないけれど、下手すりゃ「Objective-C Frameworkでツールバークラスを新規に書いて、それをコントロールするCブリッジ関数を書き、それをC++から呼び出す」なんてとんでもなく面倒臭いことをしなきゃいけない。気分は真っ暗。ああ、この世には神も仏もないのか?
ところがPDF文書3つ目くらいに読んだ「Carbon Porting Guide」に答えがあった。いわく「Carbon Eventを使えば出来る」とのこと。「Carbon Porting Guide」にあったんだったらもっと早く気がついても良さそうなもの。まあ、別の文書「Introduction to the Carbon Event Manager」にはCarbon Eventの概念的な事しか書いてなかったので、前に読んだ時には、「Introduction〜」より詳しい説明があるとは思わなかったので、読み飛ばしてしまっていたのだった。(^-^;やっぱり神様か仏様はいたんだ…。
という訳で、該当部分を注意深く読む。「そういうのはマウスムーブした時のCarbon Event Handerを使うんだ。」サンプルなど他の文献を見て、何とかEvent Handerの実装方はおぼろげに理解出来た。「このイベントに対するハンドラはこれ」という感じで指定するみたい。よくあるWindowシステムだと、イベントハンドラは1つしか指定出来なくて、そのイベントハンドラで、実際のイベント処理ルーチンに分岐するコードを書くとか、クラスライブラリが適当なメソッドを実行したりする。具体的にどうやってコードを書くかは別だが、なんとなくイメージは分かる。
「そのハンドラはイベントからkEventParamCurrentBoundsパラメータをイベントから受け取って、そのRect構造体を適宜変更して、正常終了すればOK。」ふ〜ん。じゃあイベントからkEventParamCurrentBoundsパラメータを取得するにはどうしたらいいのか?と思ったのだが、そこから先は殆ど何も書いてない。まあイベント構造体を調べれば何か分かるに違いない。
調べてみると、そのハンドラというか、コールバック関数は次のように定義しなくてはいけないことが分かった。
OSStatus MyEventHander(
EventHanderProc inHanderRef,
EventRef inEvent,
void * userData)
で、リファレンスを調べてみたのだが、EventHanderProc、EventRefがどんな構造体なのかさっぱり分かんない。少なくともData Typesのリファレンスには載っていない。唖然。まあ、全く頼りない推測だけど、EventRefがMacOS 9のevent構造体と同じか、その拡張だと思っておこう。ヘッダファイルを調べたら、EventRefというのはOPAQUE構造体、つまりWindowsでいえばプログラマーにとっては単なるHANDLEに過ぎない。構造がないものにはRect構造体なんてないから、一体どうすればアクセス出来るんだ?
「『kEventParamCurrentBoundsってパラメータを使えばいい』と書いてあるじゃないか。少なくともそれがヒントになるでしょ?」ええ、それは私も考えましたよ。ヘッダファイルを含めた統合環境のファイル全部をgrepしてみましたよ。結果、kEventParamCurrentBoundsなんてのはCodeWarrior6.0のファイルにはどこにも記述されていないって分かりましたよ。
一体どうすれば、どこからヒントを得ればいいのやら。(絶句)