朝起きたら、頭が痛いし、体がだるい。熱を計ってみたらかなり熱があった。こんな時は無理して会社に行っても能率が上がらないし、下手に同僚に病気をうつしでもしたらそれこそ周りに大迷惑だという訳で、会社を休む事に決定。その旨、会社に連絡を入れる。
まあ、大したことがないだろうと思って、薬を飲んで軽めの本でも読もうかなと思ったのだが、活字を見たら目がしょぼしょぼしてくるので、まともに本が読めない。仕方がないので一日中布団の中でじっと寝ていた。ま、風邪を引いた時にはこれが一番。
本当は某OEM提供元である某国海外ソフトハウスからβバージョンプログラムが届くはずだったのだが、「プログラムが2byteコードに対応していない」というなんか信じがたい理由で今日になっても届いていない。まあ、間に合わないという連絡は受けていたので、もう一度スケジュールを再提出してもらったのだが、受け取ってみてびっくり。βが11月になっていた。ふざけるんじゃない。(-_-;
で、プログラムにはほとんど関係のないヘルプ、マニュアルの翻訳作業のβ版もそれに合わせて遅らせるとか、そのスケジュールの遅れを、β期間を短縮することで最終的なつじつまを合わせるというとんでもないものだったので、「当初予定していたβ期間が短く済ませることができるという合理的な理由と、プログラムとは関係のないヘルプ、マニュアルの進捗状況報告がなければ納得できない」とこっちの会社の窓口担当者に連絡しておいた。こっちを安心させるつもりだったら、もうちょっと説得力がないとねぇ。
Mac。メモリを買おうと思っているのだが、どんなメモリを買えばいいのかよくわからないし、どうせメモリを差す時にはケースを開けなければいけないからと思って、ケースを開けてみる。開けること自体は簡単だったのだが、それ以上分解できない。メモリを差すにはどうやらマザーボードを筐体から外さないいけないみたいだし、筐体から外すにはマザーボードから諸々のケーブルを外して、CPUボードも外さないといけないような感じ。「使いやすい」が売り文句のMacが、高がメモリ増設くらいでそこまでしないといけないなんてのは考えられないので、きっと何か私の気がつかない方法があるに違いない。
そういう訳で、Mac使いのMさんにメモリの増設の仕方を教えてもらう。Mさんにメモリスロットルを見たいからという理由で、ばらしてもらったのだがやっぱりマザーボードから諸々のケーブルを外して、CPUボードを外していた。高がメモり増設するのにマザーボードを筐体から引っ剥がすなんて手間をかけるなんて…、と愚痴をいったら私が今使っている8600/180というマシンは一連のMac製品の中でも格段にメモリ増設がしにくい機種なんだという。妙に納得。
やっと変数のTypeに関するドキュメントを直接検索する方法が分かった。まあ、やっぱりないはずはないと思っていたのだが、Windowsの環境に比べると相当面倒な気がする。Inside Macもあんなにファイルがあったら簡単にgrepとか出来ないもんなぁ。しかもPDFだし。はぁ。
今、テキストにしている本をやっと読み終えた。もっともFATバイナリー関係の記述は読み飛ばしたのだが、いまさら68K用のプログラムの書き方とかテクニックを勉強しても意味が薄い。実際私がWindowsプログラムを書きはじめたのはwin32からなので、本当だったら協調的マルチタスクOSでなんか書きたくないし(はやくRapsody出ないかな)、ましてや私のチームが書いているプログラムは強力なCPUパワーが必要なんだから、今更68Kで書いても実質使えないし。
で、ちょっと古めの本だったのであれなんだけど、結局その本で読んだサンプルプログラムというのが、4本くらいしかなかったので、結局メニューとダイアログの出し方くらいしか勉強できなかったような気がする。たったこれだけのことを勉強するのに一体何日かかっているのだ?と思って、暗い気持ちになる。
今日読んだ中で面食らった記述がこれ。この部分が変更になります、と書いてあったので、変更部分のソースファイルを読んでみたのだがさっぱり意味が分からない。どう読んでも無限ループにはまってしまうような気がするのだ。
ぱっと読むと、グローバル変数gdragNDropFlagに何かの操作をしてから、これまたグローバル変数guserDoneがFALSEだったら、whileで無限ループに飛び込んでいるように見える。この無限ループを抜け出すには、どこかで割り込みがかかってguserDoneを変更する位しか思いつかない。ところが、ソースファイルを調べてみてもcallback関数がないから、その可能性がない。ますます訳が分からない。if (gdragNDropFlag >= 0) --gdragNDropFlag; } while (guserDone == FALSE) ;
1時間ほど悩んでいたのだが、よくよくソースファイルを見つめていて気がついた。閉じ注カッコが1つ多いんである。本当だったら、
のはずだ。あれれ?と思ってこの1つ多い閉じ括弧はどこに対応しているのか調べてみたら…、あったあった、do。このカッコはifに対応しているんじゃなくてその変更部分のず〜と先にあるdoのカッコに対応していたのだ。(^_^;この本の作者は、if (gdragNDropFlag >= 0) { --gdragNDropFlag; } while (guserDone == FALSE)
というインデントスタイルを取るので、部分的に見ていったら、分かりにくいったらありゃしない。でも、この著者はBYTE誌のテクニカルライターだっていうのだから、まるっきり素人でもない。私にはこれが読みやすい形式だっていうのがさっぱり理解出来ないんだが、やっぱりクセというか、習慣なんだろうな。ちなみに私のインデントスタイルは、do { hogehoge1(); if (gdragNDropFlag >= 0) --gdragNDropFlag; } while (guserDone == FALSE) ;
一方、Microsoft提供のサンプルコードなんかを見てみるとdo { hogehoge1(); if (gdragNDropFlag >= 0) { --gdragNDropFlag; } } while (guserDone == FALSE);
みたいな感じ。まあ、どれが読みやすいなんて宗教論争はするつもりがないけれど、世の中って広いんだなぁと感じた。do { hogehoge1(); if (gdragNDropFlag >= 0) --gdragNDropFlag; } while (guserDone == FALSE);
Macプログラムの参考書を一冊本を読みおえた所で、区切りがいいので帰ろうとすると隣のパーティションのIさんの所からうんうんうなっている声が聞こえる。面白がって事情を聞いてみたら、GlobalAllocしたメモリをGlobalLock、GlobalUnlockを繰り返しているうちに、なんだかポインタの値がずれてしまうというにわかには信じがたい話。で、早速ソースファイルを読んだのだが、これも1つのループが長いし、関数の頭でGlobalLockをやって、関数の終わりにGlobalUnlockをやれば済む話なのに、ループの中でGlobalLock、GlobalUnlockを繰り返しやっているので一緒にコードを追いかけてくらくらしてきた。
大体C++でやっているならメモリ確保なんてnewを使ってやったほうが(例外処理を含めて)よっぽど楽だし、win31時代じゃないんだからGlobalAllocなんて使って、何のメリットがあるのか私にはさっぱり分からない。GlobalAllocを使えばメモリの管理効率が良くなることがあったのは事実だけれど、win32だったらほとんど意味がないように思えるし、それでプログラムが分かりにくくなるくらいだったら、さっさとGlobalAllocなんて使うのを止めるべきだ。
最終的にはエラーは直らなかったのだが、1つだけ変なコーディングをしている所を見つけた。
最初は何かの処理というところで何か変なことをやっているのだろうと思っていたのだが、状況からしてループの終了条件が何かおかしいのではないかと気がついたので、ループが終了している所を片っ端からチェックしてぶち当たったのがこのif文。最初に読んだ時に、wCountが0の時に変になるんじゃないかと思ったのだが、見逃してしまった。もう一度見直してみたら、これ、wCountがWORD型だから、wCountが0の時に--wCountしたら、65535になって永久にこの終了条件が成立しないじゃん。(^_^;ここは、wCountをWORDじゃなくてINTとかの符号付き整数にしなければいけない。気がついた時には、何でこんなのを見逃したんだ?という思いと少しは役に立てたかな?という思いとが交錯したが、もう一度実行してみると、確かに局所的にはうまくいっているのだけれど、どうやら他で大問題を抱えているようで、さっぱり事態はよくならない。(^_^;ま、そんなこともあるよね。後は自力で頑張ってね。>>Iさん。while (何かの条件) { //何かの処理 if (--wCount < 0) { break; } //何かの処理 }
見ず知らずのOさんからYooEditに関する情報が届く。ありがたいです。(感涙)でもやっぱりダイアモンドカーソルのWordStarコンパチエディタじゃないとぉなんてわがままをいってみたりする。あともうちょっとすれば、体がMacの操作体系を受け入れてくれるのかも。(^_^;あれ、でも、Oさんから送られてきたYooEditの操作体系ってなんかWordStarの色が入っているような…。(^_^;
裁量労働に関する説明会があった。残業とか功績に関する人事、経営の方針は分かるんだけど、私はそんなに残業をしている訳でもない。(うちの会社の時間管理は月何時間働いたという管理。だから気分の乗らない時にはさっさと帰ることにしている。)査定もよくこれでクビにならないもんだという低空飛行状態なので(^_^;、ちょっとやそっとルールをいじったからといって、メリットもあまりなければデメリットもあまりないという状態。2時間も付き合わされたが、どれだけ意味があったのかは疑問。
あいかわらず、Macのお勉強は1日50ページほどしか進まない。今日はRezというコマンドを使って、テキスト形式のリソース(Windowsでいう所の*.rcファイル)をプロジェクトに取り込めるようなリソース形式(Windowsでいう所のコンパイル済みリソースファイル*.resファイル)に変換するというのをやってみた。ところが、これがちっともコンパイルに成功しない。エラーメッセージを見ても所々に変なカタカナが入っていて意味不明だし(多分英語環境だったらまともな文字が表示されるんだろう)、参考書をいくら穴のあくほど眺めてみても、どこにも入力し間違いは見つからないし、テキスト形式のリソースファイルの文法はどこを探しても見つからない。DeRezという逆コンパイラを使ってリソース文の形式のヒントでもつかもうと思ったが、やってみたら個々のリソースの内容は、単に16進ダンプをするだけだったのでさっぱり役に立たない。完全に行き詰まってしまう。
仕方がないので、コンパイルできないところはコメントアウトしてからコンパイルし、コンパイル済みリソースをいじるツールResEditを使ってコメントアウトした部分を追加する。もっともテキスト形式のリソース文の文法が分からないのだから、追加するといっても「多分この意味はこんなことなんだろう」と想像しながら作業を進めていく訳で、やっていて気分の晴れない面がある。
勘弁してくれよなぁと思ったのがリソースをソースファイルから参照する時。VC++だと、例えば文字列リソースを作ったら、統合開発環境が勝手に「IDS_123456」なんてシンボルを割り振ってくれて(もちろん、そのシンボルの名前じゃ訳がわからないので適当な名称に変更するのだが)、そのシンボルに対応する数値も自動的に決まる。で、そのシンボルと対応する数値は、普通resource.hというファイルに#defineうんちゃらかんちゃらという形式で自動的に書き込まれるから、普通はそのヘッダファイルさえ取り込んでおけば、実際にどの値が割り振られているかなんてのはあまり気にしなくてすむし、割り振られた数字をいじりたい時にはリソースエディタをいじれば、その変更が自動的にresource.hに書き込まれるから、リソースエディタで集中管理できる訳だ。
ところがMacのCodeWarriorではなまじリソースエディタが独立したプログラムになっているおかげで、その#defineうんちゃらかんちゃらというのをプログラマーが自分で書かなくちゃいけない。リソースの番号を変えたら、それに合わせて自分でリソースの対応を書いたファイルを書き換えなくちゃいけないんである。VC++でいつも書いていたから、「なんでこっちはこんなに面倒なことをしなくちゃいけないんだろう」とついつい愚痴が出てしまう。まあ、ツールの使い方を間違えているせいなのかもしれないが…。
ソースプログラムを読んでいても訳が分からなくなることがしばしば起こる。noErrとかeveryeventなんていうのが出てくるので、ぱっと見た時に定数か変数なのかさっぱり分からない。もっとも最近定義された定数には、kというプリフィックスが付いているのでかなり分かりやすくなった。また定数にしろ、構造体にしろ、その名前をキーにして探せない(探すやり方が分からない)ので、初めて出会う構造体やその中で使われる定数については、あっちを引っ掻き回し、こっちを引っ掻き回しで、能率が上がらないことはなはだしい。そう考えるとWindowsの開発環境ってのはよく出来ているんだなぁと今さらながらに実感する。
あと、変数の型の命名方も気になった。unsigned char がUInt8だっていうのに、なんでunsigned char *がUInt8PtrじゃなくてBytePtrなの?で、signed char *がPtr、ところがint *も、unsigned int *も、MacType.hを見る限り、定義されていない。APIのエラーメッセージの定義で、APIの成功を示すシンボル「noErr」がMacType.hで定義されていたけど、普通はエラーメッセージ関連のヘッダーファイルで定義するってもんじゃないの?
Macのメモリ管理について。Overviewには書いていなかったようだが、メモリ関連のドキュメントを読んでいったら、ヒープとスタックの総量についてはあらかじめユーザーなりプログラマーが決定しなければいけないのだが、それらのメモリとは別に「テンポラリ」としてシステムにメモリを要求できるらしい。そりゃそうだろうなぁ。あらかじめ使うメモリの総量(もしくは上限)が分かっていないとプログラムを書けないなんてあんまりだもんな。ま、ちゃんとシステムにメモリを要求しているのかはコンパイラ次第なんだけど、駄目なら駄目で「コンパイラがバカだから、要求仕様を満たせません」とか言い訳…できんか。(^_^;でも今時いつメモリをロックして云々なんてことをやりたくないなぁ。
CTypedPtrArrayの代わりにSTLを使えばいいということをいわれた。あれ?STLっていつC++の標準になったんだ?(^_^;ってStandardが付いているからには、標準仕様なんだろうけど、あれってまだFinal Draftじゃなかったっけ?←ちゃんと情報を追っかけていない奴。(^_^;でもいまいちテンプレートって使う気になれない。理由としては、テンプレート機能は新しい(といってもこの業界単位で計算すればそんなに古い訳じゃないが)機能だけに本当にちゃんと動くのか?という心配があるのが1つ。テンプレートはコンパイラが無名の関数を無数に作り出すというので、デバッグが大変そうというのが2つめ。ま、標準テンプレートといわれるくらいのものは沢山の人に使いこまれていることが期待できるから、内部まで追っかけないと分からないなんてことはあり得ないとは思うけど、コンパイラのバグがからんできたら、どうなるか分かったもんじゃない。もう1つ、STLを使ってのプログラミングに関して書いてある本(もしくはサンプル)を見つけられなくて、どう書いていいのかよく分からない。多分最後の理由が私が標準テンプレートを使うのをためらっている最大の理由だろう。←単なる勉強不足という話がある。(^_^;
金曜日に買っておいた「プライベートライアン」の単行本を読む。これもばりばり人が死ぬ話だ。(^_^;基本的にはノルマンディー上陸作戦を描いたものなんだけど、上陸する時に中隊の2/3ほどがあっさり死んでしまうし、ラストになってくると主要な登場人物は数えるほどしか生き残っていない。普通これだけの損害が出ると、指揮系統がずたずたになってしまって、戦闘を継続するどころの話ではなくなってくるので、現代戦の常識としてはいったん撤退をすべきなのだが、この本ではそこから攻撃を始めるんだもんな。無茶というか、昔の人は偉かったというか。(^_^;
最初題名の「プライベート」というのが何の意味か分からなかったのだが、辞書を引いてみたら2等兵、もしくは兵卒のことをこう言うらしい。「ライアン」は人の名前だから、全部日本語に訳すと「ライアン2等兵」となる。けげ、なんだかいきなりかっこ悪いタイトルに思えてくるなぁ。(^_^;
グランツーリスモ。知らないうちに追加ステージが選択できるようになっていた。わくわくしながらそのステージを選択したのだが、どうやら画面がきれいになるってだけみたい。ちょっとがっかり。サルのようにやりまくったおかげでノーマルカーレースでは総合3位、チューンカーレースでは総合2位まで順位をあげた。しかし、1位の車が死ぬほど速いのでとてもじゃないけど1位を取れる気がしない。きっちりライン取りをしていても、後ろからがんがん追突してくるわ、車をぶつけて横からコースを強引に取りにくるわで、なかなかうまいことブロック出来ない。なんかトップ争いをしている間に「ぶっ壊しレース」をやっているような気分になってきた。(^_^;
午後にのそのそ起きてきて、会社においてきたスクーターを取りに行く。どうせ家にいてもそんなにやることがないので、数時間ほどMacのドキュメントを読んでから帰宅。家に帰ったあとはお決まりのグランツーリスモ。コンピューターカーのコーナリングの速さにはどうしてもついていけない…。
OEM関連作業の打ち上げ。OEM作業に関しては大したことはやっていない、というか私はほとんどノータッチだけど、お呼びがかかる。他にもサポート関連、営業関連の人を呼んでの宴会。実は今日は別の部署でも打ち上げの宴会があって、営業のHさんはかけもちだったそうな。お疲れさま。(^_^;
Mac。今のところの目標はひたすら失敗を重ねて、Macの開発に慣れるということに尽きる。しかし、なんかやたらとハードディスクをかりかりアクセスにしに行くのは止めてほしい。統合開発環境を立ち上げて、2〜3分くらいはかりかりハードディスクから音がするんだものな。Sさんに言わせると、32Mbyteじゃやっぱり足りないらしい。上司のNさんに交渉したら、とりあえず見積もりだけ取って見ろといわれる。さて、一気に100Mbyte以上の増設を狙ってみるか。(^_^;
とりあえず参考書を読んで、サンプルプログラムを打ち込んで、ドキュメントを読んでAPIを理解し、デバッガで動かしてみて動作を確かめて、という作業をする。サンプルプログラム自体は、「DOSのテキスト形式をMac形式のテキストに変換する」という、こんなのWindowsだったらかなり凝っても2日とかからないぜ、というプログラムなのだが、なにせ初めての事ばかりで、3日目でやっとDrag & Dropの辺りの処理にたどり着く。ざっと参考書を読む限りにおいては、Macの方が Drag & Dropの処理は易しいような感じ。
で、色々あったのだが、それは結構話が広がりそうなので、「どつぼの記録」のネタとして取っておくことにする。う〜む、あっちの最終更新は3月かぁ。そろそろ更新しなければいけないもんな。(^_^;
たまには映画もいいだろうという訳で、某Nさんがお薦めの「スプリガン」を見に行く。で、映画の始まる時間をチェックせずにいったので、次の上映開始時刻まで1時間半ほどあった。しゃあないということで、映画館の近所をぶらぶら歩く。神社の木が倒されていたのにはびっくり。そうか、台風ってそんなにすごい風だったのか。昨日会社から帰る時はちょうど風が吹きやんでいた時だったので、大したことがないと思っていた。(^_^;
で、肝心の映画。まあつまらないということはなかったんだけど、絵の雰囲気が原作とかなり違っていて、登場人物の顔がずいぶんほっそりしているような感じがする。もちろん原作とどちらがいいかなんて好みの問題だと思うけど、私は原作のほうのタッチのほうが好きだし、前半はその絵が気になってなかなかのめり込めなかった。
あともう1つのめり込めなかった理由が脚本。なんというか設定を詰め込みすぎているような気がするし、話のまとめ方もあまりいいとは思えなかった。主人公が戦闘マシンになっちゃう設定、そのバックグランドなんかはこの映画で取り上げたエピソードとは直接関係がないんだから、ばっさり削ってしまってもいいと思う。ファットマンと主人公のしがらみというこの映画での新設定(原作では主人公の元上官は別人)もいらない。ファットマンが主人公をつけ狙う動機としては、単に裏の世界での有名人と対決して世界最強を証明したいとかとしたほうが、あっさりして分かりやすいし、話もまとめやすい。他にも主人公が新しいアイテムを受けとる所なんかもばっさりカットして、最初からそれらのアイテムをもっているという設定にしてしまう。で、主人公は最初からオリハルコンスーツ全開でばりばり暴れまくることにする。どうせ、一回主人公の戦力分析会議を敵がしている場面があるのだから、そこで全部説明してしまえばいい。
そうすると、いらないカットがずいぶん出てくるから、その時間で主人公が一般社会との接点である学校生活を大切にしていることを示すような軽いエピソードを1つ入れて、マクドガルとの対決でそれをからませれば、主人公の表と裏、戦う目的なんてのも説明できて、「神」と「人間」というマクドガルとの対立点が一層くっきりするはずだ。
訳が分からん設定も気になった。特に気になったのが、いきなりグニョグニョ伸びだすマクドガルの頭から伸びているケーブルとか、ラストシーンでいきなり都合よく飛んでいるヘリコプターとか。特にラストシーンのあの主人公の助かり方はないぞ。大体、その前のマクドガルとの対決で左腕は折れているはずなのに、そんな腕で自分の体重とジャンの体重を支えるんじゃない。普通腕がもげるぞ。(^_^;
まあ、原作を読んでいれば楽しめるけれど、一品料理としてはちょっとなんだかあれだなぁという気がした作品。ま、私自身はそこそこ楽しめたのでよかったと思う。(さんざんけなしておいて、結局それかい。(^_^;)
Mac。やっぱりキーボードに慣れない。PCの時のクセで、どうしてもキーボードの特記に人差し指を合わせてしまって、入力しはじめてから「なんだこりゃ?」というパターンが多い。記号関係は二回に一回程度は一発で入力できるようになったのだが、やっぱり記号の位置を頭で思い浮かべながら指を動かしているので、入力スピードはめちゃめちゃに遅い。で、そんな状態にいらついて、更に遅くなって、ストレスがたまるという…。蟻地獄状態。ま、少しずつタイプスピードは早くはなっているんだけどね。
参考書に書いてあるサンプルプログラムを入力してプログラムの動作を確かめていっているのだが、そこに書いてあるAPIのリファレンスが見当たらない。HDDの中を探してみたのだが、それっぽいドキュメントが見当たらない。Macの師匠Sさんに聞いてみると、CodeWorriorのリファレンスのうち、QuickView形式のファイルをインストールすれば入っているはずだという。それってインストールしたはずなんだけど、インストールに失敗したのかなぁと思って、もう一度CodeWarriorのインストールをやり直す。まあ、インストールの最中にサンプルプログラムの入力でも済ませようと思ったら、Macはプリエンピティブなマルチタスクじゃないので、インストールの間何もできない。仕方がないのでその間はMac関連のドキュメントをWindows95マシンで読んでいた。
で、インストールをやり直してみたが、やっぱりその手のAPIリファレンスが見当たらない。で、再び帰宅直前のSさんに頼んで調べてもらうが、やっぱりインストールされていなかったみたい。結局Appleから提供されていたCD-ROMの中にAPIリファレンスが入っていた。Sさんにそれをインストールしてもらって、なんとかAPIのオンラインドキュメントを読むことができるようになった。多謝>Sさん
で、そのオンラインドキュメントを引きながらサンプルプログラムを読み進めていく。が、そのAPI(MacだとToolBox関数と言った方がいいのか?)リファレンスがカテゴリー別に別々のファイルになっていて、こっちはMac初心者だから調べようと思ったAPIがどのカテゴリーに属するのか知らないのであっちのカテゴリー、こっちのカテゴリーと放浪する羽目になる。で、さんざん調べようと思ったAPIが揚げ句の果てにMacのToolBox関数じゃないらしいと分かった時にはかなりがっかり。こんな既存のAPIを調べるのなんてWindowsでVC++だったらキーワードサーチ一発で済むはずなのに。
Mac関連の技術資料はInside Macintoshが決定版だというので、取り合えずそれをAppleのデベロッパーサイトからダウンロードしてみた。結構量があるけれど、全部PDF。1つのカテゴリー(メモリだとか、ダイアログだとかのトピック別で、大体30カテゴリーくらいある)について書いてある各々の章(1つのカテゴリーに大体10個程度の章がある)がまたまた別のPDFファイルになっている。これじゃあ、キーワードでドキュメント全体をクエリーするなんて不可能に近い。せめて単なるテキストファイルだったらGrepとかが使えそうなんだけど、PDF形式じゃなぁ。あまけにMacはこの手のいくつかのファイルに対してまとめて何かをやるというようなバッチ的な処理はからきし苦手だと来ている。Apple Scriptとかを使えば何とかなるのかもしれないけど、沢山あるPDF形式に対してクエリーをかけるなんてちょっと出来ないと思うんだけど。エキスパートになればその辺のやり方も分かってくるのかな?まあ、Macを始めて3日目じゃ、分からないことも多いからそのうちやり方を学んでいくことになるのだろう。
で、APIの調べ方を調べる/インストールする作業だけでほとんど一日が終る。読んでいる/入力しているサンプルアプリケーションはMS-DOS形式のテキストをMac形式のテキストにするというプログラムなのだが、このプログラム自体はなんとかコンパイラエラーを除去したら動くようになった。動作もそれほど難しいものではなかったので、細かいAPIの動作とかは別にして、大雑把な構造は理解した。まあ、Macをいじりはじめて3日目だとしたら上出来かな。(^_^;
で、Macのドキュメントとかを読んでいると、Macが基本的にはPascalでプログラムを書くことを強く意識していることが分かる。例えばInside Macなんかの例題プログラムとか、関数の説明の説明は全部Pascal構文だ。こんな所で昔勉強したぱすかるの知識が役に立ったと喜ぶべきなのか、今更そんな知識を掘り起こさなければいけないほど窮地に立たされているのだとがっかりすべきなのだろうかよく分からないが、今時Pascalで書いている奴なんて(もしくはPascalを理解する奴なんて)そんなにいないんじゃないのか?それだったら、Microsoftみたいに、そこら辺をヘッダーファイルなどでちゃんと吸収して(実はWindowsAPIも基本的にはPascal方式のI/Fなのだ)ドキュメントはCスタイルで書いた方がよっぽど分かりやすいのに。(-_-;まぁ、私の場合にはたまたまPascalも知っていたから何とかなったけど、今時のプログラマーなんてPascal構文でサンプルプログラムを書かれても分かんないんじゃないのか?だから、その点では(Pascal構文でドキュメントを書く)Appleより(無理やりにでもC/C++構文でドキュメントを書く)Microsoftのほうが絶対実利に則していると思う。大体Cユーザー/Pascalユーザーの比率を考えたらドキュメントくらいC/C++ベースで書きそうなものだろうが。やっぱりAppleってユーザーとかデベロッパーが見えてないんだろうね。なお、誤解のないようにいっておくと、CとPascal、どっちが好きかといわれれば、若干Pascalのほうが好きなのだ。
参考書を見ていたら、
という表現をしている所があった。ふ〜む、Macのプログラムというのは私には想像もつかないことを要求するらしい。(^_^;これってfoo(&**AHandle)
と何がどう違うんだろうか?私にはさっぱり理解出来ない。foo(*AHandle)
あと不思議に思ったのが、型に関するaliasを全然使っていないこと。普通Cコンパイラだとshortが16bitだというのは保証されない(少なくとも16bitというのは大体あてはまるけど、きっちり16bitというのは保証されない。)からWindowsプログラムにおいてはWORDとかの型に関するaliasを宣言しておいてそれを使うという風になっているのだが、そこが結構いい加減。64bitプロセッサ環境でshortといったら32bitかも知れないのに結構無頓着に使っているような気がする。本が悪いせいかなぁ。でも単に何にも考えていないっていうのが正解のような気がする。でもこれでちゃんとプログラムを組んでいる人達がいるし、熱狂的なファンも多いんだよなぁ。Macプログラミングというのは不思議な世界である。
家に帰ってから、Inside Macintosh Overviewのメモリに関する項目を読んだ。メモリのフラグメントがどうのこうのといっていて、なんかメモリ管理に関する限りWindows3.1の世界に舞い戻ったような感触を受ける。そのドキュメントを読む限りではアプリケーションが使えるメモリ総量はあらかじめ決まっているらしい。まあ、ちゃんと仮想記憶のマジックで使えるメモリ量は実質的に上限がないんだろうけど、こんな記述があると不安感がつのる。大体C++に代表されるオブジェクトプログラミングで、メモリがロックされたとかされていないとか意識してプログラムを組めという方が無理だぞ。(^_^;
そういえば、私の書いたExcelファイルに出力するプログラム、思いっきりMFC(CtypedPtrArray)に依存しているんだけど、あれは書き直しになるのかなぁ。勘弁してほしいよ。ま、それ相当のライブラリを用意するのが正解だろうけど、面倒な話だ。
Mac。キーボードがUSなので、金曜日にやった時にはキーボードを見ながらやっていたのだが、意を決してなるべくキーボードを見ないでタイピングするように心がけてみる。まあ、違いといってもアルファベットとかは余り違いがないので、どうということはないが、Cなんかで良く使う記号の位置が違うので結構いらいらする。特に\。106キーボードの大きいEnterキーを使っている感覚で操作していると、\とEnterキーを押し間違えてしまう。(^_^;「え〜とこのキーはあそこにあったはず」などと手探りでキーを押しながら、さんざんタイプミスをしたのだが、今日一日で結構指が慣れてきたように思う。まあ、JISキーボードのほうが私はいいのだけれど、課の予算が少ない現状では買ってくれとも気軽に頼めないし。(^_^;本当はもうちょっとスペースキーの感触が軽い方が好きなんだけれど…。
はまってしまったのがエディタ。YooEditorというのがインストールされていたので、それを使ってみたのだが、多分Mac初心者だからだろう。とにかくコマンドが分からない。(^_^;カーソルを上下左右に動かす、backspaceなどの基本操作のほか、カット&ペーストなど、メニューにある項目はすぐに理解できたのだが、文字のdelete、一単語前後にカーソル移動とかちょっと凝った操作になると全然分からない。ヘルプもバルーンヘルプはあるんだけど、ドキュメントがないからさっぱりキーバインディングが分からない。(;_;)
Macの師匠Sさんに聞いてみたら、大体どのソフトでもキーバインディングは同じだから、そんなものはつける必要がないからないのじゃないか?という話。じゃあ、標準的なキーバインディングに関するドキュメントみたいなのがあるんだろうと聞いてみたところ、「『最初にお読みください』みたいなマニュアルに書いてあるんじゃないの?」と言われた。そこでiMacの添付マニュアルを読んでみたが、それっぽい記述がない。げろげろ、そうすると、カーソルキー移動とbackspace(Sさんに聞いた所、deleteに当たるものは標準では存在しないらしい)、後はメニューにある機能だけしか利用できないのか。
しかしこれだけの操作しか出来ないんだったら、Windowsで言ったらnotepadでソースを書けって言われているのと同じだぞ。(そんなWindowsプログラマーがいたら会ってみたいものだが。)WWWサイトを調べてみたけれど、せいぜいemacsに似せたエディタが見つかったくらい。これじゃあ、本能寺にいる敵ってのは何万行もあるソースファイルだってのに、B-29に竹槍で立ち向かうようなもんだな、と思って悲しくなる。WindowsとかPC-UNIXとかで柔軟なカスタマイズと柔軟なマクロ、キーバインディングの変更は出来て当たり前、なんて世界とはずいぶん違うので、よっぽどソースファイルなどのテキスト編集はWindowsでやってしまおうかとも思ったが、MacのI/Fを理解するまではとりあえず我慢することにする。
で、もうエディタ関連に関しては「Macってのは開発者には(少なくとも最初は)つらい環境なのだ」とあきらめることにして、Macのサンプルプログラムを入力して、それを動かしてみて動作を理解することに勤める。動作の理解といっても、今日のところはEditorが思ったとおりに動かないわ、開発環境のCodeWarriorやResEditがばしばしハングアップしてくれて、そのハングアップに引きずられてOS自体もお亡くなりになるわで、全然進まない。大した操作をしている訳じゃないんだけどなぁ。(コントロールオブジェクトのコピー&ペースト程度の操作でOSまで巻き添えにして死ぬか、普通?>ResEdit)
で、お亡くなりになってしまったMacを再起動している間に参考書をぱらぱらめくっていたら、「Macは使うのは易しいけど、開発するのは大変です」と書いてあった。確かにこんな状態じゃ、開発するのは大変だよな。(-_-;妙に納得。
ここまで不安定なシステムってWindowsマシンでも滅多に見たことがないのだが、これは環境依存と言う話もあって、今私がいじっているMacはかなり不安定なマシンらしい。そんな訳で来週にはきれいさっぱりハードディスクをフォーマットして、OSを入れ直してしまおうと思う。フォルダを詳細表示にするとスクロールバーを叩くだけでハードディスクにかりかりアクセスしにいって、しばらく帰って来ないなんてのは堪え切れない。(^_^;いくら熱心なMac信者でも、あのマシンをいじったら改心するに違いないなどと妄想する。ま、不安定なWindowsマシンを使う羽目に陥ったMacユーザだったら「いくら熱心なWindows信者でも、あのマシンをいじったら改心するに違いない」というに違いないが。(^_^;(だからやっぱりLinuxって選択肢がぁ…。)
で、家に帰ってPowerPCのマニュアルを読んでいる。っぱりアセンブラの知識がないと、いざとなった時に困るような気がしてならないのね。なんだかんだといってちゃんとやっている姿勢が偉いなぁ、と自分でいうあたりが全然偉くない。(笑)
グランツーリスモ。念願のIA-7をサルのようにやりつづけて、やっと通過。早速国際A級ライセンスにチャレンジする。ところが3〜4回チャレンジしたらあっさりと合格してしまった。IA-7があれだけ大変だったから、最終試験はどんなに大変かと思っていたので、かえって拍子抜けしてしまう。
とりあえず、国別対抗レースがまだだったので、それをクリアーしてしまう。こっちの方も今までなかなか勝てなかったのだが、ひたすら簡単なレースを消化してレーシングチューンをしたら、あっさり勝ててしまう。ちょっとは腕も上がったのもあるのだろうけど、やっぱり車をチューンアップするのが勝利への近道ってことだろう。ストレートで伸びがコンピュータカーと全然違ったもんね。(^_^;
国別対抗レースで儲けた賞金でNSXを買って、ノーマルカーレースに挑戦したら、コンピューターカーのコーナリングスピードの速いこと、速いこと。ハイスピードサーキットでは何とかいい勝負程度には持っていけるのだけれど、他のコースでは全然追いつけない。(^_^;それでは、というわけでワールドカップリーグに挑戦してみたら、こっちは案外あっさりと優勝できた。で、何とかめでたくエンディングを迎えることができた。
まだやっていないのが、耐久レース関連だけだったので、それに挑戦してみる。案の定予選は最下位だった。で、いよいよ本戦がスタート。で、画面表示を見たら周回数が60周と出ている。このコースは大体1周1分40〜42秒程度のペースだから…、ええ、このレースが終るまで1時間40分以上もかかるの!?そんなのやってられるか。(^_^;
といいつつ、やっては見たのだが、周回数20周ほどで飽きてきた。もっとも変な所ですピントかを繰り返して、先頭から離されすぎてやる気が失せたというのもあるが。全部のステージをクリアーすると追加ステージが見られるという話を聞いたことがあるのだがこれはいつになったら見られるか分からんな。(^_^;
Mac関連の雑誌「MACLIFE」を買ってきて読んでみる。まあ、今のコンピュータ雑誌はほとんどそうだけど、製品紹介がほとんどなので、何を買っても同じだろうと思ったけど、付録のCD-ROMにオンラインソフトが沢山収録されていたのと、これが一番広告が多そうだったので買ってみた。
その中にMacOS搭載現行機種一覧というのがあって、それを見ると、ディスクトップでPowerPC233Mhz、メモリ32Mbyte、HDD4Gbyteで、18万円近くする。これにディスプレイなどをくっつけたら、実質25万円位か。iMacはディスプレイ込みで17万円台だけど、今更15インチのモニタじゃつまんないしなぁ。互換機メーカとかがあればもっと安くなると思うんだけど、Appleが互換機メーカーをMacOS8のライセンスを与えないと言う形で、事実上締め出しちゃたし。互換機メーカーがない、自作で安いマシンを調達できないってのがMacで一番つまらない所だよな。
で、雑誌を読んでいても手元に使えるマシンがないので読んでもあまり面白くない。ま、これはMac専門雑誌でたまたま「MACLIFE」はつまらない雑誌なのか、「MACLIFE」の私が買った時のが面白くないのかは分からない。もっとも今のコンピュータ雑誌で何か面白いものを探す方が大変かもしれないが。(^_^;
Excel形式のコーディング作業が一段落したので、もう一度ソース全体をざっと見て、コメントなどを入れておく。手を入れられそうな所とか、もっと早くなりそうな部分は結構あったのだが、それはβレベルになってから考えても遅くはないだろう。直すとしたら、Excel形式の表を出力するクラスのメソッドが50以上にもなって結構醜くなってきたところから手をつけるんだろうけど、うまいことクラス分けが出来そうもない。
で、その作業にケリを付けたあと、一般的な表の表現形式というものを考えてみた。私の担当部分は、画像データを文字認識した結果をファイルなどに出力する部分なのだが、今まではA形式で出力するから、認識データをこんなふうに評価する、B形式で出力するから認識データをこんなふうに評価するという風にやっていた。バージョンが上がれば当然認識データの形式も変わるので、これまでの方法だと出力プログラムに相当手を入れなければいけなくなる。こんなことはやっていられないので、いったん何かの中間言語的な形式に認識データを変換して、出力プログラム自体はその中間言語から色々な形式に変換するようにすれば、認識データの形式が変わった時でも中間言語的な形式に変換する部分だけを修正すればよい。ただ、いきなり全部は無理なので、とりあえず手が付けやすいと思われる表の中間言語的表現を考えていた訳だ。
まあ、どうせ認識した結果なんてのはモノクロ画像だし、表に限って言えば、線と文字だけしかないと限定してしまってもいいので、簡単だろうと思った。が、よくよく考えてみると
+-------+
| B |
+ A +---+
| | C |
+---+---+
まあ、ちょっと頭を冷やしてもうちょっと考えてみよう。で、ふと隣のパーティションを見たら、Macが空いている。丁度いいという訳で、以前から懸案だったMacのお勉強を始めることにした。お勉強といっても私はほとんどMacをいじったことがないので、プログラムのお勉強を始める前にMacの操作方法を知っておく必要がある。まあ、ファイルのコピーとかエイリアスの作り方などはある程度Windows95と似ている(というか、こっちが本家か)ので大して戸惑わなかった。ま、MacOSのヘルプとかを見ながら、あれこれやっていた。
じゃあ何かテキストファイルでも作ってみようと思って、アップルメニューを開いたら、「ノートパット」というアプリケーションが目についたのでとりあえずそれを起動してみる。なんだか偉く小さいウィンドウだなぁ、と思ったが、「this is test」という文を入力してファイルメニューを開いてみると、なんかセーブが出来るような項目が見つからない。(?_? まあ、終了すればセーブするかどうかくらいは聞いてくるだろうと思い、終了コマンドを選択してみたら、いきなり終ってしまう。あれれ?
色々やってみて分かったのだが、テキストファイルを作ったりするのには「simple text」というツールを使うらしい。「ノートパット」はどちらかと言えば付箋紙的に使うものらしい。ふ〜む。
日本語入力も結構戸惑った。メニューを見るとひらがな/カタカナ/英数の切り替えは何かのキーコンビネーションで切り替えられるらしいのだが、いかんせんそのコンビネーションが分からない。(^_^;何かアルファベットの前に2つほど変な記号が書いてあるのだが、キーボードをいくら見つめても、その変な記号が見当たらない。試しにコマンドキーとかOptionキーとかの組み合わせを試してみたのだが、どうにも変わらないし。どうにも分からないので、社内のマックユーザーに聞いてみた所、「ああ、それはCTRL+SHIFTの組み合わせだ。Helpを見れば書いてあったのに。」と言われる。昔のキーボードにはCTRLキーとSHIFTキーにそのシンボルが書いてあったんだそうだ。そんなもの、今日始めたばっかりの奴には分からないぞ。(^_^;まあ、そこをクリアーしたら何とか日本語は入力できるようになったので、大満足。
ついでにCodeWarriorも入れて、ちょっとだけ簡単なプログラムをしてみることにした。最初はやっぱりHello.cしかない訳で(^_^;、それくらいなら結構簡単にできるんじゃないかと思っていたのだが、リンクするライブラリがどうのこうのとかという所でまたはまってしまう。(^_^;色々試しているうちにMacのシステムデバッガ画面にいってしまって回復手段が全然分からず、電源スイッチをおしてもなんにも反応しないしで、大いにあせる。なんとかヘルプをたよりに元の画面に戻れたので、ほっとした。なんだかんだで紆余曲折はあったが、何とか今日一日かけて、自力でHelloプログラムを書いて動かす所まで行ったので良かった、良かった。(^_^;
しかし、私のいじったMacって180Mhz、メモリ32MbyteのマシンなんだけどなんだかやたらとHDにアクセスにいくような気がする。ファインダーを一覧表示にしてスクロールさせるたびにHDにかりかりアクセスにいくので、遅いったらありゃしない。これだったら私の自宅のWindows95マシンのほうがよっぽどきびきび動いているような気がする。これって単にマシン依存なんだろうか?それともMacOSってこれだけ重いものなんだろうか?やっぱりG3マシンじゃないと遅いのかなぁ。
さて、明日はMac関係の本を探しにパソコンショップ巡りでもして見るか。
出勤途中、スクーターに乗ってぼ〜と信号待ちをしていたら、前に止まっている車に載っている2〜4才くらいの子供と目があった。すかさず、ブイサインをして答えてあげたら、車の中できゃっきゃいって喜んでいた。なんだか、そんな姿を見ているだけでこっちもうれしくなってくる。で、調子に乗って「イナイイナイバ〜」、「バイバイ」とかやっていたら、これも結構喜んでもらえたらしい。子供らしい単純といえば単純な反応なのだが(^_^;、そんな光景もたまには悪くない。
Excel97形式。簡単なサンプル程度のファイルを出力できるようにはなっていたのだが、罫線データやセルの縦横幅を変えたりするなどの機能がうまくいっているか調べた。縦横幅を変えたりするのは全く問題がないようだったが、罫線データがうまく出力されていない。あれれ?と思って、該当するソース部分を調べたら、BIFF8形式対応のコーディングがされていなかった。そういえばこの部分は「とりあえずExcel97で読めるようなファイルを出力してから取り掛かろう」と思っていたんだっけ。(^_^;これまでの作業である程度はお膳立てをしてあったので、追加コーディングは10行ほどで済んだ。OK、OK。
あと、とりあえず残っている中で一番でかいのは、ブックの中にデータが沢山ある場合に必須となるCONTINUEレコードに関する処理だ。実はExcelのレコード構造というのは1レコードの大きさが2040バイト以内と決まっているので、もし1つのレコードにそれ以上のデータを入れなければならない時には、このCONTINUEレコードというのを使ってレコードのデータ領域を拡張する。ところが、そのレコードをどこでぶった切るかというのが、「CONTINUEレコードの直前のレコードにとって自然なもの」と決められているので、その境界条件がレコードごとにばらばらなのだ。要するに、3000バイト出力しなきゃいけないから、最初のレコードを2040バイト出力して、あとの960バイトをCONTINUEブロックで出力すればいいなんて簡単な話ではないのである。もちろん、レコードの中に入っているデータも可変長データがあるので、nバイト境界なんてのも成り立たない。
まあ、完全に汎用の一般レコード+CONTINUEレコード群を出力するようにプログラムを書くのも出来るのだが(実現方法を考えつく程度ならCの初級程度の練習問題かな?)、デバッグが面倒になりそう。第一、CONTINUEレコードを処理しなくちゃいけないのはSSTレコードだけのようなので、それだけのコスト(といっても+1時間程度でコーディング+初期debug位は何とかなるけどね)をかけるのに意味があるのかはかなり疑問。そんな訳でCONTINUEレコード処理ルーチンはSSTレコードをうまく処理できるように特化することにした。ただ、特化するといってもある程度拡張することは意識して書いたので、拡張しやすくはなっているはず。
こんな場合には、ある程度拡張することを意識して書いておいて、本当に拡張が必要になった時に対処した方がコスト的には見合ったものになる事が多い。C++のテンプレートとかもそうだが、自分の思いつく限りの汎用性を追求したら、それはそれで大変な作業になるので、まあ今回は妥当な対処かなってテンプレートプログラミングを出来ないことを言い訳している奴。(^_^;まあ、テンプレート関数って、ドツボにはまりそうな所がそこかしこに転がっていそうな気がするから、あんまり自分では作りたくないってのが本音だけど。(^_^;
そんな訳でコーディングを進めていったが、書いているうちに、SSTレコード出力関係の関数がSSTレコードに含むべき情報を処理する部分とUNICODE関連の処理をする部分がごちゃごちゃしてきて、かなりの長さ(80行超)になった。うむむ、とじっとソースを見直して、SSTレコード処理部分とUNICODE処理部分を別の関数に分離して修正してみたら、思った以上に見通しがすっきりして、1つ1つの関数も分かりやすくなったので、吉。(^_^
懸案だったBlankレコードに対する処理も案外簡単にカタが着いたので、これで大雑把に言って一通りは終ったかな。後は、こっちの想定していないビットパターンが出て来ないのを祈るのみ。こればっかりはドキュメントに書いていないから、違うバージョンを全部インストールしてみて、どのような挙動を示すか調べなくちゃいけないが、今のところそこまではしなくてもいいだろう。
ある程度書き上げた所で、英会話のレッスン(レッスン料は会社持ち(^_^;で、社内に講師が来てレッスンをしてくれる。)の時間になった。このレッスンに参加しているのは10人程度いるはずなのだが、大体常連は私を含めて3人ほど。で、今日はその常連のIさんが多忙、Mさんがお休み、他のメンバーも多忙ということで、私と講師のワンツーワンの授業になった。こういうのって苦手だよなぁ。(^_^;いつもだったら、他の人が返答にとまどっている間になんとか講師からの質問の答えをひねり出せるんだけど、今日はめろめろ。(^_^;StarTrek LD BOXを見続けた成果か(^_^;、なんとなく相手が何を言っているのかは分かるんだけど、こっちが言う方がへろへろ。というか、ボキャブラリがないせいで自分の思っていることを素直に英語に表現できないのね。くやしいなぁ。まあ、でも結構馬鹿話なども出来たんじゃないかと思う。ま、たまにはこんなこともあるよね。
英会話のレッスンが終って、自分のパーティションに買える途中で、あるガラス張りの部屋でミーティング中の某氏と偶然にも目が合う。今日の朝のことがあったので、思わずブイサインをしてしまったのだが、その某氏には特に反応は見られなかった。これだから大人のすれっからしは…←普通はそうだって(^_^;。
とりあえず、今日までである程度Excelファイルに出力するモジュールについては適切なパラメータさえ与えてあげれば動くようになった。結構長かったなあ。明日はこのモジュールのI/Fに関するドキュメントをちょろっと書いて、表認識部分の認識を担当している人間に、「これだけのパラメータを送ってくれよ」という前仕様書的な部分を送って、とりあえずこの仕事はいったんケリを付けることにする。さて、その次はMacのオベンキョウじゃ。(^_^;
米マイクロソフトがOffice 97用の最新サービスパックを企業および個人ユーザー向けに無料で公開したらしい。これって、日本でもちゃんと無料になるんだろうか?この前のサービスパックはアメリカでは無料だったけど、日本では有料で「何考えているんだ、バカヤロウ」と思ったのだが、この次も有料だったら「日本人をなめるんじゃねぇ」になるだろうな。
4日ぶりに出社。
会社に来てみると、珍しく郵便物が来ている。何かと思って開けてみたら、某社からのPC-Expoへの無料招待券だった。確かこの会社と私の付き合いって、去年のPC-Expoで名刺と引き換えにパンフレットをもらったというだけだと思うんだけど、既によく憶えていない。(^_^;普通に入ると入場料1000円がかかるはずなんだけど、少なくともコンピュータソフトウェア関連の業種ではこの無料招待券はかなり余っているはず。実際私も今度のPC-Expoの招待券は既に確保しているし、この招待券は無用だ。だから、このページを読んでいる人で欲しい人がいたら、その人に送ってもいい。欲しい人はメールを下さい。とりあえず、500円からかな、なんてね。:-)送料そちら持ち、早い者勝ちで手元に2枚あるので、興味のある人はどうぞ。
4日も休むとメールが沢山たまっている。もっともほとんどが流通量の多いMLからのものだが、数が多いだけにタイトルだけざっと読んでみるのにも結構時間がかかる。ネットニュースにいたっては、ちょっとたまりすぎて読み切れないという感じ。fj.jokes以外は読み飛ばしだな、これは。
なんか最近Excelの話しかしていない。まあそれにかかりっきりというので他に書くネタがないんだけど、このネタってMicrosoftから出ているExcelファイルのフォーマットに関するドキュメントと、ダンプリストを読まないとワケワカメの内容だから、つまんなかったらごめんなさい。多分今週中でExcelファイルにケリが付けられる予定なので、もう少しのご辛抱を。<(_ _)>
BIFF8形式に出力できるような修正作業が続く。金曜日には大してデバッグもしなかったし、ドキュメントに書かれている限り最小限の変更しかしていなかったのでExcelが死んでしまったのだろうと見当は付いていたので、またもやバイナリーレベルでどのへんがどう違うのかを丹念に調べていった。
最初バイナリーレベルで見た時に、フォントの名前もセルのデータもそれっぽい文字列が見当たらなかったので、一瞬あせった。でも何か意味ありげなデータが入っているので、UNICODEじゃないのか?と当たりをつけて、SJISへ変換してみたら、予想通りUNICODEで書かれてあったものと判明した。まあ、その程度はMultiByteToWideChar()一発で済むので大したことじゃないが、BIFF8にUNICODEを埋めこむ時のルールや埋めこみ方がドキュメントに書いてあるのと全然違うので、頭にくる。その程度の事くらいちゃんと書けよ。 >Microsoft あ、私の書くドキュメントよりはよっぽどマシか。(^_^;
仕方がないので、度胸一発、何種類かのファイルのダンプリストとにらめっこをして、意味が分かったフィールドだけちゃんと設定できるようにして、あとはExcel97の出力を真似することにした。各々のフィールドの意味が分かっていれば何とか分かりやすく書く方法もあるのだろうが、意味が分からなければなんともならない。結局マジックナンバーがずらりと並んだテーブルを多用したというプログラムになった。これ、引き継ぎの時に大問題になるだろうなと予想できたので、ある程度作りながらドキュメント(というか、ダンプリストに解析状況を記したメモ)をある程度整理しておくことにする。私が引き継ぎ担当者だったら、こんなプログラムは絶対引き継ぎたくないな。←書いた本人が言うかね、普通。(^_^;
意味不明のフィールドはUNICODE関連だけではなくて、そこかしこにあったのだが、今日の段階ではそれらのフィールドについての解析は後回しにすることにして、とにかく真似っこに徹する。
ショックだったのが、セルの値の格納の仕方が全然変わっていたこと。以前はワークシートストリームのLABELレコードに文字列が格納されていたのだが、BIFF8になってブックストリームのSSTレコードに文字列を格納して、ワークシートストリームではLABELSSTレコードでその参照を格納するという方式になっていた。このロジックの追加作業でかなり時間を取られる。でも、時間がかかった割には、SSTレコード内の重複文字列とか空文字に関する取り扱いにかなりの難がある。が、とりあえずそれはそれで明日以降。また、文字列がSSTレコードに集中するようになった結果、CONTINUEブロックを使ってSSTレコードを拡大できるようにしなくちゃいけないが、そのコーディングも入っていない。ええい、これも明日、明日。
最近にしては珍しく、ちょっと遅くまで仕事をしていたのだが、頑張った甲斐があってなんとか今日中に簡単なサンプル程度のExcel97形式のファイルが出力できるようになった。ふぅ、後もう一息。これで明日Excel95形式のファイルを出力させてみたら、また駄目だとかなったら、嫌になっちゃうかもね。(^_^;