ツールバー関連のコーディングの総仕上げ。とはいっても、現段階ではツールバーに動的にコントロールを配置する事を考慮していない。それを実現するためには、まずWindow内に動的にコントロールを作る手法を身につけなくちゃいけないとか、その設定をどこかにセーブしなきゃいけない。で、それらをクリアしたとして、実際プログラムしなきゃいけないことって相当面倒臭いんだよね。ただ、ツールバー関連のアルゴリズムを0から書いたのに比べれば、大体やることがある程度見えているというのは気が楽。ドッキング可能なツールバーをMacで実現する場合には、「MS-Officeで出来ているから不可能じゃないはず」位しか根拠がなくて作り出したから、「どうやってできるか」を見つけるのが大変だったし。ちなみにMacintoshアプリケーションだと、ドッキング可能なツールバーを実装している所なんて、Microsoftくらいしかない。(^_^;
乗り越えなきゃいけないハードルは沢山あるだろう。だが、今まで超えたハードルに比べれば、その次のハードルは超えやすい…と思いたい。ただ、もうプロジェクトがdeath march状態に陥っているなと感じる。上役の度量が大きいのと、気心のしれた小人数だけでやっているせいもあって、今だ決定的な危機状態になっていないのが唯一の救いか?何とか主要な機能だけは早く仕上げないと、完全なdeath march状態になってしまう。
とりあえず、動的なボタン生成をしなければいけない部分以外に関してのツールバーに関するコーディングを終える。仕上げをしている段階で、ハングアップはするんだけど、トレース実行するとハングアップしないというバグに遭遇して、「どうすればいいんだ?」状態になる。しかもハングアップする、しないというのに規則性が見つからない。厄介なタイプのバグだ。
トレース実行でハングアップしている部分が分かんなかったら、動作のログを取るしかない。「動作のログを取る」ともったいつけていっているけど、要するにプログラムの適当な部分に「ここまで出来たよ」というメッセージを何かのファイルに書いておくという手法。極端に言えば、fprintf(fp, "ここまできたよ")なんて奴をエラーが起きていそうな部分にばらまいておくってだけなんだけどね。(^_^;で、今回はそのログを追跡することでそれでなんとかなったので一安心。(^o^)これでかなり安定した拡張可能なツールバーモジュールになったと思う。
2000年度の新人研修のC++担当講師のN君から相談を受ける。C++の研修期間は2週間。N君は今年の新人で、その時のC++の研修講師は私がやったのだが、研修直後「物足りない」とかさんざん批判された。あれだけ辛辣な批判をした彼が、どう2週間の講義を組み立てるか興味津々。へへへ、今度はあんたが批判される立場だぞ。こっちは勝手なことを言って高見の見物としよう。新人研修の講義を一般の社員が聴いちゃいけないというルールはないんだから、講義を受けてみて嫌味な質問をするってものありだよな。(^_^;そういう変なツッコミをされないように教える立場にふさわしい程度の知識は勉強しておくように。>N君(^_^;
Macのドッキング可能なツールバークラス。うまく動いているようにみえるプロトタイプモジュールとそれを使ったサンプルプログラムも、現実のプロジェクトでちゃんと使えるとは限らない。プロトタイプで作ったモジュールを現実のプロジェクトに反映させるとなると、「あの機能がない、この機能がない」となってきてどんどん機能を追加する羽目になる。今回の場合は実装者と利用者が同一人物(私)だったのですんなりいったが、このツールバー関連の仕様に関して、仕様作成者・実装者が別の人で、私は単なる利用者だったら「お前、このクラスが実用になると思ってるのか?」と喧嘩になったに違いない。(^_^;
幸い(?)、今回の場合は同一人物なので、まさか自分と喧嘩するわけにもいかないのだが(苦笑)、本来だったらきっちり時間をかけてツールバークラスに必要なメソッドを決めるんだろうな、と思う。実装者と利用者が同一人物(か、それに近い人物)だということを前提にして設計してくのは、多分他の会社では通用しないんだろうなぁと漠然と思う。他の会社ってその辺の資源の再利用ってどうなっているんだろうか?
とりあえず、かなり汎用的なツールバークラスを書けたのでその点では満足。普通のWindowと同じようには使えないが、かなり同じように使えるように書けたと思う。動的に機能を追加出来るメソッドを追加する(ただしWindowsでやる場合に比べてかなり難しい)とほぼ完全な汎用クラスになるだろうと思う。ま、せっかく汎用的に書いても使ってくれる人が自分しかいないんじゃ自己満足以外の何者でもないんだろうけどね。(苦笑)
Windowsのツールバーってほとんど自分でプログラムしたことがないんで知らなかったんだけど、ツールバーボタンに書いてある絵のリソースってまとめて1枚のBMPになっている。Mac上で(自分で)構築したツールバークラスは1つ1つのボタンに対して絵のリソース(PICTリソース)を割り当ているように作っている。だからまずやることは、まとめてある絵を1つ1つの絵に分解する作業。地味でやることが決まっているルーチンワークなんだけど、ボタンの数が80個近くあるだけに大変。これって手でやるよりも何か即席のツールを作ったほうがよかったかなぁ。
で、こうやって苦労して作ったPICTリソースを製品の仕様通り使うためには、
WindowsのVisual C/C++だと、シンボルと即値の対応ってリソースを作っている時に自動的に1対1に作られるので、その辺はやっぱり楽だよなぁと思う。もっともそれを言い出したら、ドッキングツールバークラスのないMacintoshのクラスライブラリなんて「移植するには使えない」で切り捨てられるんだけど、現実問題として移植する場合にはこれしかないから、「Windows→Macの移植は普通に考えられているよりも大変」という事実だけを指摘しておきましょう。(^_^;
社内に試験的に導入されたLotus Notesを使ったシステムだが、素晴らしく使いにくい。(-_-;「これだったらネットニュースシステムを流用したほうがよっぽどいい」と無茶を承知で「Lotus Notesを使うように」と言ってきた部長にメールで食い掛かったら、それが巡りめぐって、実務担当者にそのメールが行った。で、その実務担当者から「確かにそっちの方がいいかもしれない」なんて意外な返事をもらったりする。私の場合、現在これだけMac版の開発が遅れている以上、社内の立場では「失うものは何もない、クビにするならしてくんな」という開き直り状態な訳で、そういう立場だからもうなんでも言えるんだけど(^_^;;、実務担当からそう言われると、逆になんだがこっちの立場がないというか…。
でも「ネットニュースシステムを流用したほうがよっぽどいい」と公に言ってしまった手前、言っているだけだといわれると業腹なので、早速手持ちのWin2000サーバーで仮想NNTPサーバーを立ち上げて、Notesの1つの会議室の記事全部をそっくりNNTPサーバーにコピーして、「NNTPでやったほうがいいぞ、どんな風になるかってのはここを見てくれ」と社内電子掲示板に書きこんでデモンストレーション。もちろん「業腹」ってのは完全な言い訳で、単にWin2000でニュースサーバーをどう管理するのか、実地で試してみたかったというだけなんだけど、「本当は単に遊んでいることに、もっともらしい仕事の理由を付ける」というのは不良社員としての基本中の基本ですね。(^_^;
ところで、Win2000の仮想NNTPサーバで記事のfeed設定ってどうやるんだろう?知っている人がいたら、教えて下さい。<(_ _)>(出来ないって落ちだったりして。まさかな。でもそれっぽい設定が見つけられないの。シクシク)
Mac用に作ったツールバークラス。Windowsのツールバー関係のリソースをMacに持ってくるには、単純だけど、手数がかかることをやんなきゃいけないらしいと知って愕然とする。ツールバークラスを書いただけじゃ道のりの半分くらいしか終ってなかったんだ。(;_;)
MFCのツールバークラスの場合、ツールバーのボタンに書かれているイメージは1つのツールバーにつき1つのBMPしかイメージデータを持っていないんだけど、私の書いたMacで作ったツールバークラスは1つのボタンにつき、1つのイメージデータが必要。だから、Windowsの1つのBMPリソースをちまちまと分割する作業をしなきゃいけない。ああ、面倒臭い…。で、そのBMPリソースをMacで使えるPICTにして、それをさらにリソースに組み込むとなると…。いつになったら終るんだろう、このプロジェクト。頭が痛い…。
ツールバーのボタン自体は、一番多く表示されている時で40弱。ところが、「ツールバーのボタンが大きい・小さいをカスタマイズ出来る」という仕様があるんで、結局80くらいのボタンの動作を設定しなくちゃいけない。で、さらにだ。MacのAPIの仕様上、ドッキング可能なツールバーを実現するためには、ドッキング状態のWindowテンプレートとドッキングしていないWindowテンプレートとを別々に用意しなくちゃいけなくて、結局設定しなくちゃいけないツールバーボタンの数は倍の160個弱。これでバグが出なかったら、奇跡以外の何者でもない。(^_^;
とりあえず、作業はしているものの、「何とかちょこちょこっておまじないをすると そんな面倒なことはしなくてすむようにできないかなぁ」なんて考えながら作業をしているうちに一日が終る。いろいろ考えたけど、結局楽は出来ないみたい。(がっくり)
家に帰ったら、母親から「お前から借りたヘッドフォンが動かない」と言われた。が、実際に使ってみるとちゃんと音は出る。はて?
vyama「ちゃんと音は出てるよね。」
母「でも、このヘッドフォン、どこにも線を繋ぐ所がないじゃない。それで、どこにつなげればいいのか分かんなかったの。」
vyama「このヘッドフォン、ワイヤレスなんだってば…。」
なるほど、説明していなかった私も悪い。(^_^;とりあえずどうやって使えばいいのかを説明したら、「知らないあいだに便利なモノができたものだ」と結構面白がっていた。
家の留守番電話が壊れたので、この機会にFAX付きの電話機に換えようということになったのだが、ちょうど都合よく(?)行きつけの電気屋さんがらみのPanasonicイベント(「町の電気屋さん」云々という奴)があったので、そこでFAX付きの電話機を買うことにする。量販店で安く買うというのも1つの手なんだけれど、なじみの電気屋さんで買えば、故障した時にも来てもらいやすい。メンテナンスをするのが私だったら量販店で買うんだろうけど、電話機を使うのは機械オンチの私の両親だから、その点を考えると多少の出費は仕方がないか。(この手の電気屋さんは出張サービスをしてくれるのがありがたい。)という訳で、そのイベント会場へ母親と連れ立って車で行く。
最近、私の母親は車の免許を取ろうと頑張っている。教習所の入学申し込みは終っているが、入学はまだ。で、親戚から借りた教習本を一生懸命読んでいるらしい。で、一通り借りてきた本だけは読み終わったらしく、車の構造とかだったら大丈夫と自信満々。こういう人にはちょっと意地悪なテストをしてみるに限る。(^_^;
ちなみにこの時乗っていた車は日産サニーで、タコメータのない車種だというのがミソ。
vyama「この運転席からみてタコメータはどれ?」
母「(スピードメータを指差して、自信満々で)これがタコメータ!」
vyama「じゃあスピードメータはどこ?」
母「タコメータはここだったから…、(走行メータを差して)じゃあこれがスピードメータ!」
vyama「ふ〜ん。(赤信号が近くなったので)今、スピードを落としたけど、あんたのいうスピードメータって数字が落ちないよねぇ。不思議だねぇ。」
母「(燃料系を差して)じゃあ、こっちのメーターかなぁ。」
vyama「こっちのメータはさっきからほとんどぴくりともしないけど?」
母「参った、降参。分からないから教えて。」
vyama「ええと、これがスピードメータ。これが走行メータ。こっちは燃料計。で、この車にはタコメータがないってのが正解。」
母「タコメータがないなんて教習所からもらった本にはなかったから、こっちの機械のほうが間違っている!」
vyama「…そうですか…。」
本当にこの母親、免許を取れるんだろうか?(^_^;
ドッキングツールバーモジュールの、昨日デバッグ仕切れなかった部分のデバッグや、やるべきことが自明なバターンの最終コーディング。昨日まではドッキング出来る・出来ないという仕様上本質的な所を気に病んでいたんだが、今日やらなくちゃいけないのは、アプリケーションがActiveじゃなかったらツールバーは消されているべきだとか、大体パターンが決まっているような処理だったので、何とか順調に済んだ。
昨日一気にコーディングしたドッキングバー関連のデバッグ。ドッキングできたことはできたのだが、動作自体はこっちが想定していたものとはちょっと違う。調べてみると、引数の順番が違っていた(座標を縦、横の順で並べなきゃいけないのに、横、縦の順で並べていた)とか単純なミスばっかりで、アルゴリズムに大ポカがあっての動作異常じゃなかったので一安心。
動作チェックをしている間に、ドッキングしているツールバー領域がどんどん大きくなっていって、ドッキングしていないツールバーを隠してしまうという問題が発生。いろいろ考えると、ドッキングしていないツールバーのZorderも考えてコントロールしなきゃいけないということに気がついて一瞬青くなったのだが、これも何とか解決の目処が立つ。やれやれ。
ツールバーに関してはまだマイナーとはいえないような問題が残っていたが、今日は落語会の日なので、さっさと帰る。今日の演者は金原亭伯楽と三遊亭夢楽。演目は毎度おなじみの…といっても私はその演目の題名を知らないんだけど(^_^;、伯楽師匠は魚屋と「お金を拾ったのは夢だったんだ」と旦那を騙して旦那を更正(?)させるという、できた女房の人情話、夢楽師匠は巡礼参りを待つお女将さん達が髪を下ろしてしまう滑稽噺。
伯楽師匠の芸はいつもの通り。お酒を飲んでいる人を演じているのを見ていると、なんだかこっちも無性に酒を飲みたくなってくるような気分になる。実際に酒を飲んでいるんじゃないんだけれど、不思議なもんだ。(^_^;
いつもは中間休憩を挟んでそれぞれもう1席ずつやるんだけど、今回の落語会は趣向で伯楽師匠と夢楽師匠が「酔談」と称して二人同時に舞台に上がり、漫才風の話芸を見せてくれた。伯楽師匠が喋り、夢楽師匠が所々で合いの手を適宜に打つといった感じ。で、話題のほとんどが「芸人の肥やし」の「買う」の部分。(^_^;まあ、あの場にいた人達は「大人」ばかりなので、笑って済ませられるだろうけど、あれと同じことを社内の女性に話す勇気はないよなぁ、感じの話だった。でもその話を聞いて、声を高くして笑っているのはどっちかというと女の人だったような気が…したような、しなかったような…。(^_^;
Windows版のトラブルシューティングを何とか終えて、Mac版のコーディングに戻る。αに向けてスキャナ回りで、コーディングが終っていて、動くはずだった部分が動かないということだったので、とりあえずその部分が動かないのは何故かということを調べはじめる。詳しく追っかけてみたら、スキャナ回りのコーディングをしてくれた人のモジュール内での問題らしい。とりあえずどの部分が動かないかというのを報告して、その部分の調査は終り。
という訳で、ドッキングツールバーのコーディングを続行。懸案は1つ以上のツールバーがドッキングされた状態の時にもう1つツールバーをドッキングさせた時に何をしなきゃいけないのか、そして3つ以上ドッキングされた状態の時にその内の1つを任意に動かした場合に何をしなきゃいけないのかということ。個別のケースにはどう振る舞うかっていうのははっきりしているんだけど、それを包括的なルールというか動作アルゴリズムの形にまとめきれなくて、その部分で悶々としていた。単に使っている時にはあんまり意識していなかったんだけど、ドッキングツールバーの動作って意外と考えることが多くてびっくり。(ちなみにツールバーの数は任意)今作っているアプリケーションに特化して力ずくでごりごりやるのは絶対避けたい。ま、正直言えば、せっかく作ったんだから他のプログラムでも利用が容易な制限の少ない(今回作っているアプリケーションはツールバーがいくつだからみたいな制限だけでなく、アプリケーションで利用できるツールバーの個数が100以内(^_^;という現実的な限定も含む)ライブラリみたいな形にしたかったというこだわりがなければ楽にできたんだろうけど。
実はWindows版のトラブルシューティングをやりながら悶々していたんだが、3連休中に思いついたルールがあって、これが考えられるだけの状況をうまくルール化出来ていそうだったので、今日はひたすらそれをコーディング。久しぶりに集中してコーディングだけしたような気がする。今回は勉強だと思ってSTLを意識的に使うようにした(今までも部分的には使っていたけど、vectorくらいしか使ってなかった)ので、その分時間がかかった。
延々コーディングした後、make。一杯コンパイルエラーが出たが、タイプミスの多い私の場合はこんなのは当たり前。(^_^;コンパイルが通ったところで、実際に動作させてみたら、ちゃんと2つ以上の場合でもドッキング、ドッキングオフができた。(1つのツールバーをメニューバーにドッキングさせることは、3/9時点で出来ていた。)ドッキングした後のToolbarの位置が変だったりするんだが、とりあえずドッキング動作が出来ただけで今日は大満足。
いろんな事があったけど、とてもまずすぎて書けない。←単に忘れたというツッコミは却下。(^_^;
Windows版のトラブルシューティングに追われて、Mac版のコーディングは殆ど進まなかった。それにしてもMicrosoft WordのRTFファイルの読み出しって死にやすいよなぁ。
ドッキング可能なツールバーのコーディングを続行。Sさんにデスクトップのグラフポートを取得するAPIを聞いたがすぐには分からないという。ただ、floating windowを作る時にそんなAPIを使った憶えがあるということで、WWWでfloating windowを作る時のサンプルを調べてみる。そしたら、GetWMgrPort()というAPIを見つけた。これで、何とかなりそうだ。
で、GetWMgrPort()で得たポートをカレントポートにしてみて、DragGrayRgn()を呼び出してみたが、やっぱり、あるWindow内でしかドラッグできない。困り果てて、サンプルをもう一度読み直すと、クリッピング領域を変更している。ああ、そうかと気がつく。WindowsだとDevice Contextごとにクリッピング領域があるんで、Portを切り替えるとクリッピング領域も自動的に変更されるのが当然だと考えていたんだけど、Macintoshはクリッピング領域をすべてのプログラムで共有するんだったけ。改めてクリッピング領域を全画面に設定したら、何とかデスクトップ内でドラッグすることができた。が、やっぱりメニュー領域にドラッグすると、ドラッグできなくなってしまう。
ええい、きっぱりMacOSがそういう用途を想定しないと認めてしまおう。認めてしまえば、それが良いかどうかは別として、DragGrayRegion()相当の関数を書こうと言う気になる。で、書いてみたら、思ったよりはあっさり書けた。しかし、面倒臭いことこの上ない。関係するユーティリティークラスなどを書いていたら、結構時間がかかってしまったが、自分で一旦書く肝っ玉がすわって、方法さえ分かっていれば、後は何とかなる。で、何とかドラッグに関しては想定していたものが出来た。
で、ドラッグが出来た。次はドッキングした状態でどうやってツールバーを描画するのかだ。これがよく分からない。最初はWindowsのSetWindowLong()みたいなAPIがあって、それを使えばWindowStyleとかを簡単に変えられると思ったのだが、いくら調べてみてもそれっぽいAPIが見つからない。これで、目論見が崩れた結果、どうすればいいのか詰まってしまって、悩みに悩んだ揚げ句、結局うまい解決方法が見つからかった。まさか、ドッキングスタイルのwindowとドッキングスタイルじゃないLWindowオブジェクトの生成消滅をがんがん繰り返すなんてのは、PowerPlantのBroadcastingのメカニズムから考えると、考えられないし。で、今日はGiveup。
家に帰ってから、Toolbarのウィンドウを作る時に、実際にはfloating styleのツールバーと、ドッキング状態のツールバーを同時に作っておいて、適宜どちらかだけを表示することにすればそれっぽく見えるだろうというアイデアが浮かんだ。これだと、いちいちWindowを生成・消滅指せる手間がなくなるし、1つのメソッドで2つのWindowを同時に制御するようにすれば、事実上1つのToolbarとして扱える訳で都合がいい。その他でもいろいろメリットがありそうだ。明日早速試してみよう。
Sさんに渡す認識設定回りの関数I/Fの仕様書を作り終わって、設定パラメータを認識エンジンに渡すコーディングも大体終ったので、実はまだどれだけ掛かるか分からない部分の調査を始める。
まずはドッキング可能なツールバー。他のMacintoshプログラムでざっと調べた範囲ではMicrosoftの出している製品くらいしかそんなツールバーを実装している所はない。1)半分以上のプログラムはツールバーなんてのはそもそも存在しないし、2)残りのプログラムのほとんどはツールバーをwindowの中に埋めこんでいるから、メニューとドッキング可能なんてのは考えられない。唯一Windowの中に埋めこんでいない、3)メニューバーのすぐ下にツールバーがあったのがCorel WordPerfectだが、WordPerfectの場合は分離してツールパレット(MacintoshのToolbox用語ではfloating window)になるなんて機能はない。
前のバージョンはMS-Windowsとのクロス開発環境で作っていたので、ライブラリがドッキング可能なfloating toolbarをサポートしてくれた、というか勝手にやっていたみたいなので、今回もやらざるを得ない。しかし、通常のMacintoshプログラムを見ていると1)のパターンはツールバーに関してやることがないし、2)もツールバーのボタンをwindowのリソースの中に埋めこんでしまえばいいだけだから、これも簡単。3)の場合は、メニューバーのすぐ下にボタンだけ並んだタイトルバーなしの枠なしfloating windowを表示すればいいだけだから、これも簡単にできることが分かった。しかし、それ以上のことをやろうと思ったら、全部自分で書かなくちゃいけないらしい。つまりドッキング可能なツールバーのクラスを書かなくちゃいけないらしい。湯水の様に時間があって、鬼のようのMacintoshに詳しい人が沢山いるMicrosoftがやるならともかく、今の締め切りの状態で私にそんなものを書くのは限りなく不可能に近い。(^_^;
そんなもん1日や2日で書けるかぁ!と一声かけて仕様変更できればいいんだけれど、あいにく外部仕様上のクリティカルな部分に関っているので、それもできない。泣く泣くドッキング可能なtoolbarを実現するサンプルアプリケーションとそれをサポートするクラスを書きはじめる。
まず手始めに、floating toolbarを1つ作った。これはほとんどなんにも考えなくても出来る。しかし、このfloating toolbarを移動させる時に、マウスポインタがメニューバーと重なるとwindowのアウトラインが消えてしまう。つまりwindowをdragしてメニューバーのある場所に持っていったら、その場所はwindowが存在するべき場所ではないと判断されて(?)、windowのアウトラインを消してしまうらしい。これは非常にまずい。
関係ありそうなAPIのドキュメントを虱潰しに調べたら、DragWindow()というAPIがあって、そこでwindowが存在できる範囲を調整できるらしいと分かった。で、ClickDrag()をオーバーライドして、DragWindow()を使い、画面の全範囲にドラッグできるように変えればうまくいくに違いない。
え〜と、画面の全範囲を取ってくるAPIはなんだっけ?確か本に書いてあったよな…と本を調べてみるとLMGetGrayRgn()を使えと書いてある。GetとRgnは分かるけど、Grayの意味が良く分かんない。LMは意味が分かんないけど、それでもGetGrayRgn()が画面の全範囲を取ってくる関数だというのは、ちょっと想像できない。「てめぇ何考えて名前を付けてるんだぁ?」と怒鳴り込みたくなるようなネーミングセンスである。(-_-;
さて、使うのはいいけど、念のためAPIのリファレンスを調べてみると、LMGetGrayRgn()なんてAPIは存在しない。「理不尽じゃぁ〜」との叫び声を押さえつつ、ファイル回りでFSSpec構造体を利用するAPIがFSpXXXXで、ParmBlk構造体を利用するAPIがPBXXXXということから類推して、LMも何かの構造体の略のはずだから、その構造体を利用しているAPIセットはLMうんたらという名前を持っているに違いない。と思って、関係していそうなAPIのリファレンスを丹念に読んでいった。もちろん、どこかでLMうんたらという名前に遭遇することを願って読んでいった訳だ。
で、調べていったら、GetGrayRgn()というAPIを使えばいいということが分かる。後から考えれば「LM外せばいいだけじゃん」となるけれど、実際はLMってのがなんの略なのか分からなかくて、LMというキーワードに惑わされた結果、見当違いの調べ方をしていた野で、調べ方としては「見当違いのところを探したけれど、たまたま運がよくて探し当てられた」という感じに近い。で、肝心のキーワードだと思ったLMの略は「Low Memor accessor」の略らしい。そんな訳のわかんない省略法が分かる分けないじゃないか。(-_-;過去にはLMGetGrayRgn()は使って良かったはずなんだから、OSのバージョンが上がって使えなくなったとしても「代わりにGetGrayRgn()を使え」と一言あれば、1時間近くもんもんとしながらあんなに悩まなくてすんだのに。
その点ではMicrosoftって偉いと思う。Appleのリファレンスライブラリ(MS-WindowのMSDNに相当)なんて、単語のサーチをするのにもいちいちAppleのWebsiteに繋がないと検索できないとくる。さもなきゃ、htmlファイルをgrepするしかないんだけど、MSDNの検索機能よりは10年くらい遅れている。Macintosh用のプログラムを世の中に多く出してほしければ、ここら辺からどうにかしないとどうしようもないぞ。
まあ、何とか全画面分のRegionを見つけるAPIは見つかった。早速、そのAPIを使ってClickDrag()をオーバーロード。これで全てうまくいくはず…のつもりだったが、DragWindow()の中でドラッグできる範囲からメニューバー部分を除いているみたいで、状況が変わらず。小さな親切、大きなお世話どころか大迷惑の典型である。(-_-;
さらにドキュメントを読んでいると、すぐDragGrayRgn()というAPIが見つかる。こいつはマウスボタンが押されている間のドラッグ処理をやってくれるAPIで、先程のDragWindow()はDragGrayRgn()とMoveWindow()という2つのAPIを使って自走されているんだということらしいことがドキュメントに書いてある。ということは、下位関数のDragGrayRgn()とMoveWindow()を使えば、先程のDragWindow()で出来なかったもっときめ細かい処理が出来ると期待してよく、これで1つ問題を突破したかに見えたような気がした。見えたような気がした?そう、つまり最後の最後に来て、どんつまりになってしまったのだ。
DragGrayRgn()は、カレントのグラフポート内でのwindowの移動をサポートする。PowerPlantの提供する環境では、普通はカレントのグラフポートは制御が渡されたwindowのグラフポートになっている。確かにそれは自然だ。ところが、今回の用途ではグローバルなデスクトップでの描画が要求されている。だから、カレントポートをデスクトップのグラフポートを設定しなくてはいけないのだが、今日のところはDesktopのグラフポートに対するアクセスの方法が全然分からない。どこかに突破口はあると思うのだが、他の人がやっていないということから考えて、ほとんど「これは駄目だぁ」モード。
今日の経験からいえば、Macintoshのプログラム人口が廃れていったのも無理はないよなと思う。少なくとも苦労ばかり多くて、実が少ないから「プログラムを組んで生活していこう」という人にMacintoshだけは勧めないと思うな。
OCRの認識パラメータ設定の関数I/Fの仕様書を書く。もともともプログラムの関数仕様書がないから、コードを追っかけて後追いで仕様書を書くというのも変な話なんだが、まあそれはいい。ところが、コードを追っかけてみると、構造体のフィールドの中には、設定しただけで参照されていないとか、そもそも全然使われていないとか、名前とは全然違う意味で使われていたりするなんてのが結構あって、おまけに設定する関数自体もデフォルト100行以上だったりするんで、まるで「オープンなブラックボックス」状態。
ソースを読んでいると「これは変だぞ」という箇所にぶつかったりして、その度に気になってソースを追っかけて見たりして、もう泥沼状態。それでも何とか認識パラメータの設定ダイアログがアクセスしなければいけないフィールドに関しては何とかドキュメントがまとめられたけど、まだまだ書かなくちゃいけない仕様が残っているもんなぁ。やっぱりドキュメントを書くのは疲れる。(^_^;
ところでMacintoshってコンパイルをしている途中、タスクスイッチが利かない。コンパイルをしている途中、本当に「ボ〜としている」しか仕方がない訳だ。プリエンピティブなマルチタスクOSのWindows95/NT/UNIX系統だったら、何とかメーラーを使ったりとか出来る(もちろんレスポンスは落ちる)んだけど、Macintoshってそういうことって全然出来ないんだもんなぁ。こんな古臭いOSをありがたがっている人が何を考えているかってのが、私にはさっぱり分からないし、だからその人達が使うようなソフトウェアを書くことに何か意味を見いだすこともできない。でも、きっと「それじゃいけない」んだろうな。何かMacOSの決定的な長所を見つけ出せれば救われると思うんだけど、それを知っている人は是非教えて下さい。(^_^;
Iさんが今抱えているプログラムで詰まったらしくて質問に来た。基本的にはSJISテキストファイルの文字数を数える(バイト数ではない)プログラムで、私はそんなに難しいとは思わないんだけど、1byte == 1文字のpureな世界よりは面倒なことは確かだし、文字コードに関する知識も必要だ。その面倒臭さをちゃんと面倒を見られればいいんだけれど、一般人レベルでコンピュータをいじっている分には(多分、この日記を読んでいる人にはその面倒臭さを知りつくしている人が多いだろうが(^_^;)、そんな事は意識しなくてもいい訳で、確かに初めてそんな事にぶちあたったら戸惑うだろうなぁと思った。もちろん、教える時はそんな事は容赦なしにびしびし「テメ〜こんな事も知らないのかぁ」と罵声を浴びせていたんだけどさ。(^_^;←鬼
コマンドプロンプトで起動時にDOSKEYマクロを登録する方法をようやく見つけた。cmd.exeの設定で、/Kオプションを設定すればいいというのがその答え。分かってしまえば単純だけど、発見するまでは艱難辛苦。まあ、そんなものなんだろうな。
TさんがMacintoshプログラムの件で私に相談に来る。それって無謀だよなぁ、と思いつつ、何とか質問には答えられたようだ。で、後でその問題をTさんが解決した後に「Macってなんてプログラムが面倒なんだ!」と言ったという話を聞いた。そうだよね。MacintoshのプログラムはWindowsとかUNIXとかに比べると、信じられないくらい制約が多いし、プログラムも組みにくい。メモリ管理とかリソース管理なんてのはユーザの立場からすれば使いやすいんだろうけど(ただし、私はMacOSがユーザとして使いやすいと思ったことは今までない)、無茶苦茶だと思う。経験を通じて痛い思いをして学ぶしかない事柄が多すぎて、閉口する。標準的なプログラミングの常識がまるで通じないんだもんなぁ。