Macintosh Developer Online (MDOnline)

2001年4月24日発行号 - REALbasic 3.1正式版へ

5月1日の記者会見は新製品が発表されそうという話が出始めています。だけど、そこで大きな発表があると、WWDCでは何も新しい発表がないとかになってしまいそうで、ちょっと複雑ですね。だけど、発表の内容を受けて、iWeekでは話題沸騰になるかもしれません。ちょうど1週間後になりますが、さてどうなることやら。今日はLaunch Serviceのサンプルプログラム作成で本筋とは関係ないところではまってしまったので、疲れてしまいました（苦笑）、てなわけでこの辺で。
さて、Flash本の当選者は以下の方です。5名の方々の応募がありました。明日、発送の予定です。
Flash5本当選者：船切誠さん
（新居雅行 msyk@mdonline.jp）

小池邦人のプログラミング日記》2001/4/22＜ウィンドウのLive Resizing　その2＞

今回は前回の続きです。「ウィンドウのLive Resizing」を実現しているCarbon Event Handler（Carbon Event処理ルーチン）のソースコードを、より良い形へと書き直しててみます。

まずは、おさらいからです。前回作成したCarbon Event Handlerのソースコードをもう一度見てみます。

　

このソースの「美しくない点」は2箇所ありました。ひとつ目は、ウィンドウのサイズオーバーをCarbon Eventの処理内で逐次チェックしている点です。ViewJPEGアプリのウィンドウには画像が表示されています。マウスドラッグでウィンドウを拡大したとしても、それが画像矩形枠より大きくなることは許されません。画像ウィンドの最大矩形枠（画像矩形枠に左右のスクロールバーを加えたサイズ）はgetGrowRect()ルーチンで求めるられます。

　

GetEventParameter()で現在のウィンドウ矩形枠を得て最大矩形枠とSectRect()を行い、制限内に内に収めるように対処しています。もうひとつは、ウィンドウの画像を再描画する前にSizeWindow()を呼び出している点です。このルーチンを呼ばないと、最後にマウスカーソルが静止した位置での中身の再描画が行われないことは前回に説明しました。元来、SizeWindoｗ()はシステムで実行されているはずですので、ここで呼び出さなければいけないのは釈然としません。

新しく改訂されれたCarbon Eventsに関するPDFドキュメントを調べてみると、10ページから「Default Event Handlers」という章があります。Carbon Event Modelでは、開発者側がウィンドウに対するCarbon Event Handlerを何も用意していないと、システムが用意しているHandlerが利用される仕組みになっています。つまり、システム側が自動でCarbon Eventの世話をしてくれるわけです。これを、Default Event Handlerと呼びます。こうしたDefault Event Handlerは、ユーザの操作対象である、あらゆるオブジェクト（アプリケーション、ウィンドウ、コントロール、メニューなど）に対して用意されており、開発者側の負担を減らすように考慮されています。ですから、昔のEvent Modelの場合なら、ウィンドウの移動、リサイズ、ズーム、閉じる処理などを実現するには、必ずWindow MangerのAPIを用いて、何らかのソースコードを記述しなければいけませんでした。しかしCarbon Event Modelでは、その手間の大部分を省くことが可能なのです。

この章で重要な箇所は、11ページから12ページにかけて記述されている、ウィンドウに関連したDefault Event Handlerの挙動内容です。マウスドラッグによりウィンドウのリサイズが起こった時、いくつものCarbon Event（Event Kind）が発生します。ここでは、その発生順序が時系列に解説されています。まずはユーザのマウスクリックにより「kEventClassMouse」（Event Class）の「kEventMouseDown」（Event Kind）が発生します。それ以降に発生するCarbon Eventを順次記載してみました（括弧内はEvent Kindです）。

（1）マウスがウィンドウのどの部分（パーツ）でクリックされたかチェックされる。
　　「kEventWindowHitTest」

（2）ウィンドウのRisize Region（グロウボックス）でクリックされたと判断される。
　　「kEventWindowClickResizeRgn」

（3）ウィンドウの最小サイズ（矩形枠）と最大サイズが設定される。
　　「kEventWindowGetMinimumSize」「kEventWindowGetMaximumSize」

（4）以下の3ステップはマウスドラッグ中に繰り返して処理される。

　（a）マウスドラッグがなされている。「kEventMouseDragged」
　（b）ウィンドウサイズが変更される。「kEventWindowBoundsChanging」
　（c）ウィンドウ枠の描画を行う。「kEventWindowGetGrowImageRegion」

（5）ユーザによりマウスボタンが離される。
　　「kEventMouseUp」

（6）サイズが変更されたウィンドウ自身が再描画される。
　　「kEventWindowDrawFrame」

（7）最終的なウィンドウ枠が決定される。
　　「kEventWindowBoundsChanged」

（8）ウィンドウのアップデートが要求される。
　　「kEventWindowUpdate」

（9）ウィンドウの中身がの再描画が要求される。
　　「kEventWindowDrawContent」

上記の流れを見てみると、ステップ3で呼び出されるkEventWindowGetMinimumSizeとkEventWindowGetMaximumSizeをこちら側で処理すれば、リサイズ最中に逐次ウィンドウサイズをチェックする必要はなさそうです。ViewJPEGアプリのHandlerルーチンに両Event Kindに対応する処理を追加することで、まずは最初の問題点は解決しました。

　

もうひとつの問題点は、kEventWindowBoundsChangedというEvent Kindが用意されていることに気づき謎が解けました。どうもリサイズ終了時のウィンドウサイズは、このEvent Kindが送られきた時点で決定されているようです。よって、ソースコードを以下のように書き直すことで、SizeWindow()を実行しなくても問題なくLive Resizingを行うことが可能になりました。

　

ちなみに、Mac OS XでウィンドウアトリビュートにkWindowLiveResizeAttributeをセットした時には、（4）の（c）は発生せず、代わりに（6）での処理が逐次実行されていると考えられます。それ以外にも、Mac OS XとMac OS 9では、Carbon Eventの発生順序や種類に微妙な違いがあるようです。よって、Event Handlerをインストールする時点で、前回紹介したchkSysOSX()を利用し、Mac OSのバージョンによりインストールすべきEvent Kindを切り替えることにしました。

　

今回の場合、Mac OS Xでは「kEventWindowBoundsChanging」と「kEventWindowBoundsChanged」がインストールされていますが、逆に「kEventWindowResizeCompleted」はMac OS 9のみのインストールとなります。こうした個別対処は、メニューやコントロールに対するCarbon Event Handlerのインストールでも必要になるかもしれません。

また、Carbon Eventには、名前は似ているが発生するタイミングが微妙に違う種類がいくつかあるようです。例えば、「kEventWindowClose」と「kEventWindowClosed」という似たような名前のEvent Kindがあります。前者はウィンドウのクローズボックスがクリックされ、マウスボタンが離された時点で発生します。後者はウィンドウが閉じられてしまってから発生します。最初のうち、ViewJPEGアプリでの画像ウィンドウを閉じてメモリを解放する処理は、kEventWindowClosedのHandlerルーチンとしてインストールされていました。しかし、これは大きな間違いです。これではウィンドウがすでに閉じられてしまった（DisposeWindow()が実行された）後に、またウィンドウを閉じる処理を繰り返えすことになり、大きなバグを生み出していたことになります。

Universal InterfacesのCarbonEvent.hには、個々のEvent Kindの内容や、その時点で入出力できるパラメータの種類については、そこそこ詳しい解説が載っています。しかし、Default Event Handlerを自分自身のHandlerルーチンに書き換えるような場合には、ユーザのマウスやキーボード操作により、どのような時系列でどんな種類のEvent Kindが発生するのかという情報が大変重要になります。残念ならら、こうした情報に関しては、まったく手がかりがありません。よって開発者側が自分でかってに想像するしかないのですが、それは危険で非効率な作業です。デベロッパーにもっとCarbon Event Modelを利用してもらいたければ、Apple社は、さらなる技術情報をドキュメントやサンプルソースとして早急に提供する必要があるでしょう。

今回の解説に用いたViewJPEG v1.23のソースコードは、以下のサイトに登録されています。詳細を確認したい方は、ぜひダウンロードしてみてください。

◇Ottimo: Digital Library
　http://www.ottimo.co.jp/library/index.html

[小池邦人/オッティモ]

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

Browsing Mac OS X》Launch Serviceでのプログラム例

Launch Servicesの利用方法の続きを説明しよう。前回は概要だけだったが今回は詳しく説明することにする。ヘッダファイルのLaunchServices.hについても並行して目を通していただきたい。まず、Launch ServicesにはいくつかAPIがあるが、それらを整理すると以下の3つのジャンルに分けることができる。もちろん、情報を取得したいという人もいるだろうけど、もっともよく使うのは、最後のファイルやURLをオープンするというカテゴリにあるAPIコールだろう。今�鵑呂海譴蕕鮖箸辰織汽鵐廛襯廛蹈哀薀爐魴悩椶垢襦�プログラムは別掲の記事に示した。

□Launch Serviceの初期化と終了
　LSInit、LSTerm

□ファイルやURLに関わる情報の取得
　LSCopyItemInfoForRef、LSCopyItemInfoForURL、
　LSCopyKindStringForRef、LSCopyKindStringForURL、
　LSGetApplicationForItem、LSGetApplicationForInfo、
　LSGetApplicationForURL、LSFindApplicationForInfo、
　LSCanRefAcceptItem、LSCanURLAcceptURL

□ファイルやURLをオープン
　LSOpenFSRef、LSOpenCFURLRef、
　LSOpenFromRefSpec、LSOpenFromURLSpec

ファイルやURLをオープンするAPIは4つあるが、それぞれ、開く対象をFSRefで指定するものとCFURL（Core FoundationのURL ServiceベースのURL）で指定するものに分けられる。また、それぞれ、単に1つのFSRefやCFURLを開くものと、アプリケーションと開く文書をそれぞれ別々に指定することができるものに分けられる。

まず、単に指定したFSRefを開くのがLSOpenFSRefである。指定したのがアプリケーションであればそのアプリケーションが開く。文書ファイルであれば、その文書ファイルに関連づけられたアプリケーションが開き、文書ファイルを開く。いわば、Finder上でダブルクリックした動作に等しいAPIだと言えるだろう。
サンプルプログラムではLaunchItem関数で、LSOpenFSRefを使っている。サブルーチンにするまでもないほどではあるが、いちおうLaunch ServicesのAPIコールが明確になるように、サブルーチンとしてみた。LSOpenFSRefは2つの引数をとるが、1つ目に開く対象のFSRefがあればよい。2つ目の引数は、実際に開いたアプリケーションへのFSRefが戻される。たとえば、文書ファイルを開くとその文書ファイルを開いたアプリケーションへの参照が得られる。ただし、その参照が不要な場合には、NULLを指定する。起動処理は非同期に行われる。起動処理に入り、呼び出し側ではすぐにLSOpenFSRefの次に実行が移る。起動するまで待つという動作をしたい場合には、以下で説明するLSOpenFromRefSpecというAPIコールを利用する。非同期での起動でも、起動したことを知らせると思われるNotifiyの仕組みがどうやらあるようだが、LaunchServices.hを見る限りではその使い方は詳しくは書いていない。
プログラムでは、TextEditを起動するように作ってみた。TextEdit自体をどうやって参照するかだが、当初はFindFolderやFSFindFolderを使って、Applicationsフォルダを参照して、そこからファイル名で指定をしようと考えた。しかし、FindFolderやFSFindFolderのいずれもアプリケーションフォルダへの参照を得ようとしてもエラーがでて得られなかった。そこで、フルパスを記述してそこからFSRefを得るFile ManagerのAPIの1つFSPathMakeRefを使って、TextEditへの参照を得た。なお、FSPathMakeRefの引数はUTF-8の文字列を指定しないといけないので注意が必要だ。TextEditだとアルファベットだけのパスなので、今回の例では気楽に利用できる。

次に、開くファイルとそれに使うアプリケーションを別々に指定するLSOpenFromRefSpecというAPIコールを使ってみた。実際の例が、LaunchDocumentWithApp関数に記載している。LSOpenFromRefSpecも引数は2つだけだが、1つ目にLSLaunchFSRefSpec構造体へのポインタを指定するようになっている。この構造体に、開くアプリケーションや、開く文書などいろいろなものを指定する。実際の指定方法は、LaunchDocumentWithApp関数のプログラムを参照してもらいたい。ここで、開く文書が複数ある場合にも対応している。そのときは、FSRefが連続して入っているメモリーブロックのポインタを指定し、いくつのFSRefがあるのかも構造体の別のメンバーに指定をする。このFSRefの連続したものは、FSRefの配列である。イメージ的には、1つのFSRefが80バイトであるので、その80バイトのメモリブロックがファイルの数だけ並んでいると思えばよい。たとえば、3つのファイルを開く用に指定していれば、240バイトのメモリ領域を確保しておき、その先頭のアドレスを指定すればいいということだ。
LSLaunchFSRefSpec構造体のlaunchFlagsというメンバには、LSLaunchFlagsという型で定義された値を指定するが、要は定義されている定数をそのままあるいは加算して指定すればそれでよい。これも、詳しくはLaunchServices.hを参照してもらいたい。たとえば、起動するけどすぐに背後に隠れるようにするという定義定数や、Info.plistの設定を無視するといった定義定数も見られる。なお、kLSLaunchDefaultsだと、非同期での起動で、起動するアプリケーションのinfo.plistファイルの設定に従うということになっている。起動するまで待つように処理したいのなら、たとえば、launchFlagsに0を設定することで、非同期のフラグを落として実行すればよい。
サンプルプログラムのmain関数側では、Navigation Servicesのファイル選択ダイアログボックスを表示し、開くファイルを指定して、そのファイルをTextEditで開くというようにプログラムを作っている。ファイル選択ダイアログボックスで、複数のファイルにも対応できるようになっている。NavChooseFileの引数指定は最低限しか指定していないので、タイトルバーもでてこないがそのあたりはお許し願いたい。FSRefの配列の入ったメモリブロックを構築するあたりが、C言語の複雑なところで、ポインタ処理と配列の連動をうまく組み込まないといけないところだ。

さらに、指定したURLを開くLSOpenCFURLRefというAPIコールを使ったのがOpenURLという関数だ。URLではファイルを指定してもいいが、一般にはWebサイトなどを指定することになるだろう。http://で始まるURLを指定すると、システム側で定義されているデフォルトのWebブラウザを使って、そのサイトを開くことができる。Mac OS 9.1まではInternetConfigのAPIを使っていたか、あるいはAppleEventを利用していたかもしれないが、InternetConfigのAPIはちょっと独特だったので思わずひるんでしまうところだった。だけども、Launch Servicesを使うと、簡単にURLをデフォルトのブラウザで開くことができる。LSOpenCFURLRefには引数が2つあるが、1つ目に開くURLを指定する。2つ目にはベースになるURLを指定するが、1つ目に絶対参照を指定するのなら2つ目はNULLでかまわない。CFURLは、CFURLCreateWithStringを使えばCFStringから簡単に変換できる。ここではCFSTRマクロを使ってCFStringを生成しているが、CやPascal文字列からCFStringを得るには、CFStrinCreateWithCStringやCFStringCreateWithPacalStringなどのAPIコールを使えばよいだろう。「NoCopy」の名前の付いたAPIコールもあるので、そのあたりの使い分けはCore Foundationのドキュメントを参照してもらいたい。

以上のように、単に別のアプリケーションや文書あるいはURLを開くだけなら、たいして難しいプログラムは必要はない。ただ、Launch ServicesがMac OS Xでしか利用できないので、Carbon対応アプリケーションでも、Mac OS XなのかMac OS 9までなのかで処理を分けないといけないだろう。Mac OS 9までの場合には、以前までに使われていたプログラムを使い、Mac OS Xに対応するときにその部分にLaunch Servicesをつかったもの書き足すという使い方もできるだろう。

カテゴリ：ユーザインタフェース, Browsing Mac OS X

Browsing Mac OS X》Launch Serviceでのプログラム例（プログラム）

Project Builderで、新たなプロジェクトを、Cocoa Applicationのテンプレートを使って作成する。そして、作成されたプロジェクトにあるmain.cの内容を以下のプログラムにそっくりそのまま入れ替えれば、利用することができる。


/* main.c */

#include 

OSStatus LaunchItem(FSRef * app);
OSStatus LaunchDocumentWithApp(FSRef * doc, UInt32 nDocs, FSRef * app);
OSStatus OpenURL(CFStringRef urlStr);

/* 3種類のプログラムを用意したが、以下の3行のdefineのうち、1つだけ
   コメントをはずすようにしてどのプログラムを動かすかを決める。　*/
//#define Try1
#define Try2
//#define Try3

int main(int argc, char *argv[])
{
    OSStatus er;
    FSRef editTextRef;
    char path[256];
#ifdef Try2
    NavReplyRecord reply;
    UInt32 itemsInList;
    FSRef* docArray;
    AEKeyword keywd;
    DescType returnedType;
    Size actualSize;
    int i;
#endif
    
    LSInit(kLSInitializeDefaults);  //Launch Servicesの初期化、引数はこれを指定しろとなっている

    strcpy(path, "/Applications/TextEdit.app");  //TextEditへのパスを記述
    er = FSPathMakeRef(path, & editTextRef, NULL);    //TextEditへのFSRefを取得
#ifdef Try1
    er = LaunchItem(&editTextRef);
#endif
#ifdef Try2
    er = NavChooseFile(NULL, &reply, NULL, NULL, NULL, NULL, NULL, NULL);
            //ファイルを選択するダイアログボックスを表示する
    if(reply.validRecord)       {        //Cancelが押されていないなら
        er = AECountItems(&reply.selection, &itemsInList);    //ファイル選択した個数
        docArray = (FSRef*)NewPtr(sizeof(FSRef)*itemsInList);      //各ファイルへのFSRefを納める領域を確保
          for ( i=1 ; i<= itemsInList ; i++)  {
                    er = AEGetNthPtr(&reply.selection, i, typeFSRef, &keywd, &returnedType, 
                                    &docArray[i-1], sizeof(FSRef), &actualSize);
                    //ファイルの選択結果からFSRefとして取り出して、メモリに保持する
        }
        LaunchDocumentWithApp(docArray, itemsInList, &editTextRef);
        DisposePtr((Ptr)docArray);
    }
#endif
#ifdef Try3
    OpenURL(CFSTR("http://cserver.locus.co.jp/mdo.html"));
#endif
    LSTerm();
    return 0;
}

OSStatus LaunchItem(FSRef * app)    {
    OSStatus er;
    er = LSOpenFSRef(app, NULL);        //引数のファイルを開く
    return er;
}

OSStatus LaunchDocumentWithApp(FSRef * doc, UInt32 nDocs, FSRef * app)    {
    OSStatus er;
    LSLaunchFSRefSpec inLaunchSpec;

    inLaunchSpec.appRef = app;            //起動するアプリケーション
    inLaunchSpec.numDocs = nDocs;   //開く文書の数
    inLaunchSpec.itemRefs = doc;        //文書ファイルのFSRefの配列へのポインタ
    inLaunchSpec.passThruParams = NULL;          //追加のパラメータはななし
    inLaunchSpec.launchFlags = kLSLaunchDefaults;   //起動の動作はデフォルト
    inLaunchSpec.asyncRefCon = NULL;       //この引数も使わない
    
    er = LSOpenFromRefSpec(&inLaunchSpec, NULL); //文書をアプリケーションで開く
    return er;
}

OSStatus OpenURL(CFStringRef urlStr)       {
    OSStatus er;
    CFURLRef thisURL;
    
    thisURL = CFURLCreateWithString(kCFAllocatorDefault, urlStr, NULL);
                //CFStringからCFURLに変換
    er = LSOpenCFURLRef(thisURL, NULL);   //URLを開く
    return er;
}

カテゴリ：

REALbasic 3.1が正式版として配布を開始

Real Softwareは、Mac OS Xに対応した開発ツールREALbasic 3.1を正式に出荷した。これまではベータ版としてリリースされてきていた。Ver.3.0のユーザはそのままシリアル番号を利用できる。Ver.3.0でMac OS X対応し、Carbonをベースに稼働する統合開発環境を利用でき、また、Carbonで稼働するアプリケーションの作成もできるようになった。しかしながら、Mac OS X Public Betaしか発売されていない状況でのREALbasic 3.0のリリースだったために、正式出荷版のMac OS X 10.0ででは最適化されていなかったため、急遽Ver.3.1の開発が進められた。Mac OS XでREALbasicを使うユーザは必ず3.1にアップデートするようにすすめられている。なお、日本語版についての配布時期などのアナウンスについてはまだされていない。

関連リンク：REALbasic: Current Release
カテゴリ：REALbasic

QuickTime 5の英語版のダウンロードが開始、プレビュー版から正式リリースへ

QuickTime 5とQuickTime Streaming Server 3が正式に発表された。QuickTime 5の英語版は配布が開始されている。各国語版については2001年5月にリリース予定だ。QuickTime Streaming Server 3は、5月にリリースされる。いずれも、プレビュー版としてすでにリリースされているが、正式版が登場することとなった。なお、Mac OS X 10.0にはQuickTime 5が当初からインストールされている。今回配布されたのは、Mac OS 9.1までのシステムで使用できるQuickTime 5である。
QuickTime 5ではエンコードの改良などもあるが、大きな柱はCubic VR Movieと、Skin対応といえるだろう。Cubic VRは、VRムービーを180度の視野からさらに上下方向の視野も増やして360度の方向を見ることできるといったものだ。いままでのVRムービーは右や左に方向を変えることができたが、上を向いたり下を向くということができるようになるのである。SkinはMP3プレイヤでおなじみの機能だが、QuickTime 5のSkinは少しニュアンスが違って単にプレイヤの飾り付けではない。Skin自体をムービーに入れてコンテンツの一部としてSkinを作成することができる。また、AppleScriptと組み合わせることにより、QuickTime Playerでさまざなオーサリング機能を利用できるようにすることができる。つまり、Skinで独自のオーサリングしたコンテンツを作成できるようにもなるのである。いずれも、QuickTimeの利用者にはすぐにはメリットとしては得られないことではあるが、開発者や制作者にとっては新しい手段が増えた点はチェックをしておくべきところだろう。
QuickTime Streaming Server 3では、Skip Protectionとしてストリーミングがとぎれがちでも品質を保つ機能や、Webベースでの管理機能などが追加されている。オープンソースで展開しているDarwin Streaming Server 3もリリースされ、Linux、FreeBDD、Solaris 8、Windows NT/2000を動作環境としてサポートする。

関連リンク：Apple Announces QuickTime 5 and QuickTime Streaming Server 3
カテゴリ：QuickTime

Mac OS Xに対応したファイルの中身を16進数で表示・編集可能なプログラム

Raphael Sebbe氏が公開した「HexEditor 1.1」は、Mac OS Xで稼働するアプリケーションで、ファイルの内容を16進表示するものだ。また、内容の修正もできるが、16進数だけでなく、10進数や複数のデータバイトをまとめて浮動小数点数、あるいは文字列として修正ができるなど、実用度はなかなか高い。また、ファイル中の漢字文字列については16進表示部分では前後のバイトに分かれてしまうものの、テキスト編集では漢字として表示し、さらに修正までできてしまう。プログラミングあるいは解析のときには、こうした16進数でファイルの中身を参照できるユーティリティがあると、実際に書き込まれているデータがそのまま見られることもあって便利な場合もあるだろう。

関連リンク：MacOS X - Programming Examples
カテゴリ：ユーティリティ

TIL》Mac OS X 10.0.1でのアップデートの変更点を紹介

Tech Info Libraryに、Mac OS X関連のアップデートの変更点がまとめられた文書が掲載された。Software Update 1.3.1は、ダウンロード処理の復帰やプロキシ経由のダウンロード、インタフェースの改良が行われた。10.0.1 Updateでは、iTunesの処理能力の向上、サードパーティのUSBやFireWireデバイスを利用する際の性能向上、SSHによりリモート接続、Classic環境の改良、AFPボリュームに対する互換性の向上となっている。

関連リンク：Mac OS X 10.0: Software Update 1.3.1, 10.0.1 Update, and Epson Printer Driver Update Provide Feature Enhancement, Address Issues
カテゴリ：Knowledge Base（旧TIL）, Mac OS X