MOSA Multi-OS Software Artists

MOSAはソフトウェア開発者を支援します

プログラマーに興味がある方なら誰でも入会いただけます。
MOSA Multi-OS Software Artists
===SINCE 1995===

  • iPhone/iPod touch アプリ紹介
  • MOSA掲示板
  • 活動履歴
  • About MOSA(English)

MOSADenバックナンバー 2005年7月発行分

  • MOSA Developer News[MOSADeN=モサ伝]第169号

    2005-07-26

    目次

    • 「WebObjects Dev Report」     第15回  田畑 英和
    • 藤本裕之のプログラミング夜話 #73
    • 高橋真人の「プログラミング指南」  第71回
    • ニュース・解説                小池 邦人

    「WebObjects Dev Report」  第15回  田畑 英和

     ここ数回モデルファイルの作成方法について解説してきましたが、いつまでもモデルの話ばかりしてられないので、そろそろ次の話題に移っていきたいと思います。
     モデルには、データベースとオブジェクトをマッピングするための情報が定義されていますが、実際にモデルを利用するにはプロジェクトに追加する必要があります。プロジェクトに追加したモデルファイルは自動的に認識されますが、モデルファイルを直接プロジェクトに登録してしまいますとそのプロジェクトからしか認識されません。
     1つのプロジェクトしか作成しない場合はもちろんこれでもよいのですが、プロジェクトを複数作成し、各プロジェクトで共通のモデルファイルを参照したい場合もあります。たとえば一般ユーザ用と管理用のアプリケーションを個別に作成するようなことが考えられます。
     このときそれぞれのプロジェクトに直接モデルファイルを登録してしまいますと、モデルファイルを更新する場合、プロジェクトごとにモデルファイルの更新をおこなわなければならなくなります。このような問題を解決する手段として複数のプロジェクトから共通のリソースを呼び出すための仕組み「フレームワーク」が用意されています。今回はこのフレームワークの作成方法について解説したいと思います。

    フレームワーク

     WebObjectsアプリケーションを開発する場合は、Xcodeで新規プロジェクトを作成(「WebObjects Application」タイプを使用)するのが一般的ですが、このタイプのプロジェクトを作成するとすでにプロジェクトにいくつかのフレームワークが登録されています。
     ここで一応フレームワークについて簡単に説明しておきますと、ライブラリや画像ファイルなどの様々なリソースをたばねて、他のプロジェクトから参照可能にするのがフレームワークの役割です。”/System/Library/Frameworks”にシステム標準のフレームワークがあらかじめインストールされていることを確認することができます。フレームワークは既存のものを利用することもできますし、自分でフレームワークを作成することもできます。フレームワークにはとにかく色々なファイルを格納することができますので、モデルファイルを格納したフレームワークを作成しておけば、そのフレームワークを複数のプロジェクトから参照し、1つのモデルファイルを共有することが可能になります。こうしておけばフレームワーク内のモデルファイルだけをメンテナンスすればよいことになります。またフレームワークにはJavaプログラムも格納しておくことができますので、共通して利用するようなロジックをフレームワーク化して、複数のプロジェクトから利用することもできます。

    フレームワークの作成

     では実際にどのようにしてフレームワークを作成するかですが、Xcodeで新規プロジェクトを作成するときに「WebObjects Framework」を選択してください。これでまず空のフレームワーク用プロジェクトが生成されます。
     空のプロジェクトが作成できましたら次に、モデルファイルをプロジェクトに登録します。プロジェクトにはあらかじめいくつかのグループが設定されていますが、モデルファイルを登録する場合は「Resources」グループあたりがよいでしょうし、新しいグループを作成してそちらに登録してもよいです。
     フレームワークのインストール先ですが、”/Library/Frameworks”にインストールします。また、WebObjectsのサンプルにもいくつかフレームワークのサンプルが登録されていますので、次のディレクトリも参照してみてください。

    ・サンプルフレームワーク
    /Developer/Examples/JavaWebObjects/Frameworks

    フレームワークの利用

     フレームワークが作成できれば、あとはそのフレームワークをプロジェクトに登録することにより、プロジェクトからフレームワーク内のモデルファイルやその他のリソースにアクセスできるようになります。
     このようにフレームワーク化をおこなっておくことにより、効率よく開発がおこなえるようになりますが、どのような区切りでフレームワークを作成するかは十分検討する必要があります。無秩序にフレームワークを作成していってしまいますと、今度はかえってフレームワークのメンテナンスに手間がかかってしまう、なんてことになりかねません。
     またどのようにフレームワークを作っていけばよいかよく分からないような場合は、まずはプロジェクトを単体で開発していき、そのなかからまとまりのある部分や、他のプロジェクトと共通している部分をフレームワーク化していくのもよいでしょう。

    藤本裕之のプログラミング夜話 #73

     承前。優秀で勤勉なる我が読者の皆さんのこと、大多数はワタシが前回ここで作ってみせたサンプルプログラムと同じものを自分で作成、あーだこーだといろいろ試しまくり調べまくり納得しまくっただろうから、今回ワタシがする説明などは必要なくなっているだろうと思う。しかしワタシは「一握りのエリートだけが国の将来を左右するに足るような高等教育を受ければいい、シモジモは読み書きそろばんくらいでいいのだ」という三浦朱門先生みたいな考え方には反対である。予習復習をキチンとやるようなヨイ子は確かに手間もかからず頼もしいが、サボリまくりの劣等生の中にもしかしたら天才がいるかも知れないのだ。エジソンもアインシュタインも初等教育の段階では劣等生だったことを忘れてはいけないのである(音楽盛り上がって)。
     
     閑話休題。前回ワレワレは(という疑似共犯的書き方は好きではないが)、NSViewのサブクラスを2種類つくって一方(MySmallView)を他方(MyBigView)に包含される形に配置し、背後にあるMyBigView の mouseDown:をオーバーライドして前面の MySmallView をクリックしたときも MyBigViewに mouseDown: メッセージが送られてくることを見た。これはどういう仕組みなのか。
     ウィンドウとその内部に配置されるビューなど包含関係を成すオブジェクトの集合は、NSResponderのサブクラスとして、Nibファイルからロードされてメモリ上に配置された時に一連の「レスポンダ・チェイン」というものを形成する。レスポンダ・チェインはNSResponderクラスの唯一のインスタンス変数である _nextResponder というオブジェクトへのポインタを介したいわゆるリスト構造で、上の例でいえばMySmallView(正確に言うとMySmallViewのインスタンス、長いので省略する。以下も同じ) はそのインスタンス変数_nextResponder にMyBigView へのポインタを保持し、MyBigView は同じくウィンドウの contentView を保持している。
     そして、サブクラス(あるいはカテゴリ)によってオーバーライドされないNSResponderの mouseDown: の中身は(ソースが公開されてないので「おそらく」だが)以下のようなものである。

    -(void) mouseDown: (NSEvent*) theEvent {
        [_nextResponder mouseDown:theEvent];
    }
    


     もうお分かりだろうが、mouseDown: をオーバーライドしていないMySmallViewはマウスクリックが起こるとこれを実行する。こいつの_nextRespnder はMyBigViewなので、MyBigView にmouseDown: が送られ、それはオーバーライドされて console にメッセージを出すようになっている、という寸法で、前回最後に見た実行結果が現出したわけである。おわかりか。
     なお、このMySmallViewの代わりにNSButtonやNSTextFieldなどを配置した場合、NSBigViewにmouseDown: は送られて来ない。確かにNSButtonもNSTextFieldもNSResponderのサブクラスには違いないが、それ自体が既にmouseDown: をオーバーライドしているから。そんなこと当然ではないかと思うかも知れないが(いや、オレもそう思ったんだけど)、以前どっかで上のようなレスポンダ・チェインの説明に、先頭にNSButtonがある図を使ってるのを見たような気がするので念のため。

     次回はレスポンダ・チェインのもう一つの活躍ドコロ、ちうかこっちがメインの活躍場所だけど(だって上のような一種のパス機能を意図的に使う機会ってそうないからね)、「nil をターゲットにしたアクション」を説明する。そして、「ファースト・レスポンダ」にまつわる思い込みや勘違いをただしたい。では。
    (2005_07_21)

    高橋真人の「プログラミング指南」第71回

    UNIXとしてのMac OS X

    〜Perlについて(17)〜

     こんにちは、高橋真人です。
     さて前回の最後に、Perlで正規表現を記述するときに最もよく使われる//という演算子は、本当はm//という形だということをご紹介しました。このm//演算子にはいくつかのオプションを指定することができます。今回はこのオプションについてのお話です。
     Perlのリファレンスを見ますとm//演算子に付けられるオプションは7つもあるのですが、すべてを説明するのはこの連載のポリシーに合いませんので(笑)、代表的なものを二、三紹介します。

     まずは、s///演算子のところでも触れたことがあるので憶えている方もおいでかもしれませんが、gです。たとえば以下のように使います。

    if ($string =~ m/abc/g) {
        ...
    }
    


     このようにすると、abcという正規表現は、$stringの中に含まれるabcという文字並びすべてにマッチすることになります。ただ、ちょっと考えてみればお分かりのように、このような書き方をするときにgオプションを使うことにはあまり意味はありません。なぜなら、$stringの中にabcが一つでも含まれていれば、それだけで条件判断は成立してしまいますから。マッチ個所が二つあろうが三つあろうが条件が成立したことに変わりはありません。
     そもそもm//演算子にgオプションを付ける意味なんてあるんでしょうか? もちろんあるんです。ここがまたPerlの面白いところでもあり、複雑なところでもあるのですが。
     今まで条件判断の中でm//演算子を使ってきましたが、実はここがスカラーコンテキストなのだということに気付かれていたでしょうか? さあ、出てきましたよ、「コンテキスト」(笑)。もう忘れてしまった人は連載の62回目あたりを読み返してみてくださいね。
     さてm//演算子は、スカラーコンテキストでは真偽値を返します。つまり、パターンマッチングが成功すれば真を返し、ダメなら偽を返すのです。では、リストコンテキストではどうなるのかということですが、まずは以下のコードを見てください。

    @matched = $string =~ m/abc/g;

     ちょっと、見慣れないと何をしているのか分かりにくいかもしれませんが、パターンマッチングを$stringに対して行い、その結果を@matchedに代入しているのです。ごらんのように@matchedはリスト変数ですから、この代入式はリストコンテキストになります。
     では、実際に走らせて、リストに何が入るのかを見てみましょう。

    $string = 'aBcdefABCdefabcffabc';
    @matched = $string =~ /abc/g;
    print @matched;

     出力結果は、

    abcabc

    となりました。
     本当はもう少し体裁よくプリントしたいところですが、そのためにはまた新しい要素をいくつか説明しないとならないので、今回はリストをそのままprint演算子に渡します。print演算子は、リストを処理するときすべての要素を連結した形で出力します。従って、@matchedの中身は(‘abc’, ‘abc’)だということです。
     以上でお分かりの通り、m//演算子にgオプションを付けた場合、リストコンテキストではマッチしたものすべてをリストにして返すことになっています。(ただしgオプションを付けない場合にはまた状況が異なるのですが、話が複雑になるため今回は説明から除外します)

     さて次は、iオプションです。iを付けるとm//演算子は大文字と小文字の違いを無視します。早速やってみましょう。オプションは複数のものを併用できますから、先ほどの例にiオプションを加えて試してみます。

    $string = 'aBcdefABCdefabcffabc';
    @matched = $string =~ /abc/gi;
    print @matched;

     出力結果は、

    aBcABCabcabc

    となります。
     パターンの際には大文字と小文字の違いが無視されますが、マッチした部分が変化するわけではないので、リストコンテキストで返されるとき、それぞれの要素の大文字、小文字はオリジナルのままです。
     さて、以前「大文字、小文字を問わない」表現として、[aA][bB][cC]というものを紹介しましたが、Perlの場合には、iオプションを使うことでよりシンプルに表現できるのです。

    ニュース・解説

    今週の解説担当:小池邦人

    Carbon ドキュメント & サンプル & SDK ナビゲーション(2005/7/22)

    【開発環境】

    日本でも、Apple社によるWidgetダウンロードサイトが立ち上がりました。
    MOSAでは「Dashboard Widgetプログラミングセミナー」開催を機に、様々なカテゴリーのWidgetを会員の皆様から募集しています。例えば、以下のようなカテゴリーのWidgetの開発にチャレンジしてみてはいかがでしょうか?

    「株価」「乗り換え案内」「地図」「辞書」「和風単位換算」「占い」「今日は何の日」「映画情報」「時刻表」「ライブカメラ」「交通情報(渋滞情報とか)」「貨物追跡」「イエローページ」「郵便番号検索」「今日の料理」「お買い得情報」「Mixi更新状況」「パッケージツアー情報」「ヤフオクウオッチャ」「花粉情報」「サーチエンジン系」「行楽情報」「日本の祝日・六曜」「ゲーム系」「iCalビューワ」「たまごっち系」「UGイベントカレンダー」

    開発されたWidgetについてご連絡を頂ければ、Apple社ご協力のもと、MOSAおよびApple社ウェブサイトやメーリングリストにて、積極的にご紹介したいと考えています。
    ご連絡はMOSA事務局までどうぞ!

    MOSAのWidgetセミナー内容に関しては以下のサイトをご参照ください。
    http://www.mosa.gr.jp/htmdocs/article/170701-dashboard.htm

    Apple社のサイトではWidgetのダウンロードサイトも立ち上がっています。
    http://www.apple.com/jp/downloads/macosx/

    一般ソフトウェアやWidgetの申し込みのガイドライン(Apple社)はこちらです。
    http://www.apple.com/jp/downloads/macosx/submit/index.html

    【テクニカルドキュメント】

    前回から7月22日の期間中、Apple社のDocumentationサイトには新規ドキュメントがひとつも登録されませんでした。その代わりに、新規のデベロッパー向け読み物が2つ登録されています。「Simplifying Data Handling with Uniform Type Identifiers」については、前号の木下さんの記事を参照してみてください。

    「Using Automator to Expand the Market for Your Software」(読み物)

    http://developer.apple.com/macosx/automatormarket.html

    「Simplifying Data Handling with Uniform Type Identifiers」(読み物)

    http://developer.apple.com/macosx/uniformtypeidentifiers.html

    前回から7月22日の期間中、新規テクニカルノートは2つ登録されました。新規テクニカルQ&Aの方は4つ登録されています。QA1439では、「kEventControlHit」イベントでControl(HIView)のPart Codeを受け取るには、先んじて「kEventControlHitTest」イベントを受け、その処理の中でPart Codeを渡す必要があることがソースコードと共に解説されています。TN2138については、前号の木下さんの記事も参照してみてください。

    TN2138「QTKit Frequently Asked Questions」
    TN2148「Multi-Buffer Aware Image Decompressors」

    http://developer.apple.com/technicalnotes/index-rev-date.html

    QA1439「Why am I not receiving kEventControlHit events for some of the parts of my custom HIView?」
    QA1357「Mixing link-local IP addresses and routable IP addresses」
    QA1389「Problems getting Bonjour TXT record information」
    QA1424「What are the predefined macros for GCC?」

    http://developer.apple.com/technicalqas/index-rev-date.html

    【サンプルソースコード】

    前回から7月22日の期間中、Apple社のSample Codeサイトには、新しいサンプルソースコードが8つ登録されました。QuickTime関連のサンプルソースコードが多いのは、古いQuickTime APIをモダンAPIに差し替えたサンプルの提供が活発化しているためのようです。「WhackedTV」と「QTCoreImage101」はCocoa用のサンプルソースコードで、後者は、Movie再生中の映像に「Core Imageエフェクト」をかけるサンプルです。

    「ASCIIMoviePlayerSample」(QuickTime関連)
    「CaptureAndCompressIPBMovie」(QuickTime関連)
    「QTCoreImage101」(QuickTime関連)
    「QTCarbonShell」(QuickTime関連)
    「SimpleAudioExtraction」(QuickTime関連)
    「WhackedTV」(QuickTime関連)
    「EnhancedAudioBurn」(DiscRecord関連)
    「Quartz Composer QCTV」(Quartz Composer関連)

    http://developer.apple.com/samplecode/index-rev-date.html

    【デベロップメント SDK】

    前回から7月22日の期間中、Apple社のSDKサイトには新しいSDKが2つ登録されました。最近、.Macでは、新しい「bandwidth/storageアップグレード・オプション」が開始されたようですので、「.Mac 2.0 SDK」は、それに合わせたバージョンアップかもしれません。「Kernel Debug Kit 10.4.2」は、最近登場したMac OS X 10.4.2に対応したバージョンとなっています。

    「.Mac 2.0 SDK Developer Preview」
    「Kernel Debug Kit 10.4.2」

    http://developer.apple.com/sdk/

    MOSAからのお知らせと編集後記は割愛します

    MOSA Developer News   略称[MOSADeN=モサ伝]
    Apple、Mac OSは米国アップルコンピュータ社の登録商標です。またそのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。
    このメールの再配信、および掲載された記事の無断転載を禁じます。
    特定非営利活動法人MOSA
    Copyright (C)2005 MOSA. All rights reserved.

  • MOSA Developer News[MOSADeN=モサ伝]第168号

    2005-07-19

    目次

    • 「WebObjects Dev Report」    第14回  田畑 英和
    • 小池邦人の「Carbon API 徒然草」
    • SqueakではじめるSmalltalk入門  第43回  鷲見 正人
    • ニュース・解説               木下 誠

    「WebObjects Dev Report」  第14回  田畑 英和

     今回は、前回解説しきれなかった多対多のRelationを解説したいと思います。対1(to-One)と対多(to-Many)のRelationはすでに紹介しましたが、これだけでは表現できないデータ構造もあります。たとえばビジネスマッチングシステムにユーザのプロファイルを登録するときに、ユーザごとに得意なプログラミング言語も登録できるようにするとしましょう。
     このとき、登録可能なプログラミング言語用のEntity(ProgLang)を追加してからMOSAUserとRelationを設定するとします。複数のプログラミング言語をマスターしている方もいらっしゃるでしょうから、1人のユーザに対して複数のプログラミング言語が選択できる必要があります。
     ですが、単純にMOSAUserからProgLangに対して対多のRelationを設定してしまいますと、MOSAUserのプライマリーキーをProgLangに外部キーとして登録することになり、ProgLangからみるとMOSAUserに対して対1のRelationしか設定できなくなります。つまりあるプログラミング言語はたった1人のユーザにしか設定できなくなります。これではObjective-Cが使えるのはSさんだけ、Javaが使えるのはTさんだけ、となってしまいますが実際には1つのプログラミング言語は複数のユーザに設定できるようにしなければなりません。

     つまり、MOSAUserからProgLang、ProgLangからMOSAUserの両方について対多のRelationを設定する必要があるということです。このようなRelationが多対多ということになりますが、ここで問題になるのが外部キーをどのように扱うかです。2つあるEntityのどちらかのプライマリキーをもう片方の外部キーとして扱うと、Entityが2つだけでは両方で対多のRelationを設定することができません。
     両方のEntityのプライマリーキーをそれぞれ外部キーとして扱う必要があるわけですが、キーを管理するためのEntityを1つ追加することによって対応が可能になります。

     そこで具体的にどうするかですが、分かりやすくするためにまずは簡単な例を考えてみましょう。まずユーザSからUまで3人のユーザが存在し、それぞれ次のようなプライマリーキーが割り当てられ、プログラミング言語としては3つの言語が管理されていたとしましょう。

    ・ユーザ(プライマリーキー)
    ユーザS(1)
    ユーザT(2)
    ユーザU(3)
    ・プログラミング言語(プライマリーキー)
    Objective-C(10)
    Java(11)
    Ruby(12)

     各ユーザごとに複数のプログラミング言語を設定するには、キーを管理する3つ目のEntityを用意し、ユーザとプログラミング言語のEntityのそれぞれのプライマリーキーの組み合わせを設定します。つまり次のようになります。

    ・3つ目のEntity
    1, 10 <- ユーザSとObjective-C
    1, 11 <- ユーザSとJava
    1, 12 <- ユーザSとRuby
    2, 11 <- ユーザTとJava
    3, 10 <- ユーザUとObjective-C
    3, 12 <- ユーザUとRuby

     ユーザとプログラミング言語のEntityにおけるプライマリーキーの組み合わせが3つ目のEntityに登録されています。このとき3つ目のEntityには2つのキーを登録できるように、2つのAttributeを追加しておきます。ではこのとき3つ目のEntityのプライマリーキーをどのように設定するかですが、2つのキーの組み合わせは3つ目のEntity内ではかならずユニークになります。ですので、3つ目のEntityに追加した2つのAttributeをそれぞれプライマリーキーとして設定することにより、Entity内での各レコードをユニークに識別できるようになります。このようにプライマリーキーは必ずしもEntity内で1つだけではなく、複数存在する場合もあります。

     多対多の関係をもったRelationをモデル上に作成する方法ですが、基本的には1つEntityを追加し、双方のEntityのキーを管理すれば良いことになります。ですがEOModelerには多対多のRelationを自動的に作成する機能がありますので、こちらを紹介しておきましょう。Relationを設定したい2つのEntityを選択した状態で、「Property」メニューから「Join in Many-to-Many」を実行すると、自動的に3つ目のEntityおよびRelationを自動的に作成してくれます。自動的に作成されたEntityやRelationの名前は必要に応じて変更するとして、これで簡単に多対多のRelationを作成することができます。
     WebObjectsに付属するサンプルのモデルファイルにも、多対多のRelationが含まれていますので、そちらも参考にしていただければと思います。

    ・モデルファイルのサンプル
    /Developer/Examples/JavaWebObjects/Frameworks/JavaBusinessLogic/
    Movies.eomodeld

    小池邦人のCarbon API 徒然草

    Carbon API 徒然草(2005/07/15)

    〜 ドラッグ&ドロップの活用(その6) 〜

    今回は、アプリケーションからFinderなどにファイル情報をドラッグ&ドロップする時、どのようにドラッグアイテムを作成したら良いのかを調べてみます。具体的には、ドラッグアイテムとして渡すことになる、HFSFlavor構造体と、PromiseHFSFlavor構造体の使い分けの解説です。

    まず最初に紹介するのが、Finderや他のアプリケーション(ワープロや画像編集ソフトなど)にファイル情報を渡す時に用いられるHFSFlavor構造体です。ここで注目すべきは、ファイルデータ(ファイルの中身)自体を渡すのではなく、ファイルタイプ、クリエータ、Finderフラグ、FSSpec構造体といったファイル情報を渡すという点です。例えば、ワープロがドラッグ&ドロップによりファイル情報を受け取ると、そのタイプからテキストなのか? 画像なのか?画像であればどんな種類なのか? を判断してから、FSSpec構造体を参照してデータを読み込み、作業用ウィンドウのドロップされた位置にそれを張り込むことになります。

    struct HFSFlavor {
                        OSType    fileType;       // ファイルタイプ
                        OSType    fileCreator;    // ファイルクリエータ
                        UInt16    fdFlags;        // Finderフラグ
                        FSSpec    fileSpec;       // FSSpec構造体
                    };
    


    以下のcreateDataMyDrag()ルーチンは、HFSFlavor構造体をAddDragItemFlavor()でドラッグアイテムとして登録しています。登録すべきファイルのFSSpec構造体は、自作ルーチンのgetMyTargetFSSpec()で得ていますが、この部分を適切な処理に差し替えれば、そのまま汎用ルーチンとして利用することが出来ます。ターゲットファイルのファイルタイプ、クリエータ、Finderフラグについては、FSpGetFInfo()を使えば得ることが出来ます。

    short createDataMyDrag( WindowPtr window,ControlRef chd,DragReference dref )
    {
        short        ret=1;
        FInfo        info;
        FSSpec       fsc;
        long         len;
        HFSFlavor    hfs;
    
        if( ! getMyTargetFSSpec( window,&fsc ) ) // ドロップファイルのFSSpecを得る
        {                                        // (自作ルーチン)
            FSpGetFInfo( &fsc,&info );           // ファイルのFinder情報を得る
            hfs.fileType=info.fdType;            // ファイルタイプ
            hfs.fileCreator=info.fdCreator;      // ファイルクリエータ
            hfs.fdFlags=info.fdFlags;            // Finderフラグ
            hfs.fileSpec=fsc;                    // 目的ファイルのFSSpec構造体
    
            len=sizeof( HFSFlavor );             // HFSFlavor構造体のサイズ
            ret=AddDragItemFlavor( dref,(ItemReference)1,kDragFlavorTypeHFS,
                                                            (Ptr)&hfs,len,0L );
                                                 // ドラッグアイテムに加える
        }
        return( ret );
    }
    


    Finderは、上記のドラッグアイテムを受け取ると、いったいどんな処理を実行するのでしょうか? それを試すのには、Adobe PhotoshopなどでJPEG画像をオープンし、ウィンドウタイトルに表示されるプロキシアイコンをデスクトップ上にドラッグ&ドロップしてみてください。対象となるJPEGファイルのアイコンは、ドロップされたデスクトップ位置へと移動させられます。また、オプションキーを押しながら実行すると、そのファイルは複製され、オプション+コマンドキーを押しながらだと、Aliasファイルが作成されることが分かります。つまり、Finder上でアイコンをマウス操作するのとまったく同じ処理を実行しているわけです。

    それでは、ドラッグ&ドロップでファイル情報を渡すのではなく、ファイルデータ(ファイルの中身)そのものを、別アプリケーションに渡したい時にはどうしたら良いのでしょうか? 普通に考えれば、データそのものをドラッグアイテムに追加してしまえば良いわけですが、ファイル容量が膨大(数100Mとか)であると、そのドラッグアイテムを作成するのに相当な時間がかかることになります。すると、ユーザが対象物をマウスドラッグしようとしても、それがマウス移動に追随できない状況が発生し、ドラッグ&ドロップの操作感を大きく損ねてしまいます。また、作業用メモリが不足し、処理を継続できない可能性も出てきます。

    そこで、Drag Managerには、実際のデータの受け渡しを、ドラッグ開始時ではなくドロップ時に行う仕組みが備わっています。つまり、ドロップ時であれば、少々時間がかかる処理であっても、ユーザの操作感は損なわれないわけです。この仕組みを用いると、ドラッグ開始時に大量データをドラッグアイテムに追加する処理を省略することができます。この時にドラッグアイテムとして利用するのが、以下のPromiseHFSFlavor構造体です。

    struct PromiseHFSFlavor {
                               OSType      fileType;        // ファイルタイプ
                               OSType      fileCreator;     // ファイルクリエータ
                               UInt16      fdFlags;         // Finderフラグ
                               FlavorType  promisedFlavor;  // 予約アイテムタイプ
                             }
    


    今回は、Finder上のドロップした位置に、ドラッグしてきたファイルの複製を作成してみます。また、複製されたファイルは、こちらで指定した文字列により名称変更がなされるとします。以下のcreateDataMyDrag()ルーチンで、PromiseHFSFlavor構造体をドラッグアイテムとして登録しています。加えて、オリジナルファイルのFSSpec構造体、名称変更用のパスカル文字列も追加します。そして最後に、アイテムタイプがkDragPromisedFlavorで、データが何も含まれていないドラッグアイテムをひとつ追加します。

    short createDataMyDrag( WindowPtr window,ControlRef chd,DragReference dref )
    {
        short             ret=1;
        FInfo             info;
        Str255            name;
        FSSpec            fsc;
        PromiseHFSFlavor  phf;
    
        if( ! getDuplicatetFSSpec( window,&fsc,name ) ) // 複製元ファイルのFSSpecと
        {                                               // 複製先名称を得る(自作)
            FSpGetFInfo( &fsc,&info );                  // Finder情報を得る
            phf.fileType=info.fdType;                   // ファイルタイプ
            phf.fileCreator=info.fdCreator;             // ファイルクリエータ
            phf.fdFlags=info.fdFlags;                   // Finderフラグ
            phf.promisedFlavor=kDragPromisedFlavor;     // kDragPromisedFlavorタイプ
    
            AddDragItemFlavor( dref,(ItemReference)1,'str ',(Ptr)&name,
                                                               sizeof(Str255),0 );
                                               // 名称変更用のパスカル文字列を追加
            AddDragItemFlavor( dref,(ItemReference)1,'fsc ',(Ptr)&fsc,
                                                               sizeof(FSSpec),0 );
                                                // 元ファイルのFSSpec構造体を追加
            AddDragItemFlavor( dref,(ItemReference)1,kDragFlavorTypePromiseHFS,
                                           (Ptr)&phf,sizeof(PromiseHFSFlavor),0 );
                                                // PromiseHFSFlavor構造体を追加
            ret=AddDragItemFlavor( dref,(ItemReference)1,kDragPromisedFlavor,
                                                                       NULL,0,0 );
                                                // kDragPromisedFlavorタイプを追加
        }
        return( ret );
    }
    


    次回は、今回のファイル複製処理の続きです。以前解説したstartMyDrag()の中で登録しておいたsendDataMyDrag()ルーチンについて詳しく解説します。ドラッグアイテムに追加されたPromiseHFSFlavor構造体やその他の情報は、このルーチンの中で解析されてファイル複製に利用されることになります。

    つづく

    SqueakではじめるSmalltalk入門   第43回  鷲見正人

     本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。前回までにファイルストリームの扱い方について触れたので、それにからめて、簡易ファイラである「ファイル・リスト」や、オブジェクトの“ファイル化”やユーザー間でのやりとりの方法について、しばらく順を追って解説してゆきたいと思います。

     MacのFinderやWindowsのExplorerほど高機能なものではありませんが、Smalltalkシステムにも「ファイル・リスト(file list)」と呼ばれる簡易ファイラがあります。ディレクトリの閲覧や作成、ファイルやディレクトリの削除、ファイルの名称変更などが可能です。加えて、ファイル内容の確認やその内容の編集など、テキストエディタのような機能も提供します。

     SqueakNihongo7でファイル・リストは、デスクトップメニューから「開く…」→「ファイル・リスト」で呼び出すことができます。

    [fig.A]ファイル・リスト
    http://squab.no-ip.com:8080/mosaren/uploads/43a.png

     もちろんメッセージ式のdo it (Cmd + D)でも起動可能です。

    FileList2 morphicView openInWorld

     なお、クラス名の最後に“2”とあるのは、以前のバージョンである「FileList」の存在を意味します。この“旧バージョン”のファイル・リストも次の式のdo itで起動して使用することができます。

    FileList openAsMorph openInWorld

    [fig.B]旧バージョンのファイル・リスト
    http://squab.no-ip.com:8080/mosaren/uploads/43b.png

     新バージョンといってもFileList2はFileListのサブクラスに過ぎません。文字通り、FileListの機能を継承し、それに拡張を施しただけの存在で、現時点ではまだ、FileListに置き換わるほどの“地位”を得ているわけではありません。将来、FileListがFileList2に踏みつぶされて機能しなくなり、さいごにはFileList2に吸収され消滅することもあるかもしれません。が、経験上それはかなり先の話になりそうです。なぜって、SqueakにはまだALTO時代のGUIフレームワーク(MVC)が生き残っていて、必要ならいつでも目覚めさせ、利用できるようになっているくらいなんですから!(デスクトップメニュー →「開く…」→「MVCプロジェクト」)

     それでは簡単に、(新バージョンの)ファイル・リストの機能を紹介してゆきましょう。

     ファイル・リストのウインドウは、おなじみのシステム・ブラウザやインスペクタと同様、機能を受け持つペイン(枠)で区切られています。おおまかには、上のペイン群はディレクトリやファイルの閲覧、下のペインは上のペインで指定したディレクトリやファイルの内容を表示するためのものです。なお、選択されたファイルがテキストファイルなら下のペインで編集、保存も可能です。

     上のペインはさらに左右のペインに分けられていて、左手がディレクトリ一覧、右手が左のペインで選択したディレクトリ内のファイル一覧に使われます。最上段のペイン左側の入力欄は、ファイル名のパターンでファイルの一覧を絞り込むためのものです。デフォルトでは全パターン「*」になっていますが、たとえばこれを「*.txt」などと変更後accept (Cmd + S)すれば、テキストファイルだけに限定して一覧できます。そのすぐ右側に並ぶボタン群は、ファイル一覧ペインの黄ボタンメニューでよく使う項目をボタン化して使いやすくしたものです。起動時には「name」「日付」「size」となっていて、ファイル一覧の並び順を変更できます(デフォルトは日付順)。Smalltalk関係のファイル(.st、.cs)や画像ファイルなどを選択すると、対応して、このペインのボタンが増えます。

    [fig.C]Smalltalkコードを収めたファイルを選択したとき
    http://squab.no-ip.com:8080/mosaren/uploads/43c.png

    [fig.D]画像ファイルを選択したとき
    http://squab.no-ip.com:8080/mosaren/uploads/43d.png

     たとえば、画像を選択したときは「読み込み」「開く」「background」という3つのボタンが追加されます。「読み込み」は画像ライブラリへの画像の登録、「開く」はその画像をオブジェクトとしてデスクトップに呼び出すとき、「background」はデスクトップ画像を選択画像に変更の際に使用します。いずれもファイル一覧ペインの黄ボタンメニューからも実行可能です。(それぞれ「画像をImageImportsに読み込みます」、「open graphic in a window」、「画像を背景として使います」に相当)

     「画像ライブラリ」とは、デスクトップメニューの「ヘルプ…」→「画像ライブラリ」で呼び出すことができるMac OS 9時代のスクラップブック(ただし画像専用)のようなソフトです。

    [fig.E]画像ライブラリ
    http://squab.no-ip.com:8080/mosaren/uploads/43e.png

     画像ライブラリから興味のある画像を取り出すには、まず、「Prev」「Next」ボタンでその画像を表示させ、つづけて「Prev」のすぐ左手のメニューアイコンをクリックしてポップアップするメニューから「hand me one」を選択します。

     なお、画像をSquaekシステム内に取り込む方法としては、このようにファイル・リストを使うほかに、Finderから画像ファイルのアイコンをSqueakのウインドウにドロップインする手軽な方法も用意されています。

     デスクトップに現われた画像オブジェクトは、不要ならば、Cmd-クリックで選択後、×ボタンをクリックすることで消去可能です(他に、右手中央の鉛筆ボタンでペイントツールによる加筆も可)。また、バックグラウンド画像を変更してしまった際には、デスクトップメニューの「元にもどす “背景画像の設定”」で元に戻すことができます。ファイル・リストとは直接関係ありませんが、以上、参考まで。

     次回はファイル・リストの簡易エディタ機能について紹介します。

    バックナンバー:
    http://squab.no-ip.com:8080/mosaren/

    ニュース・解説

    今週の解説担当:木下 誠

    ———————————————————————-
    Universal Binary Programming Guidelinesの日本語訳が登場
    ———————————————————————-
    IntelとPowerPCチップ両対応のバイナリを作るためのドキュメント、「Universal Binary Programming Guidelines」の日本語訳が、アップルのサイトで公開されました。

    このドキュメントには、チップのアーキテクチャの差、エンディアンの違いの解説、コンパイラの設定など、Intelチップ用のプログラムのための技術情報が詰まっています。Intelへの移行作業を行っている方はもちろん、これから新規にプログラムを書く方も必読です。あらかじめ、プログラムをできるだけエンディアンフリーにしておくことが大切になります。将来何が起こるか、まったく予想がつきませんからね。

    素早い日本語訳の登場は、評価したいと思います。この調子で、他のドキュメントも提供されると、うれしいのですが。

    Universal Binaryプログラミングガイド
    http://developer.apple.com/ja/documentation/MacOSX/Conceptual/universal_binary/

    ———————————————————————-
    Cocoa-Javaの終焉?
    ———————————————————————-
    先週の小池さんのニュースでもありましたように「Cocoa-Java Integration Guide」がアップデートされましが、その中に「10.4から後のCoocaの機能は、Cocoa-Javaに追加されない」という記述があります。これは、Cocoa-Javaのサポートが、10.4までで終了すると受け取れます。

    Cocoaプログラミングの窓口を広げるために導入されたJava APIでしたが、ここでおしまいになるようです。Javaの特徴として、プラットフォーム非依存や、静的な型を持つ傾向がありましたが、このあたりがCocoaとの相性が悪かったのかもしれません。

    今後、Cocoaの新規APIは、Objective-Cのみになるようです。もっとも、10.4までのCocoa-Javaでも、かなりのアプリケーションが作れるとは思います。

    Cocoa-Java Integration Guide
    http://developer.apple.com/documentation/index.html

    ———————————————————————-
    UTIの解説ドキュメント
    ———————————————————————-
    UTI (Uniform Type Identifiers)の使い方を解説したドキュメント、「Simplifying Data Handling with Uniform Type Identifiers」が公開されました。

    UTIは、ファイルの種類を特定する新しい手段として、導入されました。拡張子、MIMEタイプ、OSタイプなどから、統一的な新しいファイルタイプUTIが決定されます。UTIは、ドキュメントを扱うアプリケーションや、Spotlightなどで使われています。

    Simplifying Data Handling with Uniform Type Identifiers
    http://developer.apple.com/macosx/uniformtypeidentifiers.html

    ———————————————————————-
    QTKitのFAQ
    ———————————————————————-
    CocoaでQuickTimeを取り扱うためのフレームワーク、QTKitのTechnical Note、「QTKit Frequently Asked Questions」が公開されていました。様々な質問が取り上げられています。

    現在のQTKitは、基本的に「再生」に関する機能しかなく、高度な編集や作成、録音といった機能はありません。このドキュメントでは、将来のバージョンで、ムービーにトラックを追加したり、空のムービーを作成する機能が追加されるだろう、と述べられています。

    TN2138: QTKit Frequently Asked Questions
    http://developer.apple.com/technotes/tn2005/tn2138.html

    ———————————————————————-
    Enhanced Podcast作成のためのツール
    ———————————————————————-
    7/15日に、MOSA主催による「Podcastingセミナー」が開かれましたが、そこでEnhanced Podcastingを作成するためのツール、ChapterToolが紹介されました。ChpaterToolは、Appleが配布している、AACファイルにchapterを埋め込むためのツールです。

    ダウンロードするには、iTunes 4.9で、iTunes Music Storeに行きます。Podcastsの項目から、Publish Podcastsを選び、そこにある「Learn more about podcasting on iTunes」をクリックします。すると、ダウンロードページが表れます。

    このツールを利用することで、iTunes上で音声と画像を同期して再生することができるようになります。

    MOSAからのお知らせと編集後記は割愛します

    MOSA Developer News   略称[MOSADeN=モサ伝]
    Apple、Mac OSは米国アップルコンピュータ社の登録商標です。またそのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。
    このメールの再配信、および掲載された記事の無断転載を禁じます。
    特定非営利活動法人MOSA
    Copyright (C)2005 MOSA. All rights reserved.

  • MOSA Developer News[MOSADeN=モサ伝]第167号

    2005-07-12

    目次

    • 「WebObjects Dev Report」     第13回  田畑 英和
    • 藤本裕之のプログラミング夜話 #72
    • 高橋真人の「プログラミング指南」  第70回
    • ニュース・解説                小池 邦人

    「WebObjects Dev Report」  第13回  田畑 英和

     前回の続きとして、モデルファイルを作成するときのRelationの詳細設定について解説します。なおEOModelerの使い方については下記のドキュメントが公開されていますので、こちらもあわせて参照していただければと思います。

    ・Using EOModeler
    http://developer.apple.com/documentation/WebObjects/UsingEOModeler/

     さて前回は、MOSAUserとPrefecture Entityの間にRelationを設定するところまでを紹介しました。MOSAUser側からみると対1のRelation、Prefecture側からみると対多のRelationを双方向に設定しました。今回はRelationの詳細設定を解説したいと思いますが、まずはOptionalityの設定からみていくととにしましょう。

    Optionality

     Relationが設定されているということは、あるEntity上のデータがRelation先のEntitiy上のなんらかのデータと関係をもつということになります。このときRelationが設定されているからといってかならず関係するデータが必要なわけではありません。
     例えばMOSAUserのデータを登録する場合のことを考えてみましょう。データを登録するさいPrefecture(都道府県)の入力を省略可にする場合も考えられますし、省略不可にする場合も考えられます。
     実際どちらにするのかはどのようなデータを登録させたいかによりますが、省略可にした場合、Relationが設定されていたとしても、あるMOSAUserデータに関係するPrefectureのデータはあってもなくてもよいことになります。一方省略不可にした場合、あるMOSAUserデータには必ず関連するPrefectureのデータが1つ必要になります。
     こういったRelation先のデータの省略可/不可を設定するのがOptionalityの設定になります。Optionalityの設定は省略可か不可の2つだけで、それぞれ次のような呼び方をしています。

    ・Optional:省略可
    ・Mandatory:省略不可

     またRelationが設定されるということは、Relation先のデータのプライマリーキーを外部キーとして記録することになります。もしRelationをOptionalとして設定するのであれば、外部キーはNullである可能性(つまりRelation先のデータを省略する場合)がありますので、外部キーAttributeも省略可(Allows Null)の設定にしておく必要があります。

    Delete Rule

     Optionalityはデータを登録するときに影響する設定でしたが、次はデータを削除するときの設定です。データを削除する条件の設定としてDelete Ruleがあります。
     例えば、MOSAUserのデータを削除するとしましょう。MOSAUserにはRelationが設定されていますので、データの削除時にはRelationの参照をもつ他のデータに与える影響も考慮する必要があります。MOSAUserデータを削除するといっても、そのMOSAUserデータがRelation先として参照していたPrefectureデータはそのまま残しておくことになるでしょう。

     一方Prefectureのデータを削除する場合はどうでしょうか。Prefectureは都道府県のデータですので、一度登録してしまえば運用上削除するようなことはないかと思いますが、仮に削除するとしましょう。Prefectureは、MOSAUserに対して対多のRelationを設定していました。つまりあるPrefectureデータは複数のMOSAUserデータを参照しているかもしれません。Prefectureデータを削除してしまいますと、そのPrefectureデータをRelation先として設定してあった複数のMOSAUserデータの都道府県情報が失われることになります。こういった問題を防ぐには、Relation先としてなんらかのデータから参照されている場合、そのデータの削除を禁止するといった処置が必要になってきます。
     それでももしPrefectureデータを削除したいとしましょう。このとき問題になるのが削除するデータを参照していたデータの外部キーです。データが削除されると、もはや存在しないデータのプライマリーを外部キーとして持ち続けることになってしまいますので、データの不整合が生じます。ですのでデータを削除する場合には、そのデータをリレーション先として参照していたデータの外部キーをNullに設定する必要があります。

     さらにデータ構造によっては、あるデータの削除時にRelation先のデータも同時に削除してしまいたい場合もあるでしょう。こういったデータ削除時の設定として役立つのがDelete Ruleの設定です。Delete Ruleの設定には次の4種類があります。

    ・Nullify:削除データをRelation先として参照するデータの外部キーをNull
    ・Cascade:Relation先のデータも同時に削除
    ・Deny:他のデータからRelationの参照がある場合は削除を禁止
    ・No Action:なにもしない

     No Actionはデータの不整合を生じる危険性がありますので、使用する機会はないかもしれませんが、もしNo Actionの設定をおこなう場合は、データの整合性を保つ処理を明示的におこなう必要があります。

    設定方法

     Relationを設定したときには、今回説明したOptionalityやDelete Ruleの設定にも注意してください。どのような設定にするかはデータ構造や使用目的によって異なってきますが、双方向のRelationを設定した場合には、両Entity側のRelationでDelete Ruleの設定をおこなうことになりますのでご注意ください。
     実際にこれらの設定をおこなう方法ですが、EOModeler上でRelationを選択し、Inspectorを表示してAdvanced Relationship Inspectorの画面から設定をおこなうことができます。
     今回は予定していた多対多のRelationまで解説できませんでしたがまた次回に解説したいと思います。

    藤本裕之のプログラミング夜話 #72

     さて、今回からCocoaにおけるイベント・ハンドリングの説明をするために、この連載始まって以来のコード満載の話が始まるわけだが覚悟はよろしいであろうか。ご両親やお子さんに言い残したことはありませんか、死後に見つかって恥ずかしいファイルとかは処分しましたか……ってそういう覚悟ぢゃないか(笑)。

     まずXcode(Xcodeでありさえすればバージョンは大して問題ではない……はずである。とはいえ私はこれをXcode2.1でやっているので、ここに書いた通り動作しない場合は2.1でやってみてほしいが)を起動し、Fileメニューから「New Project…」を選択、当然だけど「Cocoa Application」を選ぶ。
     これでスケルトンというか、何もしないWindowが一個出るだけのプロジェクトが出来上がったはずである。時間のあるヒトは一度実行して動くことを確認するべし。あ、実行にあたっては「Build & Run」ではなく「Build & Debug」を選んでほしい。そうするとGDBのウィンドウが開く。そのウィンドウに十分な横幅があれば、ツールバーの一番右に「Console」というアイコンがあるはずなので、これをクリックして「Debugger Console」のウィンドウも開いておくと後々便利である。

     動作を確認したらこれを終了し、プロジェクト・ウィンドウの「Group &Files」の中の「MainMenu.nib」をダブルクリックしてInterface Builderを起動しよう。そして……こういうのを文章だけで説明するのは難しいんだが、さっき出たウィンドウに、(*)パレットから「Custom View」というのをドラッグ&ドロップしてほしい。できましたか? そしたらそれを……ウィンドウの真ん中あたりで、だいたい上下左右に1cmくらい余白がでるくらいにリサイズする。次に「MainMenu.nib」というウィンドウを前面に持ってきて、「Classes」タブを押し、NSObject->NSResponder->NSViewを選んでリターンキーを押す。つまりNSViewのサブクラスを作るわけ。これを「MyBigView」と名付け、Classes メニューから「Create Files For MyBigView」を選んでソースファイルを生成する。ウィンドウの中の「CustomView」を選択し、インスペクタ・ウィンドウの「Custom Class」を選択してこのビューを今作った「MyBigView」とする。
     ここまで来たら、*印繰り返し(笑)。パレットからもう一度「Custom View」をこの「MyBigView」の内側にドラッグ&ドロップして同じ手順、ただしこっちはクラス名を「MySmallView」にする。ウィンドウのなかにちょうど漢字の「回」のように包含関係にある2つのビューが見え、プロジェクトのディレクトリ内に「MyBigView.h」「MyBigView.m」「MySmallView.h」「MySmallView.m」という4つのファイルが出来ていたらOKである。

     InterfaceBuilderを終了してXcodeに戻ったら、とりあえず2つのビューが目に見えるようにそれぞれのクラスの「drawRect:」を以下のようにする。

    /* MyBigView.m の drawRect */
    -(void) drawRect:(NSRect) rect {
    
      [[NSColor grayColor] set];
      [[NSBezierPath bezierPathWithRect:[self bounds]] fill];
    }
    
    /* MySmallView.m の drawRect */
    -(void) drawRect:(NSRect) rect {
    
      [[NSColor blackColor] set];
      [[NSBezierPath bezierPathWithRect:[self bounds]] fill];
    }
    


     そして今回の眼目、MyBigViewの方にだけ、mouseDown: というメソッドを以下のように定義する。言わずもがなと思うけど、これはNSResponderのmouseDown:をオーバーライドしてることをお忘れなく。

    -(void) mouseDown:(NSEvent*) theEvent {
    
      NSLog(@"MyBigView received 'mouseDown:' message");
    
    }
    


     これをビルドして「デバッグ」する。と、内側の黒いビューをクリックしても上のメッセージがConsole ウィンドウに出力されるのである。もちろんグレイの部分をクリックしても同じ。これはどういう仕組みでこうなっているんでしょう、というのが次回のお話である。どっとはらい。
    (2005_07_07)

    高橋真人の「プログラミング指南」第70回

    UNIXとしてのMac OS X

    〜Perlについて(16)〜

     こんにちは、高橋真人です。
     さて前回の最後にご紹介しましたs///演算子ですが、これは演算子としてはかなり不思議な見た目をしています。他の多くのプログラミング言語における演算子と比較した場合はもちろんのこと、Perlにおける演算子というイメージからもかけ離れています。しかし、それでもこの演算子はPerlにおいては重要な位置を占め、なくてはならない存在として異彩を放って(?)いるのです。
     使い方としては、既に紹介した以下のような形が普通です。

    $string =~ s/ABC/123/;

     s///は置換をするための演算子ですが、この演算子と文字列をつないでいるのもまた演算子です。この「=~」をパターン結合演算子と呼んでいます。
     ところで、多くのPerlの演算子と同様にs///演算子も、既におなじみの$_変数と共に使うことができます。つまり、検索置換対象の文字列が$_変数の中に格納されている場合には、単に以下のような書き方をするだけでよいのです。

    s/ABC/123/;

     あまりにシンプルな表現なので、少し違和感を持たれるかもしれませんが、すぐに慣れます(笑)。私の場合、入門の早いうちにこっちの書き方を先に学んだので、むしろこの方がしっくりきます。
     ちなみに、Perlで簡単なテキストフィルタを書く場合に典型的な書き方は以下のような形です。

    while (<>) {
        s/a/A/g;
        print;
    }

     まだ触れていないことがたくさん盛り込まれているので少し分かりにくいかもしれませんが、これだけで標準入力からテキストを一行ずつ読み込み、小文字のaがあったら大文字のAに変換した上で標準出力に書き出すという処理になります。
     以前CGIを解説した時に説明したように、ファイルの先頭に#!/usr/bin/perlと加えてからスクリプトファイル自体に実行権限を与えてやると、このままテキストフィルタのコマンドとして機能します。
     例えば、テキストファイル(test.txt)がスクリプトファイル(convert.pl)と共にホームディレクトリにあった場合、ターミナルを開いて以下のように打ち込むと、

    Mac:~ mosa$ cat test.txt | ./convert.pl > out.txt

     out.txtという名のテキストファイルが作成され、s///演算子によって変換された結果が書き込まれます。もちろん、out.txtという名のファイルが存在していた場合には上書きされてしまうので注意してください。もっとも、その代わりと言うか、上記のout.txtの部分をtest.txtと元のファイル名にしますと、対象ファイル自体を書き換えることができます。

     さてパターン結合演算子は、決してs///演算子の専用ではありません。実はPerlにはm//演算子というのもありまして、これはパターンにマッチするかどうかをテストするためのものです。ところで、以前にパターンマッチの表現を使った時に、正規表現の両側をスラッシュで囲んでいたのを憶えていますか?
     実はm//演算子では、mを省略して書かれることが多いのです。つまり、今までもたびたび登場していた正規表現パターンの表記にはこのm//演算子を使っていたというわけです。
     //もしくはm//を使った正規表現では、改めて言うまでもなく暗黙に$_が対象となっていました。ですから上で説明してきたことと同様に、$_変数に格納された文字列以外のものとパターンマッチングさせたい場合には、パターン結合演算子を使うことになります。
     例えば以前、カラの行または文字列かどうかを判断するために、

    if (/^$/)

    という書き方をしましたが、検査の対象が$_でなく$stringの場合には、

    if ($string =~ /^$/)

    というように書きます。
     もっとも、文字列がカラかどうかを検査するのに正規表現を使うのは少し冗長なのですけれども。

    ニュース・解説

    今週の解説担当:小池邦人

    Carbon ドキュメント & サンプル & SDK ナビゲーション(2005/7/08)

    【開発環境】

    開発してきた自作アプリケーションをx86コードへ移行させる準備として「Universal Binary Programming Guidelines」をざっと読んでみました。しかし、ドキュメントの最後に、PowerPlant用”PPob “リソースのFlipper(エンディアン反転ルーチン)のサンプルソースコードが載っているのには笑ってしまいましたが…。筆者は、開発環境としてMetrowerks CodeWarriorを使い、Carbon+NibファイルでMach-Oアプリケーションを開発しています。PowerPlant等の特別なフレームワークには依存していませんので、プロジェクトをXcodeへ移行するのは簡単です(ほんの数十分)。基本的にはエンディアンとAltiVecの問題だけをクリアすれば、トランジションはそこそこ達成できそうです。ついでに、CodeWarriorがMach-OのX86コードに対応してくれるようになれば、もっと楽なんですけどね(笑)。

    それから、今更という感じもありますが(笑)、IBMから新しいPowerPC 970プロセッサが発表されました。以前、このニュースでも開発の噂を取り上げたデュアルコアバージョンの「PowerPC 970MP」と、低電圧版の「PowerPC 970FX」です。Intel CPUへの移行までにはまだ随分と時間がありますので、この両プロセッサを搭載したMacintoshが登場するのは間違いないと思われます。しかし、970MPの方は2.5GHzまでしかクロックが上がっていないので、現行マシン(2.7GHz)との差別化を考えると、このCPUをDualで搭載(4 Core)したPowerMacが登場する可能性が高いかもしれません?一番の注目は、低電圧版の970FXを搭載したPowerBook G5が登場するかという点ですが…う〜ん、今となっては何とも言い難いところです(笑)。

    【テクニカルドキュメント】

    前回から7月8日の期間中、Apple社のDocumentationサイトには大量のドキュメントが登録されました。また、デベロッパー向けの読み物がひとつだけ登録されています。ただし、登録されたドキュメントのほとんどが、マイナーな変更(Minor Change)のみです。今回は、その中で「Content Update」と「First Version」と併記されているドキュメントのみをピックアップしてみました。ただし、初版(First Version)のドキュメントとは「Core Endian Reference」のみです。ソースコードをx86への移行させる時に利用するエンディアン反転用のAPIリファレンスです。TIFFやExifファイルの読み込みなどの用途にも利用できるでしょう。

    「Cocoa Bindings Programming Topics」(内容更新)
    「Cocoa Tutorial for Java Programmers」(内容更新)(PDFあり)
    「Cocoa-Java Integration Guide」(内容更新)
    「Core Endian Reference」(初版)(PDFあり)
    「Multiprocessing Services Programming Guide」(内容更新)(PDFあり)
    「Quartz 2D Reference」(内容更新)
    「QuickTime API Reference」(内容更新)
    「QuickTime Overview」(内容更新)(PDFあり)
    「Sync Services Tutorial」(内容更新)
    「Text Services Manager Reference」(内容更新)(PDFあり)
    「Transferring Data With URL Access Manager」(内容更新)(PDFあり)
    「URL Access Manager Reference」(内容更新)(PDFあり)

    http://developer.apple.com/documentation/index-rev-date.html

    「Ready for the Future: Chronos Switches to Cocoa」(読み物)

    http://developer.apple.com/business/macmarket/chronos.html

    前回から7月8日の期間中、テクニカルノートはひとつだけ登録されました。また、新規テクニカルQ&Aの方は3つ登録されています。TN2144とQA1394については前号の木下さんの記事を参照してみてください。

    TN2144「Detecting low printer ink levels」

    http://developer.apple.com/technicalnotes/index-rev-date.html

    QA1438「Using the QuickTime DVCompressor properties」
    QA1429「Deprecated CALL_ON_[UN]LOAD pragmas」
    QA1394「Using NSSound with CoreAudio on Mac OS 10.3.x」

    http://developer.apple.com/technicalqas/index-rev-date.html

    【サンプルソースコード】

    前回から7月8日の期間中、Apple社のSample Codeサイトには、新しいサンプルソースコードが4つ登録されました。詳しい内容については前号の木下さんの記事を参照してみてください。

    「AlbumToSlideshow」(CFXML&NSXML関連)
    「QTAudioExtractionPanel」(QuickTime関連)
    「ScriptingDefinitions」(AppleScript関連)
    「TextTrack」(AppleScript関連)

    http://developer.apple.com/samplecode/index-rev-date.html

    【デベロップメント SDK】

    前回から7月8日の期間中、Apple社のSDKサイトには新しいSDKが3つ登録されました。
    ひょっとして、かなり以前に登録されていたかもしれませんが、申し訳ない!気づいていませんでした(笑)。「FireWire SDK 20 for Mac OS X」と「Image Capture SDK for Mac OS X v10.4」は、Mac OS X 10.4(Tiger)に対応したバージョンです。

    「QuickTime 7.01 SDK 」
    「FireWire SDK 20 for Mac OS X」
    「Image Capture SDK for Mac OS X v10.4」

    http://developer.apple.com/sdk/

    MOSAからのお知らせと編集後記は割愛します

    MOSA Developer News   略称[MOSADeN=モサ伝]
    Apple、Mac OSは米国アップルコンピュータ社の登録商標です。またそのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。
    このメールの再配信、および掲載された記事の無断転載を禁じます。
    特定非営利活動法人MOSA
    Copyright (C)2005 MOSA. All rights reserved.

  • MOSA Developer News[MOSADeN=モサ伝]第166号

    2005-07-05

    目次

    • 「WebObjects Dev Report」    第12回  田畑 英和
    • 小池邦人の「Carbon API 徒然草」
    • SqueakではじめるSmalltalk入門  第42回  鷲見 正人
    • ニュース・解説               木下 誠

    「WebObjects Dev Report」  第12回  田畑 英和

     今回はEntity間の関係を定義するRelationについて解説したいと思います。通常1つのモデルファイルの中には通常複数のEntityが存在し、それらはお互いに関係をもつことにより、複雑なデータ構造を定義することができます。

    Relationの種類

     Relationにはいくつかの種類がありますが、まずはどのような種類があるかをおさえておきたいと思います。具体的には以下の3種類があります。

    (1)対1
    (2)対多
    (3)多対多

     例えば住所Entityと都道府県Entityがあったとしましょう。住所Entityには名前のとおり住所データが格納されていて、都道府県Entityには計47の都道府県データが格納されているとします。このとき住所Entityと都道府県Entityの間にRelationを設定することにより、それぞれお互いのEntityを参照できるようになります。
     Relationは双方向に設定する場合と、片方向のみ設定する場合がありますがまずは双方向に設定したとしましょう。住所Entityからみるとリレーション先の都道府県Entityのレコードのどれか1つを参照することになります。この場合(1)の対1のRelationとなります。逆に都道府県Entityからみてみますと、都道府県Entityのある1レコードからは、住所テーブルの複数のレコードを参照することになります。この場合(2)の対多のRelationとなります。
     住所Entityから都道府県Entityの参照だけができればよい場合には、住所Entityからの片方向のRelationのみを設定することができます。また各都道府県の住所一覧も取得したいような場合には、都道府県EntityからのRelationも設定し双方向のRelationを定義することもできます。

    Relationの設定方法

     (3)の多対多の場合は次回解説するとして、モデルファイル上でどのようにRelationを設定するかを説明しておきます。前回の連載では、MOSAUserというEntityを作成しましたが、ユーザ情報として都道府県の情報を追加したいと思います。
     このときMOSAUserに都道府県用のAttributeを追加するという方法もありますが、この方法では拡張するにしたがってEntityが肥大化することになりますし、都道府県のようなデータの場合、各レコードに重複するデータが何度も入力されることになります。
     そこでMOSAUserとは別に都道府県用のEntityを追加し、Relationを設定することによって効率的なデータ構造を定義することができます。まずは都道府県用のEntityですが、以下のように定義してみました。

    Prefecture Entity

    ・プライマリーキー
    prefId, PREF_ID, Number, int
    ・都道府県名
    prefName, PREF_NAME, String, char(32)
    ・表示順
    order, ORDER, Number, int
    prefId, PREF_ID, Number, int
    ※左からAttribute名、カラム名、Javaデータタイプ、OpenBaseデータタイプ

     都道府県名を格納するAttribute(prefName)を設定し、都道府県の一覧を表示するときのために表示順のAttribute(order)も追加してみました。英語データの場合はアルファベット順での表示ができますが、日本語データの場合はなんらかの方法でソート順を設定する必要がありますので、こういった工夫が必要になります。

     これで都道府県用のEntityが追加できましたが、Relationを設定するためにはMOSAUser側にRelation用のAttributeを追加する必要があります。各Entityには各レコードをユニークに識別するためのプライマリーキー(主キー)がありますが、Relationの設定をおこなうには外部キーの追加をおこなう必要があります。
     外部キーですが、対1のRelationを設定するEntity側にRelation先Entityのプライマリーキーを追加します。つまりMOSAUserにPrefectureのプライマリーキーを外部キーとして追加します。EOModeler上ではAttributeをコピー&ペーストできますので、あるEntity上のAttributeを別のEntityに簡単に追加することができます。このとき外部キーもプライマリーキーと同様にEOFによって自動的に管理されますので、外部キーのClass Propertyの設定はOffにしておきます。

     では最後に実際にRelationを設定する方法ですが、一番直感的な方法を紹介しておきます。まずはEOModelerでDiagram View(Toolsメニューから実行)に切り替えて、Ctrlキーを押しながらPrefectureのprefIdを、MOSAUserのprefIdまでドラッグアンドドロップします。そうするとEntity間に線が引かれて双方向のRelationが自動的に設定されます。このときRelation名は自動的に設定されますが、必要に応じて変更することも可能です。

     このようにしてEntityおよびRelationを設定していくことができます。それでは次回はRelationの詳細設定と今回取り上げなかった多対多のRelationについて解説したいと思います。なおモデルファイルですが、WebObjectsのサンプルにモデルファイルが付属していますので、そちらも参考にしてみてください。

    ・モデルファイルのサンプル
    /Developer/Examples/JavaWebObjects/Frameworks/JavaBusinessLogic/Movies.eomodeld

    小池邦人のCarbon API 徒然草(2005/07/01)

    ドラッグ&ドロップの活用(その5)

    今回からは、前回紹介したドラッグ&ドロップにおけるSend処理の手順を追って行きます。まずは、startMyDrag()内で実行されているcreateDataMyDrag()ルーチンの紹介です。ドラッグ&ドロップで受け渡すデータの種類が変わることで、そのデータを登録する処理がどのようになるかを調べてみます。

    Drag Managerでは、Send処理で受け渡すデータを「ドラッグアイテム」と呼びます。ドラッグアイテムのうち幾つかの種類については、アプリケーション同士が暗黙のうちに認識できるように、種類やその内容がOS標準として定義されています。例えば、Mac OS 9時代に頻繁に利用していたスクラップブックに保存されていた画像やテキストデータなどがそうです。まず最初に、クリップボードに保存されているPICT画像を、ワープロやペイントアプリケーションへ渡す場合のドラッグアイテムの作り方を取り上げてみます。以下のgetClipbord()は、クリップボードから任意のデータを取り出す簡単なルーチンです。

    short getClipbord( Handle *hd,ScrapFlavorType type )
    {
        Size        size;
        ScrapRef    sref;
    
        GetCurrentScrap( &sref );               // 現在のクリップボードを得る
        GetScrapFlavorSize( sref,type,&size );  // 指定タイプのデータサイズを得る
        if( size )                              // 指定タイプのデータが存在する
        {
            if( *hd=NewHandle( size )  )        // サイズと同容量のハンドラを確保
            {
                HLock( *hd );                   // ハンドラをロック
                if( ! GetScrapFlavorData( sref,type,&size,**hd ) ) // データを得る
                {
                    HUnlock( *hd );             // ハンドラのアンロック
                    return( noErr );
                }
                DisposeHandle( *hd ); // 確保に失敗した場合にはハンドラを解放
            }
        }
        return( 1 );
    }

    Send処理で好みのデータを受け渡したい場合には、AddDragItemFlavor()を利用して現在のDragReferenceへ新規ドラッグアイテムを追加します。以下のcreateDataMyDrag()ルーチンでは、クリップボードから抽出したPICT画像(PicHandle)を、AddDragItemFlavor()でドラッグアイテムとして登録しています。このドラッグアイテムをデスクトップへドロップすると、Finderによりクリッピングファイル(Mac OS Xであればピクチャクリッピング)が作成されることになります。ここで注意することは、AddDragItemFlavor()で渡したデータはシステム内部で複製されますので、渡した後のオリジナルの方は削除(不必要であれば)している点です。そうしないと、ドラッグ&ドロップするたびに不必要なメモリ領域が消費されていくことになります。

    short createDataMyDrag( WindowPtr window,DragReference dref )
    {
        short        ret=1;
        PicHandle    pict;
        long         len;
    
        if( ! getClipbord( (Handle *)&pict,'PICT' ) )
                                               // クリップボードからPICT画像を得る
        {
            HLock( (Handle)pict );             // PicHandleをロックする
            len=GetHandleSize( (Handle)pict ); // PicHandleのサイズを得る
            ret=AddDragItemFlavor( dref,(ItemReference)1,'PICT',(Ptr)*pict,len,0 );
                                               // データをドラッグアイテムに追加する
            KillPicture( pict );               // PicHandleを削除する
        }
        return( ret );
    }
    


    getClipbord()に渡すデータタイプを’PICT’から’TEXT’へ変更すれば、クリップボードに保存されている文字列データを別アプリケーションへ渡すことが可能になります。

    short createDataMyDrag( WindowPtr window,DragReference dref )
    {
        short    ret=1;
        Size     len;
        Handle   hd;
    
        if( ! getClipbord( &hd,'TEXT' ) )
                                          // クリップボードからテキストデータを得る
        {
            HLock( hd );                  // ハンドラをロックする
            len=GetHandleSize( hd );      // ハンドラのサイズを得る
            ret=AddDragItemFlavor( dref,(ItemReference)1,'TEXT',*hd,len,0 );
                                          // データをドラッグアイテムに追加する
            DisposeHandle( hd );          // ハンドラを削除する
        }
        return( ret );
    }
    


    次は、ImageWellコントロールに表示されているPICT画像をドラッグアイテムに加えてみましょう。ImageWellコントロールは、PICT画像だけでなくアイコンなども表示することが可能です。表示されているデータは、ControlButtonContentInfo構造体に適切な情報を代入してGetImageWellContentInfo()に渡すことで得ることができます。contentTypeメンバーに画像の種類をセットすれば、そのデータへの参照パラメータ(リファレンス)については、次に続くUnion構造体のメンバーに代入されて返ります。

    struct ControlButtonContentInfo {
      ControlContentType  contentType;
      union {
                 SInt16            resID;
                 CIconHandle       cIconHandle;
                 Handle            iconSuite;
                 IconRef           iconRef;
                 PicHandle         picture;
                 Handle            ICONHandle;
                 CGImageRef        imageRef;
             } u;
    };
    


    今回欲しいのは表示されているPICT画像のPicHandleですので、info.contentTypeにはkControlContentPictHandleをセットします。もし、ImageWellコントロールにPICT画像が表示されていれば、info.u.pictureにその画像のPicHandleが返されます。クリップボードの時と同様に、これもオリジナルの複製となりますので注意してください。

    short getMyControlWellPict( ControlRef chd,PicHandle *pict )
    {
        ControlButtonContentInfo    info; // ImageWellの内容物を指示するための構造体
    
        *pict=info.u.picture=NULL;                   // PicHandleの初期化
        info.contentType=kControlContentPictHandle;  // PicHandleを返すように指示
        if( ! GetImageWellContentInfo( chd,&info ) ) // ImageWellの内容物を得る
        {
            if( info.contentType==kControlContentPictHandle ) // タイプはPICTか?
                *pict=info.u.picture;       // そうであれば得られたPicHandleを返す
        }
        if( *pict )                         // PicHandleが返れば正常終了
            return( noErr );
        return( 1 );
    
    }

    以下のcreateDataMyDrag()ルーチンでは、ImageWellコントロールに表示されているPICT画像をドラッグアイテムに加えています。どのコントロールなのかは、引数で渡されてくるControlRefで判断するのですが、それ以外の処理内容は、クリップボード経由の場合とほとんど同じとなります。

    short createDataMyDrag( WindowPtr window,ControlRef chd,DragReference dref )
    {
        short        ret=1;
        PicHandle    pict;
        long         len;
    
        if( ! getMyControlWellPict( chd,&pict ) ) // ImageWellの表示PICT画像を得る
        {
            HLock( (Handle)pict );                // PicHandleをロックする
            len=GetHandleSize( (Handle)pict );    // PicHandleのサイズを得る
            ret=AddDragItemFlavor( dref,(ItemReference)1,'PICT',(Ptr)*pict,len,0 );
                                                  // データをドラッグアイテムに追加
            KillPicture( pict );                  // PicHandleを削除する
        }
        return( ret );
    }
    


    次回は、ファイル情報をアプリケーションからFinderにドラッグ&ドロップしたい時のドラッグアイテムの追加方法を紹介します。具体的には、ドラッグアイテムとして渡すことになる、HFSFlavor構造体とPromiseHFSFlavor構造体の「使い分け」を解説します。

    つづく

    SqueakではじめるSmalltalk入門   第42回  鷲見正人

     本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。

     ストリーム(a Stream)は「絶え間のないデータの流れ」を表現するオブジェクトで、磁気ヘッド(position)を使って磁気テープ(基になるコレクション)から情報を読み(next)書き(nextPut: anObject)できることを前回示しました。見方を変えると、ストリームは最後に読み出した場所を覚えていてくれる、ちょっと変わったコレクションの一種だと考えることもできます。実際、ストリームにはコレクションの特徴的なメソッドでもある#do:も定義されていて期待通りの動作をします。

    | stream |
    stream _ 'abcdefg' readStream.
    World findATranscript: nil.
    Transcript cr.
    stream do: [: each | Transcript show: each asUppercase]
    " => ABCDEFG (トランスクリプトへの出力) "

     さて。今回は外部ストリーム、つまりファイル情報にアクセスするためのストリームについてです。と、申しましてもこのオブジェクトについては、

    (FileStream fileNamed: ‘test.txt’) edit

    のような式において、editメッセージを受けるレシーバとしてすでに登場済みです。ただ、このeditによって起動されるメソッドFileStream >> #editはファイルリスト(a FileList)というオブジェクトと連携して少々ややこしいことをしていますので、まずは、オーソドックスなファイルストリームの扱いを見てみましょう。

     ファイルストリームも、前回紹介した内部ストリームとほとんど同じように扱えます。ちょっと違うのは、内部ストリームを作るときは基になるコレクションを指定したのに対し、ファイルストリームではファイル名を指定すること。また、ストリームを使い終わったらデバイスを解放するためにそれを“閉じる”必要があることです。たとえば、FileStreamExample.txtという名前のファイルを作って、そこに文字列を書き込む式は次のようになります。

    | stream |
    stream _ FileStream fileNamed: 'FileStreamExample.txt'.
    stream nextPutAll: 'abcdefg'.
    stream close

     「読み」と「書き」それぞれ専用のものがあった内部ストリームと違って、ファイルストリームは読み書き共用です。nextを送れば、データの読み出しもできます。

    | stream |
    stream _ FileStream fileNamed: 'FileStreamExample.txt'.
    World findATranscript: nil.
    Transcript cr.
    [stream atEnd] whileFalse: [Transcript show: stream next asUppercase].
    stream close
    


     もちろん必要ならば読み出し専用のストリームにもできますが、モードのようなものを切り換えているだけで、内部ストリームのように属するクラスを使い分けているわけではありません。

    | stream |
    stream _ FileStream readOnlyFileNamed: 'FileStreamExample.txt'.
    [stream nextPut: $a] ensure: [stream ifNotNil: [stream close]].
    " => Error: Cannot write a read-only file "
    
    (FileStream fileNamed: 'FileStreamExample.txt') class
       " => MultiByteFileStream "
    (FileStream readOnlyFileNamed: 'FileStreamExample.txt') class
       " => MultiByteFileStream "

     ここで、FileStreamにメッセージを送っているのに、出てきたストリームがMultiByteFileStreamのインスタンスであるというのはオカシイ…と気付かれた方もおられることと思います。この疑問はFileStream >> #fileNamed:をブラウズするとすぐに解決できます。

    FileStream >> fileNamed: fileName
       ^ self concreteStream fileNamed: (self fullName: fileName)

     self、つまり、この文脈ではFileStreamというクラス自身にconcreteStreamというメッセージを送って、その返値に改めて「fileNamed: …」というメッセージを送りなおしています。concreteStreamの送信に対する返値がおそらくMultiByteFileStreamで、FileStream fileNamed: … は、実際にはMultiByteFileStream fileNamed: …と等価なのだろう…ということは容易に想像できると思います。このことを確認するには、FileStream >>#concreteStreamの定義を見ます。FileStream >> #fileNamed:を閲覧中のブラウザで、implementorsボタンのポップアップから「concreteStream」を選ぶなどして、新しいブラウザを開いてみてください。どうです? 予想どおりですね。

    FileStream >> concreteStream
       ^ MultiByteFileStream

     さて。日本語の書き出しもしてみましょう。

    | stream |
    stream _ FileStream fileNamed: 'NihongoExample.txt'.
    stream nextPutAll: '日本語の文字列'.
    stream close

     内容を確認してみます。

    | stream contents |
    stream _ FileStream fileNamed: 'NihongoExample.txt'.
    contents _ stream contents.
    stream close.
    ^ contents   " => '日本語の文字列' "

     問題ないですね。だだ、SqueakNihongo7はデフォルトでは文字コードにUTF-8を使って日本語文字列を出力するので、シフトJISを期待する他のソフトでは文字化けしてしまいます。

     a MultiByteFileStreamでは、読み書きにテキストコンバータ(a TextConverter)というオブジェクトが介在し、あらかじめ決められた文字コードで読み書きが行なわれています。

    (FileStream fileNamed: 'test.txt') converter
       " => an UTF8TextConverter "

     Mac OSではシフトJISが多く使われるので、an UTF8TextConverterの代わりにシフトJISを理解するテキストコンバータに代えてやれば、UTF-8からの変換の手間を省くことができて便利です。

    | stream |
    stream _ FileStream fileNamed: 'ShiftJisExample.txt'.
    stream converter: ShiftJISTextConverter new.
    stream nextPutAll: 'シフトJISの日本語文字列'.
    stream close

     TextConverterのサブクラスを見れば、使用可能なコンバータを一覧できます。

    TextConverter subclasses
    " =>  #(CompoundTextConverter EUCTextConverter MacRomanTextConverter
            ShiftJISTextConverter UTF8TextConverter Latin1TextConverter
            CP1253TextConverter ISO88597TextConverter UTF16TextConverter
            CP1250TextConverter ISO88592TextConverter) "

    バックナンバー:
    http://squab.no-ip.com:8080/mosaren/

    ニュース・解説

    今週の解説担当:木下 誠

    ———————————————————————-
    Cocoaへのスイッチ記事
    ———————————————————————-

    ADCで、アプリケーションのCocoaへのスイッチ紹介記事、「Chronos Switches to Cocoa」が公開されていました。StickyBrainという、ノートパッドタイプのアプリケーションを、Cocoaベースで書き直した、という記事です。

    この記事では、デベロッパにCocoaへの移行のメリットを説いています。今後、Universal Binaryの導入もあることですし、CocoaやXcode環境への移行が強調されることでしょう。

    Chronos Switchs to Cococa
    http://developer.apple.com/business/macmarket/chronos.html

    ———————————————————————-
    プリンタのインクの残量を調べる
    ———————————————————————-

    Technical Noteで、プリンタのインクの残量を調べる方法が公開されています。

    Mac OS X 10.4からは、IPプリンタに対して、コマンドラインツールsnmpInkを使うことで、インクの残量を調べることができるようになりました。snmpInkは調査結果をXMLで返すのですが、この記事でそのXMLのキーの解説をしています。

    TN2144: Detecting low printing ink levels
    http://developer.apple.com/technotes/tn2005/tn2144.html

    ———————————————————————-
    NSSoundとCoreAudioを同時に使う
    ———————————————————————-

    Technical Q&Aで、10.3.xで、NSSoundとCoreAudioを同時に使う際のバグと、その回避方法が説明されています。

    10.3.xでは、NSSoundの実装とCoreAudioの実装が、ハードウェアの抽象レイヤー(HAL)で干渉してしまうバグがあるそうです。これを避けるには、NSSoundのインスタンスが作られる前に、CoreAudioで適切な処理をする必要があるそうです。

    QA1394: Using NSSound with CoreAudio on Mac OS 10.3.x
    http://developer.apple.com/qa/qa2005/qa1394.html

    ———————————————————————-
    サンプルが4つ公開
    ———————————————————————-

    TextTrack:
    AppleScriptとPerlスクリプトを使って、Final Cut ProのXMLファイルを操作するサンプルです。
    http://developer.apple.com/samplecode/TextTrack/TextTrack.html

    AlbumToSlideshow:
    CoreFoundationとNSXMLを使って、Final Cut ProのXMLファイルを操作します。iPhotoのアルバムデータをFinal Cut Proにインポートします。
    http://developer.apple.com/samplecode/AlbumToSlideshow/AlbumToSlideshow.html

    QTAudioExtractionPanel
    QTKitのサンプルです。WWDCで使われたサンプルQTKitPlayerを拡張して、オーディオトラックにアクセスできるようになっています。
    http://developer.apple.com/samplecode/QTAudioExtractionPanel/QTAudioExtractionPanel.html

    ScriptingDefinitions
    AppleScriptの定義ファイルである、.sdefファイルのサンプルです。
    http://developer.apple.com/samplecode/ScriptingDefinitions/ScriptingDefinitions.html

    MOSAからのお知らせと編集後記は割愛します

    MOSA Developer News   略称[MOSADeN=モサ伝]
    Apple、Mac OSは米国アップルコンピュータ社の登録商標です。またそのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。
    このメールの再配信、および掲載された記事の無断転載を禁じます。
    特定非営利活動法人MOSA
    Copyright (C)2005 MOSA. All rights reserved.