Carbon Event ManagerはCarbonLib v1.1（このバージョンは世に出ないかも？）からサポートされています。この新しいEventモデルは、今までのようなイベントループによる分岐を使わず、Apple Eventで用いた手法を拡張し、発生したEventを各オブジェクトにリンクさせたEvent Handlerで処理する設計になっています。例えば、ユーザがウィンドウ（オブジェクト）上の、Close Box、Zoom Box、Grow Boxをマウスクリックした時にも、Event Handlerとして登録されているルーチンがその処理を担当します。アプリケーションで利用するオブジェクト（ウィンドウ、メニュー、コントロール）に対するEvent処理を「すべてこの仕組みで統一しましょう！」と言うのが、新モデルの目標です。この新Eventモデルの最大のメリットは、Mac OS Xで起動したCarbonアプリケーションをWaitNextEvent()の呪縛から解放し、そのパフォーマンスを改善することです。また、Carbonアプリケーションを他のプロセスに迷惑をかけない「良い子アプリケーション」に変身させるためにも、ぜひとも実装しておきたい新機能です。
現在（2000年12月20日）Carbon Event Managerを利用するのには、ADCのメンバーサイトから「CarbonLib 1.2f3 SDK」をダウンロードする必要があります。
開発に用いるStubライブラリやUniversal Interfacesは、このSDK内の「Carbon Support」フォルダに入っているバージョンを利用します。ちなみに、現在のUniversal Interfacesの最新バージョンは3.4b1です。現状、Metrowerks CodeWarrior 6とCarbonLib 1.04の環境でソフトを開発をされている方は、そちらの環境と混在すると危険ですので、「Carbon Support」フォルダをそのまま「Metrowerks CodeWarrior」フォルダに入れ、Settingsでプロジェクトのアクセスパスを変更して利用されるのが安全です。その場合には、先んじて「CarbonLibHeadersPreCompiled」フォルダにある「CarbonHeaders.mcp」を使い、Universal Interfaces 3.4b1に対応した新しいPreCompiled Headerを作成しておくと便利です。
続いて、開発の指針となるドキュメントを探してみます。代表的なドキュメントは、以下のApple Carbon Documnetのサイトにある「Introduction to the Carbon Event Manager」と「Carbon Event Manager Preliminary API Reference」です。
◇Apple Carbon Documnet
http://developer.apple.com/techpubs/carbon/oss/CarbonEventManager/carboneventmanager.html
ところが、どちらのドキュメントもほとんど役に立ちません。前者のPDFファイルは、たった5ページしかない貧弱な内容です（涙）。後者はAPIや定数に関するリファレンス的な説明ですが、内容の更新が遅いので、本当に「これ」を信じてよいのか甚だ疑問です。こうした状況は2000年7月ごろからまったく変わっていません。結局このふたつのドキュメントを読むより（まあ、とりあえず読んだ方が良いのですが...）Universal Interfaces 3.4b1に含まれる「CarbonEvents.h」を読んだ方が（？）仕様をより深く理解できるという現実は、まったくもって情けない話しです。
Appleには、Carbon Event Managerに関する正式なドキュメントの早急な配布を強く要望したいと思います。ところで話は変わりますが、CodeWarrior IDEのエディタはコメント文をカラー表示できます。そこで私は、CarbonEvents.hをEPSONのPM-900Cでカラープリントしようとしました。ところが、カラー設定にしておいても何故だかテキストがカラーでプリントアウトされません？どなたか原因をご存じの方、教えていただけると大変に助かります。
最近、参考になるドキュメントがもうひとつだけ増えました。CarbonLib 1.2f3 SDKの「Documentation」フォルダ内にある「Carbon Porting 11/15/00.pdf」です。このCarbon Porting Guideに関しては、そこそこ頻繁に内容がアップデートされており、現在のリビジョン（1/15/00）では99ページから109ページまでがサンプルソースを用いたCarbon Eventの説明となっています。たった10ページしかないのですが、まあ、まったく無いよりましなので参考にしてみてください。こうした貧弱なドキュメントでカバーしきれていない箇所は、結局、サンプルアプリケーションのソースコードを見て自分で補う（推理する）しかありません。旧Event Managerの代わりにCarbon Event Managerを使っているサンプルが、CarbonLib 1.2f3 SDKの「Sample Code」フォルダ内にいくつかあります。現在のSDKでは「BasicCarbEvents」「SimplerText」「BasicDataBrowser」の3つのプロジェクトがそれに相当します。
まずは「BasicCarbEvents」というサンプルプロジェクトのソースコードを見てみます。
名前からして、これが「Carbon Eventのためのサンプル」であることは間違いないでしょう。しかし、ソースを見ると驚くほどシンプルで（笑）とてもサンプルのレベルに達していない気もします。まずはアプリケーションをメイクして動作確認をしてみることにします。CodeWarriorでプロジェクトを起動して、リンクしているライブラリ（CarbonLib）やUniversal Interfacesのパス設定をCarbonLib v1.2対環境へと対応させます。加えて、Mac OS 9.04の機能拡張フォルダ内のCarbonLibを、バージョン1.2の物へと交換しておくことも忘れないでください。さっそくコンパイル＆リンクしてみると、「BasicCarbEvents.r」（このアプリのリソースが定義されているファイル）の中でコンパイルエラーが発生します。調べてみるとBasicCarbEvents.rで使用している「Dialogs.r」で未定義のリソースタイプが使われているようです。
Dialogs.rは「Carbon.r」から呼ばれており、どちらもUniversal Interfacesフォルダ内の「RIncludes」フォルダ内にあります。RIncludesフォルダ内のすべてのファイルを対象にして、未定義だと怒られているリソースタイプを検索してみると、それは「MacWindows.r」に定義されていました。つまり、Carbon.rの中でMacWindows.rを呼ぶ前にDialogs.rを呼んでいるのが原因のようです。ところが詳しく調べてみると、Carbon.rは、ちゃんとDialogs.rの前にMacWindows.rを呼んでいるのです。とすれば、どこか別の場所（ファイル）で先んじてDialogs.rを呼び出しているということになるのですが、これ以上詳しく追求するのは面倒なので、先頭でMacWindows.rを呼ぶようにCarbon.rを作り直してやりました。これでコンパイルエラーは消え、めでたくアプリケーションの完成です。
Appleの連中は古いサンプルを入れておくだけで、それを最新の環境でメイクできるかどうかを確認をしてないわけです。しばしばこういう現象に遭遇すると、「こいつら自分で動かしてないな！」ってことがすぐにバレルわけでして、なんだかとても悲しい気持ちになります（涙）。
次回は、このBasicCarbEventsサンプルで、どのようにCarbon Event Managerが使われているのかを詳しく見てみることにします。
[小池邦人/オッティモ]