Macintosh Developer Online (MDOnline)

2000年12月21日発行号 - Carbon Eventを使う

歳末大売り出しではありませんが、またまたプレゼントです。やっぱりこの時期はモノが動くのでしょうか。1つ目のプレゼントの写真をぜひともごらんください。家内が近所のドン・キホーテで見つけてきた、「アップルロゴのテープ」です。ガムテープサイズですが、テープの部分の厚みが4mmほどしかないので、長さそれほどはないでしょう。値段は240円で、在庫は3つだけだったそうです。いずれにしても、割高ではありますが、それはアップルロゴの為せる技か？　3つ売っていたうち、2つも買ってきてしまったそうなので、1つをプレゼントに回します。
だけど、そのアップルマークなんですが、りんごの右側は欠けていないし、葉っぱの部分は異なる色で、つまりは7色なんです。だから、良く見れば、Appleのロゴではないという風になっていますが、デザインをした人の意図は見え見えではありますね（笑）。
あと、マイクロソフトの手帳は革風の表紙のもので、ダイアリーになっているものです。カレンダーはCD-ROMケースにもなるもので、金属製のケースみたいです。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝プレゼント
アップルロゴもどき（笑）の幅広テープ（1枚）
figs/photos/DSC10019.jpg
―――――――――――――――――――――
申し込み方法：＜msyk@locus.co.jp＞宛にメールをする
　メールのタイトル：【アップルロゴテープ】を希望

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝プレゼント
マイクロソフトの手帳（2つ/1つは写真撮影のため開封）
figs/photos/DSC10022.jpg （左側）
―――――――――――――――――――――
申し込み方法：＜msyk@locus.co.jp＞宛にメールをする
　メールのタイトル：【マイクロソフトの手帳】を希望

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝プレゼント
マイクロソフトの卓上カレンダー（4つ）
figs/photos/DSC10022.jpg （右側）
―――――――――――――――――――――
申し込み方法：＜msyk@locus.co.jp＞宛にメールをする
　メールのタイトル：【マイクロソフトのカレンダー】を希望

＜共通項目＞
　メールの本文には、名前、住所、郵便番号、当選時の公表名、を記載
　メールは、MDOnlineに登録のメールアドレスから送付してください
　複数のプレゼントを御希望の場合は、それぞれ個別にメールをしてください
　締め切り：2000年12月25日（月）到着分のみ
（新居雅行 msyk@mdonline.jp）

【小池邦人のプログラミング日記】2000/12/20＜Carbon Event Managerを使う　その1＞

最近はADCメンバーサイトのCarbon SDKの更新も停滞ぎみです。まだクリスマス休暇には早いと思うのですが...。気持ち良く年を越すためにも、もうそろそろCarbon SDK v1.2のGM版を出して欲しいところです。今回から数回にわたり、Carbon環境から新しく導入された「Carbon Event Manager」を使う過程を実況中継したいと思います。

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が使われているのかを詳しく見てみることにします。
[小池邦人/オッティモ]

関連リンク：オッティモ
カテゴリ：Carbon/CF, 小池邦人のプログラミング日記

ついに見てしまったMac OS X PBでの“パニック”、Mac OS Xでのフリーズの傾向と対策

安定した堅牢なMac OS X…という能書きは耳にしながらも、どうせ落ちる時には落ちるに決まっているとタカをくくっていた。もちろん、アプリケーションがフリーズ同然になったり、突然御隠れになったりすることはあったが、それでも別のアプリケーションにはほとんど影響はなく、なかなかいいじゃないかと思ってもいたものだったが、本格的なフリーズを意味する「Panic」に出くわしてしまった。そこで思わず記念写真を撮ってしまった（ニホンオオカミじゃないけども…）。

◇これがMac OS X Public BetaのPanic!だ
　

このPanicとは、Mac OS Xのいちばんコアの部分にあたるカーネルでの動作不具合が発生したことを意味する。TILの文書のアドレスは以下に示しておく。アプリケーションのメモリ環境は個別に保護されているために、そこで何が起こっても他には波及しないのであるが、コアとなるカーネルでの動作不具合はやはりマシン全体を落としてしまうのである。写真にあるように、再起動するか続けて行なうかをキー入力するのだが、続けて行なってみてもやっぱりだめで、今度はキー操作は一切受け付けないで、本体のリセットボタンを押さないといけなくなってしまった。

◇Mac OS X Public Beta: What Is a Kernel Panic?
　http://til.info.apple.com/techinfo.nsf/artnum/n106076

◇Mac OS X Public Beta: How to Log a Kernel Panic
　http://til.info.apple.com/techinfo.nsf/artnum/n106079

ちなみに、このパニックは、Mac OS Xを終了しているときに発生した。だから、何が悪影響を発生させたのかはちょっと判断がつかない。そのときは、アプリケーションを1つくらい起動して、ものの10分も使わないで終了させたくらいで、システムを使い込んでの影響ということでもないと思われる。もっとも、普段の使っているときでもマルチタスクOSだけに、パニックが発生しても何が悪いのかはそう簡単には判別できないだろう。

なお、Mac OS Xでフリーズのような状態になると「コマンドライン」に落ちると思われている節もあるが、おそらくまずそんなことはいだろう。アプリケーションレベルで落ちた場合には、単にそのアプリケーションのプロセスがなくなる。つまり、保護メモリの機能が働く範囲では、単にそのプロセスが死ぬだけだ。一方、カーネルレベルだとパニックとなる。Windowsのように、MS-DOSというコマンドラインベースのOSの上でさらに起動をかけて動くような場合にはコマンドラインに落ちることもあるだろうけど、Ver.3.1時代ならともかく今時のバージョンではそれすら見られない。Mac OS Xをはじめ、UNIX系のものは、コマンドラインを実現する機能も、シェルといういわば1つのアプリケーションといったものだから、そこに落ちるということはあり得ないと考えられる。OSのカーネルにコマンドラインのインタプリタのような機能があるといったMS-DOS的なものではないわけだ。

Mac OS Xを使っていて、アプリケーションがフリーズする場合もある。落ちてしまうときれいさっぱりなくなるのだが、落ちないで、さらに応答もしないということもある。その場合には、無理矢理落とすしかないだろう。起動したままだとレスポンスが悪くなるような場合もあるようだ。無理にアプリケーションを落とす場合には、Command+option+escというキー操作を行なう。すると、起動しているアプリケーションの一覧が出てくるので、強制終了させたいものを選択してボタンを押せばよい。Mac OS 9でも同じキー操作で強制終了ができたが、そちらではアクティブなアプリケーションだけだった。Mac OS Xでは落とすアプリケーションを選択する。
また、OSのプロセスレベルでは、たとえばTerminalでコマンドを入れてやるとか、/Application/UtilitesにあるProcess Viewerを使って、指定したプロセスを落とすというようなことも可能である。その場合には、アプリケーションだけでなくバックグランドで動いているものなど何でも落としてしまうことができるが、当然ながら、システムについて詳しくないのであればあまり触らない方がいいだろう。もっとも、その後すくに終了するのであればあまり影響はないかもしれないが、単に再起動をスムーズにさせたいというだけなら、アプリケーションの強制終了でほとんど事は足りると思われる。

キーボードによる強制リセットの機能（Command+control+パワーキー、Command+shift+パワーキー）は、Mac OS Xでも機能する。それで、実際にリセットをして再起動をするようだが、ハードウエア的ないきなりのリセットでもないようだ。というのは、画面を見ていると、少しの時間だが、マウスポインタが虹色になってぐるぐる回っている。つまり、何かの処理をやっているようにも見える。だが、アプリケーションが起動していてもそのまま画面は真っ暗になるので、アプリケーションは強制終了し、カーネルレベルで再起動をかけているくらいじゃないかと思うが、そのあたりは想像だ。Mac OSでは強制リセットを行なう機会も多かったけど、Mac OS Xではそれをやらないといけない場面は少ないと思われる。少なくともDesktopが起動してれば再起動などはできるわけだから、なるべくメニューから選んで終了や再起動を行なうようにすべきだろう。再起動は、Desktopの「特別」メニューをoptionキーを押しながら選択すると、該当する項目が出てくる。optionキーはメニューをたらした後に押してもかまわない。

カテゴリ：Mac OS X

4Dでレーダーチャートを描くプラグインがバージョンアップ

光琳館は、データベースソフトの4th Dimension（4D）で、レーダーチャートを表示するためのプラグイン「RChart.4dx Ver.2.3」のリリースを行なった。WindowsおよびMacintosh版があり、価格は\21,000となっている。
K’s RoomのサイトにVer.2.1からの変更点が記載されており、それによると、関数の追加によって設定のバリエーションを増やしたことや、文字列の埋め込み、サンプルの改良などがなされている。
◇K’s Room
　http://www.ksroom.com/

関連リンク：レーダーチャート作成プラグイン RChart.4dx Ver.2.3
カテゴリ：データベース

REALbasic 3.0a16がリリース、1日おいての矢継ぎ早のリリースアップ

開発ソフトのREALbasic 3.0のアルファ版リリース16が公開されている。リリース15の公開の翌日の公開だ。ソケットを設定した場合にクラッシュするバグや、ツールバー、リストボックスでのバグ修正、長いメソッドを編集する場合のスピードアップなどの修正が加えられている。REALbasic 3.0はCarbon対応で、Mac OS X向けのネイティブアプリケーションを制作できる。

関連リンク：REALbasic 3.0a16
カテゴリ：REALbasic