ディー・アート刊
Macintosh
アプリケーションプログラミング 　上・下

新居雅行　著　　　　　　 定価　　各\3,800

読者サポートコーナー　 Internet読者カード◇ 誤植・訂正◇ Q&A◇ 追加情報

書籍のご紹介

• Macintoshのアプリケーション作成法を説明しています。ソースプログラムは、C言語を利用して作成しています。
• Symantec C++およびCode Warriorでコンパイルして実行できるサンプルアプリケーションのソースを、上巻に添付したフロッピーディスクで提供します。
• Inside Macintoshに紹介されているシステムルーチンのうち、一般的なアプリケーションに必要なものをリファレンスできます。

サンプルアプリケーションの特徴は以下の通りです。これらの機能をプログラム上で実現する方法について、書籍およびサンプルソースで解説します。

• マルチウインドウ、メニューを含む、一般的な書類作成機能をサポート
• ドローソフトのように、テキスト、リスト、ピクチャーなどのオブジェクトをウインドウ上に配置し、書類ファイルへ保存できる
• Macintosh Drag and Dropに対応し、オブジェクトをスクラップブックやFinder上にもドラッグ&ドロップ可能
• AppleScriptによるコントロールも可能。発行と引用にも対応
• PowerPC、68k、いずれのプラットフォームにも対応

目次（上巻）

• 第1章 アプリケーション開発の方法
  • 1.1　プログラム作成とは
  • 1.2　開発ツールの利用
  • 1.3　リソースの作成
  • 1.4　アプリケーション作成
  • 1.5　開発情報の入手
• 第2章 Cによるプログラミング
  • 2.1　基本的な型
  • 2.2　Cの制御構造
  • 2.3　プロトタイプ
  • 2.4　演算子と定数の取り扱い
  • 2.5　Toolbox関数の呼び出し
  • 2.6　PowerPC対応のプログラム作成
• 第3章 サンプルプログラム
  • 3.1　アプリケーションの概要
  • 3.2　基本的なタイプ
  • 3.3　サンプルプログラムのコンパイルとソース
• 第4章 メモリとシステム環境
  • 4.1　メモリ環境
  • 4.2　ヒープメモリの利用
  • 4.3　メモリ領域の管理
  • 4.4　Gestalt Manager
• 第5章 グラフィックス環境
  • 5.1　QuickDrawについて
  • 5.2　QuickDrawの座標系
  • 5.3　ビットマップとピクセルマップ
  • 5.4　グラフポート
  • 5.5　ペンと描画属性
  • 5.6　線や基本図形の描画
  • 5.7　複雑な形状の扱い
  • 5.8　グラフポート内での処理
  • 5.9　カーソル（マウスポインタ）
  • 5.10　アイコン
  • 5.11　オフスクリーンのGWorld
  • 5.12　印刷処理
• 第6章　イベント処理
  • 6.1　イベント取得とローレベルイベント
  • 6.2　マウスイベント処理
  • 6.3　キー入力の受け付け
  • 6.4　アプリケーションの切り替え
  • 6.5　マウスポインタの管理
• 第7章　ウインドウとコントロール
  • 7.1　ウインドウの作成
  • 7.2　グラフポートとウインドウの関連
  • 7.3　マウスクリックの処理
  • 7.4　ウインドウへのイベント
  • 7.5　コントロールの作成と破棄
  • 7.6　コントロールの値
  • 7.7　コントロールの状態
  • 7.8　ウインドウとコントロール
• 第8章　メニューの処理
  • 8.1　メニューの作成
  • 8.2　メニュー選択処理
  • 8.3　メニュー項目の属性
• 第9章　テキスト処理
  • 9.1　プログラム中の文字列
  • 9.2　文字列の描画
  • 9.3　フォント処理
  • 9.4　スクリプト対応
  • 9.5　文字列の処理
  • 9.6　テキストエディットの基本処理
  • 9.7　テキストエディットとスタイル管理
  • 9.8　インライン変換

目次（下巻）

• 第10章　リストオブジェクトの管理
  • 10.1　List Managerの使い方
  • 10.2　ListRec構造体の作成と廃棄
  • 10.3　マウス応答
  • 10.4　データの出し入れ
  • 10.5　イベント対応と表示処理
  • 10.6　リスト定義ルーチン
• 第11章　クリップボード処理
  • 11.1　スクラップの処理
  • 11.2　スクラップ処理の構築
  • 11.3　連続化データから戻す
• 第12章　ドラッグ&ドロップの組み込み
  • 12.1　ドラッグ&ドロップの動作
  • 12.2　ドラッグ&ドロップ処理の組み込み
  • 12.3　データフレーバー作成
  • 12.4　ドラッグ処理
  • 12.5　ドラッグデータの取り出し
  • 12.6　ドラッグ中のトラック処理
  • 12.7　ドラッグ後のデータ受け付け
  • 12.8　Finderとのドラッグ&ドロップ
  • 12.9　ドラッグ処理のカスタマイズ
• 第13章　ダイアログボックス
  • 13.1　ダイアログボックスの種類
  • 13.2　リソースとダイアログの作成
  • 13.3　ダイアログのアイテム
  • 13.4　モーダルダイアログ
  • 13.5　ムーバブルダイアログ
  • 13.6　ダイアログボックスとデータ処理
  • 13.7　アラート
• 第14章　ファイル処理とリソース
  • 14.1　ファイル管理のシステム
  • 14.2　ファイルやフォルダの指定
  • 14.3　標準ダイアログの表示
  • 14.4　標準ダイアログのカスタマイズ
  • 14.5　ファイルの作成や削除
  • 14.6　ファイルの内容の読み書き
  • 14.7　ファイル情報の取得と設定
  • 14.8　ボリューム情報の取得
  • 14.9　リソースとファイル処理
  • 14.10　リソースの読み書き
  • 14.11　エイリアス
  • 14.12　TextDrawでのファイル処理
• 第15章　AppleEventとアプリケーション間通信
  • 15.1　AppleEventへの対応
  • 15.2　AppleEventの処理
  • 15.3　AppleEventの取り扱い
  • 15.4　Required AppleEventの組み込み
  • 15.5　Edition Managerの処理
  • 15.6　引用の処理
  • 15.7　発行の処理
  • 15.8　その他の発行と引用の処理
• 第16章　AppleScript対応
  • 16.1　対応のためのロードマップ
  • 16.2　オブジェクトのサポート
  • 16.3　命令のサポート
  • 16.4　AppleScriptに対応したデータのやりとり
  • 16.5　スクリプト記録を可能に

ご購入は全国の書店でお願いします。

「メールの送付」の部分をクリックすると、メールを送付することができます。あるいは、msyk@locus.co.jpまでメールをお送り下さい。

メールの運用とお願い

• いただいたメールは、筆者と出版社の編集担当者へ転送されるようになっています。電子的な読者カードだとご理解いただければと存じます。（メールは筆者にだけ転送されるようになりました-99/8/13）
• ご意見あるいはご要望については、可能な限り、改版時などに反映させていただきます。ただし、諸般の事情によりご要望にそぐえないこともあるかと思いますので、ご了承ください。
• ご質問に関しては、そのすべてについてお答えするとは限りません。まず、本書と直接的に関係のないことについては基本的にはお答えできないものとお考え下さい。たとえば、読者の方が独自に作成されているプログラムのうまく機能しない点などについてのご質問については本書の範囲外となりますので、書籍のサポート外だと認識しています。
• ご質問やご要望については可能な限り返事を差し上げるよう努力します。その場合、ご質問内容やご要望についての回答を「Q&A」のコーナーに掲載することもありますので、この点はお含みおきください。また、その場合、質問者については無記名で、Q&Aの形式で記事掲載させていただくことを原則とします。なお、その場合には「Q&A」のコーナーに掲載するだけでなく、基本的にはお便りをいただいた方にも直接ご連絡は差し上げます。
• メールアドレスは設けておりますが、メールに対するお返事を必ず差し上げることを保証するものではありません。筆者の状況によって長時間かかることや、あるいはお答えができないことありますのでご了承ください。

  下巻のみの読者の方へ

  フロッピーのご提供サービスについては、郵送のみで受け付けています。メールでは受け付けておりませんので、ご了承下さい。フロッピーのご提供方法については下巻の巻末をご覧下さい。

  　

• 行数はそのページの上からの行数です。
• ツールボックスルーチン、見出し、図や表のキャプション、表の中身は行数に数えます。リストも行数に数えますが、リスト内の空行は行数に含めません。
• 図や図のコメントは行数に数えません。

巻	ページ	行数	間違い	正しい記述	備考
上	157	24	pascal void Subpt(Point *src, Point * dst);;	pascal void SubPt(Point src, Point * dst);
上	178	図5-6	奇跡	軌跡	下のコメント
上	202	13	picParam.hRes = 72;	picParam.hRes = 72<<16;	解説があります
上	202	14	picParam.vRes = 72;	picParam.vRes = 72<<16;	解説があります
上	287	22	(WindowPtr)	(WindowPeek)
上	368	4〜6	つまり、メモリブロックの先頭から文字列がいきなり始まります。文字列の長さはGetHandleSizxeを利用して求めます。	ハンドルによって示されるメモリブロックには、文字列の長さを示すバイト数から始まるPascal形式の文字列が入っています。したがって、1バイト目を参照することで、文字列の長さが分かります。	解説があります
上	369	2〜3	ハンドルにテキストを収める場合には、GetStringを使ったときのようにメモリブロックに文字コードを納めるのが一般的でしょう。	ハンドルにテキストを収める場合には、メモリブロックに単に文字コードを収めるという方法もあります。	解説があります
上	369	27	distStr[i] srcStr[i];	distStr[i] = srcStr[i];	=が欠落しています
上	370	2	distStr[distStr[0]+i] srcStr[i];	distStr[distStr[0]+i] = srcStr[i];	=が欠落しています
上	389	引数 code	（意味が分かりづらいので、右のように訂正します）	設定するスクリプトコードを0か正の数で指定。ないしは負の数で処理内容を指定（表9-8参照）
下	680	28	ヌルイベントはダイアログかどうかの区別はありませんので、…	（右記を参照）	ヌルイベント中でも、isDialogEventを利用すれば、ダイアログかどうかの判断はできます
下	721	31	Folder.h	Folders.h	このページの最後の行です
下	725	10	EOFErr	eofErr
下	725	12	EOFErr	eofErr
下	727	22	picParam.hRes = 72;	picParam.hRes = 72<<16;	解説があります
下	727	23	picParam.vRes = 72;	picParam.vRes = 72<<16;	解説があります
下	804	27	er = AECoerceDesc(...); の行の前に次のソースを追加	docListPtr = (AEDescList*)NewPtr(sizeof(AEDescList));	解説があります
下	805	2	return er; の行の前に次のソースを追加	DisposePtr((Ptr)docListPtr);	解説があります
下	806	24	er = AECoerceDesc(...); の行の前に次のソースを追加	docListPtr = (AEDescList*)NewPtr(sizeof(AEDescList));	解説があります
下	807	1	} の行の前に次のソースを追加	DisposePtr((Ptr)docListPtr);	解説があります

以上の訂正に伴い、サンプルプログラムについても修正をお願いします。修正が必要なサンプルプログラムのソースファイルは、以下のものです。

ソースファイル名	関数名	関連項目
AERequireSuite.c	DoAEOpen DoAEPrint	Open,Printイベントの処理ルーチンについて
DocFile.c	SaveToPict	PICT作成時のパラメータについて
PubSub.c	GetRectPict	PICT作成時のパラメータについて

プロジェクトのコンパイルについて

添付のフロッピーに納めてあるSymantec C++向けのプロジェクトは、筆者のミスにより、そのままではコンパイルできないことが判明しました。大変申し訳ありません。Symantec C++のみでコンパイルするためには、以下のように処置してください。

Symantec C++ Ver.8.4Jの場合

• Constants.hにはDrag.hをCD-ROMから持ってくるように記述されています。しかしながら、Drag.hは、開発ツール内に最初から含まれているので、特にどこかから持ってくる必要はありません。

  　

• ソースのCheckSys.cの最初に、次のソースを追加してください。
  
  • #include <Traps.h>

Symantec C++ Ver.8.0Jの場合

• Drag.hは、ヘッダファイルのConstants.hに記載されたものではなく、以下の位置にあるものを利用してください。
  
  • Symantec C++:Symantec C++ 8.0:Goodies:Universal 2.0a4 Interfaces:Drag.h
• ヘッダファイルのConstants.hの適当な位置に、以下の記述を加えてください。
  
  • enum { gestaltDragMgrAttr = 'drag',
    • gestaltDragMgrPresent = 0

    };

• THINK Cの場合は、さらに次の記述をConstants.hの適当な位置に追加してください。
  • extern pascal OSErr TEGetHiliteRgn(RgnHandle region, TEHandle hTE)
    THREEWORDINLINE(0x3F3C, 0x000F, 0xA83D);
• THINK Cの場合、ソースのWindowSet.cの最初の方にある#ifdef __SC__とそれに対応する#endifを削除してコンパイルしてください。つまり、その間の#defineが効くようにしてください。

PICT作成時のパラメータについて

PICTデータあるいはPICTファイルを作る場合に、OpenCPicParams型構造体のhRes、vResに解像度を設定します。書籍では「72」を代入していますが、これらのメンバーの型はFixed型なので、72<<16を代入しないと、1 dpiよりも小さな値が設定され、こうして作成したデータをうまく利用できないソフトが出てきます。筆者の不注意で間違ったリストを示すことになり、お詫び申し上げます。

なお、ソフトによっては、PICTデータの解像度を72dpi（特に画面表示だけの場合）に固定して考えているようで、修正しなくても、スクラップブックなどにはペーストできます。しかしながら、TextDrawIIIでオブジェクトをコピーし、Photoshopで新規文書を用意すると、解像度が1dpiになります。また、GraphicConverterにはペーストもできません。これらグラフィックス専門ソフトは、解像度の情報を読みとって正しく動作しているものと思われます。

Open,Printイベントの処理ルーチンについて

Openイベントが来たときに、パラメータから必要なデータを取り出すDoAEOpenや、Finderからの印刷処理で呼び出されるDoAEPrintにおいて、プログラムのミスがありました。ダイレクトパラメータから得られたディスクリプタを、強制変換してFSSpecデータのリストを得たいのですが、変換結果をdocListPtrをポインタとしてそこが参照するディスクリプタに対して処理が行われます。このとき、docListPtrには、AEDeskList型の構造体のメモリが確保されていなければならないのですが、本文とサンプルプログラムでは、ポインタの変数だけを用意して、実際の構造体のメモリは確保せずに処理をしています。したがって、たまたまその変数の初期値が空いているアドレスなら処理が行われますが、使っているメモリブロックを参照していればクラッシュすることになります。たとえば、DoAEOpen関数は次のようにして、docListPtrのためのメモリを確保しておかなければなりません。太字が追加する部分です。

OSErr DoAEOpen(const AEDesc *ptrToDirectParam)
{

....
AEDescList* docListPtr;
....

docListPtr = (AEDescList*)NewPtr(sizeof(AEDescList));
er = AECoerceDesc(ptrToDirectParam, typeAEList, docListPtr);
....
er = AEDisposeDesc(docListPtr);
DisposePtr((Ptr)docListPtr);
return er;

}

また、DoAEPrint関数も同様に変更する必要があります。変換先も、最低限はディスクリプタ分のメモリが確保されていなければならないのです。変換先を残すディスクリプタであるdocListPtrが示すブロックは、AECoerceDescで書き換えられ、さらにメンバーのdataHandleの先に変換結果を残します。docListPtrが示すブロックは、初期化して0で埋めておくなどの処置はとりあえずは不要ですが、サンプルプログラムによっては、何もデータを参照していないディスクリプタを処理に使う前には、dataHandleを0にして、descripterTypeをtypeNullにしている場合もあります。
なお、このミスについては、読者の雨森美知典様よりご指摘いただきました。雨森様に感謝するとともに、読者のみなさまに対しては間違ったソースを掲載したことをこの場を借りてお詫びいたします。

第9章の文字列リソースの記述について

誤植・訂正情報にも示したように、GetStringなどの文字列リソースから文字列を取得した結果は、メモリブロックの先頭からいきなり文字列が始まるのではなく、Str255型でPascal形式の文字列と同様、最初に文字列のバイト数が1バイト分確保されて、それに続いて文字列が並ぶことになります。

なお、このミスについては、読者の川上健様よりご指摘いただきました。川上様に感謝するとともに、読者のみなさまに対しては間違った情報を掲載したことをこの場を借りてお詫びいたします。

Q: 上巻のフロッピーディスクに「Visual Architect!」というシールが貼られています。内容もどうやら違うようです。違う書籍のフロッピーではないでしょうか？
A: 大変申し訳ございまん。調査したところ、数十冊くらいそのようなフロッピーのさし込み間違いがありました。お手数をおかけしますが、以下のいずれかの方法で正しいフロッピーをご請求いただけますでしょうか。出版社の負担にて正しいフロッピーを届けさせていただきます。

1. 郵便、ファクス、電話によるご請求
   1. 〒102 千代田区麹町2-10 イトーピア麹町AAビル4F
      株式会社ディー・アート分室　宛
      TEL:03-3288-0327、FAX:03-3288-0345
2. 電子メールによるご請求
   1. macappprog@msyk.locus.co.jpまでメールをお送り下さい。このホームページの「Internet読者カード」の部分をご利用ください。

お名前と住所、電話番号をお伝えいただければすぐに発送します。間違って付いていたフロッピーの返送の必要はありません。

Q: 上巻に添付されていたフロッピーを読みとることが出来ません。不良品だと思われます。交換してもらえますか？
A: 不良のフロッピーに関しても、1つ前のQ&Aと同様の方法で対処させていただきます。不良のフロッピーはお送りいただく必要はありませんので、電話、郵便、FAX、電子メールなどでご請求ください。
なお、フロッピーは2HDのフォーマットですので、2DDのフロッピーディスクドライブでは読みとることはできません。2DDが必要な方はまずいらっしゃらないかと思いますが、もしいらっしゃれば、上記の窓口にお問い合わせください。

Q: 添付のフロッピーに入っているSymantec C++向けのプロジェクトがうまくコンパイルできません。どうすればいいのでしょうか？
A: たいへん申し訳ありません。ヘッダのConstants.hに記載した内容に一部間違いがありました。「プロジェクトのコンパイルについて」として、正しい情報を記載しております（クリックするとジャンプできます）。ご迷惑をおかけしました。
日本語版のSymantec C++ Ver.8.0Jに含まれているヘッダなどは、Drag Managerなどが使われていないとても古い時代のヘッダが主に使われるようになっているために、このように余分な作業が必要になってしまっています。海外ではリリース４が配布されているようですが、国内ユーザー向けには何もアナウンスがありません。言い訳を許してもらえば、たぶん、書籍のフロッピーを作るときに、CodeWarriorから取ってきたヘッダなどを使っていたということがあったようです。もしかしたら、ヘッダのプリコンパイルをやりなおしていたのかもしれません。今後はもう少し慎重に作業します。

Q: サンプルアプリケーションをコンパイルできる具体的な開発環境を教えて下さい？
A: Syamtenc C++ Ver.8.0日本語版については、Symantec Project Manager、THINK Project Managerのプロジェクトファイルを添付してあります。また、Code Warrior Gold 7Code Warrior IDE Ver.1.3日本語版用として、PowerPC、68kそれぞれのプロジェクトを添付しています。ただし、執筆に伴う開発作業はCode Warrior Gold6のPowerPC開発環境で行いました。その他は基本的にはコンパイルが通るようにしただけですのでご了承下さい。
なお、Symantec C++ Ver.8.0日本語版をご利用の場合は、『プロジェクトのコンパイルについて』を参照してください。

Q: THINK Cを使っていますが、サンプルのアプリケーションは利用できますか？
A: Symantec C++ Ver.8には、THINK C Ver.7.0.4が含まれており、添付のディスクにはそのためのプロジェクトが含まれています。ただし、一部ソースを修正する必要があります。『プロジェクトのコンパイルについて』を参照してください。それ以前のバージョンでのコンパイルは確認していません。

Q: Symantec C++ Ver.8.0.4(Release 4)でサンプルアプリケーションはコンパイルできるのでしょうか？
Q: Symantec C++ Ver.8.0.4(Release 4)でサンプルアプリケーションをコンパイルしましたがエラーが出てしまいます。どうすればよいでしょうか？
A: 基本的には問題はないはずです。とりあえず、MacTech Manazineに添付されていたデモ版（Ver.8.0.4d11）でコンパイルしてみましたが、次の点を留意してください。

• プロジェクトファイルを読み込むと、古いバージョンであることを認識して変更するかどうかを訪ねてきますので、そこで変更をしてください。
• UtilsフォルダにあるCheckSys.cというソースに、「#include <Traps.h>」という行を最初に追加してください。

これで、コンパイルは通ります。また、コンパイラをMrCにしてもコンパイルは最後まで行われます。ちょっと動かした感じでは問題ないようです。Traps.hをインクルードするのは、Gestalt Managerが組み込まれているかどうかを確認するサブルーチンでトラップの定義定数を使用しているからです。どうやらプリコンパイルヘッダにはそれが読み込まれていないようです。

Q: Symantec C++を利用しているのですが、P367の文字列変換関数PtoCstr、CtoPstrを使っても、リンクエラーになってコンパイルが完了しません。
A: Symantec C++のマニュアルにもPtoCstr、CtoPstrの両方とも使えるように書いてありますが、インストールした状態では使えないようです。p2cstr、あるいはc2pstrを利用してください。これらはアップルが提供するUniversal Headersに定義された純正の変換ルーチンです。PtoCstrなどはTHINK Cが従来独自に提供していたルーチンです。Code Warriorでは両方とも使えるのですが、なぜかSymatec C++では使えないようです。書籍でもc2pstrの方を中心に説明した方が適切だったと思います。

Q: TextDrawIIIでオブジェクトを選択してコピーし、その結果をグラフィックスソフト上にペーストしたいのですが、正しくペーストできません。
A: これについてはリストにバグがありますので、正誤表を確認してください。バグの意味については、「PICT作成時のパラメータについて」を参照してください。

Q: CodeWarrior 11でTextDraw III Rev.2をコンパイルしたのですが、エラーが出ます。どうすればいいのでしょうか？
A: ソースファイルのConstants.hにある、「#include <Picker.h>」を、「#include <ColorPicker.h>」に変更してください。

Q: CodeWarrior Pro1でコンパイルしようとしたのですが、エラーが出てコンパイルができません。どうすればいいのでしょうか。
A: CodeWarriorはProfessional版になって、ライブラリの構成が変わったようで、プロジェクトに登録する内容を変更しなければなりません。古いプロジェクトを変換してもいいのですが、この際ですので、新しいプロジェクトを御提供します。

• 「TextDrawIII」に対応するものTDprojectMulti_Rev1.sit
• 「TextDrawIII Rev.2」に対応するものTDprojectMulti_Rev2.sit

いずれも解凍すると、「TD project Multi」というフォルダが出てきます。そのフォルダを、「TextDrawIII」あるいは「TextDrawIII Rev.2」フォルダに入れます。つまり、「AppleEvent_Handling」フォルダなどと同じ位置に「TD project Multi」フォルダを置きます。

「TD project Multi」フォルダには、Constants.hというヘッダファイルがあります。「TextDrawIII」の場合は既存のConstant.hを削除するか名前を変更し、そして「TD project Multi」フォルダのConstants.hと差し替えて下さい。「TextDrawIII Rev.2」を使う場合は差し替えなくても大丈夫なはずですが、ヘッダをアルファベット順に並び変えたり、読み込む必要のないものをコメントにするなど整理しているので、入れ替えてもよいでしょう。

そして、「TD project Multi」というフォルダにある「TD project Multi」というファイルをダブルクリックして新しくなったプロジェクトを開き、Command+Mなどでコンパイルして下さい。マルチターゲット対応なので、68k版、PPC版、FAT版のいずれもこの1つのプロジェクトから作成できます。

関連情報として、CodeWarrior Pro1でコンパイルも御覧ください。

Q: Code Warrior Pro2でコンパイルしようとしましたが、エラーが出てコンパイルできません。どうしたらよいのでしょうか？
A: CodeWarrior Pro2でコンパイルを御覧ください。ソースファイルの修正などが必要になっています。

Q: Code Warrior Pro3でコンパイルしようとしましたが、エラーが出てコンパイルできません。どうしたらよいのでしょうか？
A: Pro2までの修正が行われていればそれでコンパイルできるはずです。CodeWarrior Pro2でコンパイルを御覧ください。ソースファイルの修正などが必要になっています。ただし、AERegistry.rは正しく組み込まれているので、他からは持ってくる必要がありません。

Q: Code Warrior Pro4でコンパイルしようとしましたが、エラーが出てコンパイルできません。どうしたらよいのでしょうか？
A: CodeWarrior Pro4でコンパイルを御覧ください。ソースファイルの修正などが必要になっています。

Q:
A:

より汎用的なモーダルフィルタ

下巻p670に掲載してあるフィルタ関数を使ったモーダルダイアログボックスの処理について、中村慎一様より問題点についてご指摘をいただきました。その件について、提供していただいた情報を元に、補足説明をさせていただきます。

　下巻p670のフィルタ関数は、モーダルダイアログボックスでのキーボードのショートカット処理を組み込むのが目的です。ところがこのままだと、デフォルトボタンがOKボタンと仮定されているという問題があります。他のボタンがデフォルトの場合にはこのままでは対処できないというわけです。そこで、汎用的なデフォルトボタン処理をするためには、リストの14行目の

*item = ok;

を

*item = ((DialogPeek)theDlg)->aDefItem;

のようにするとよいでしょう。なお、OK以外のボタンをデフォルトにするには、ダイアログボックスを表示したときなどに、構造体のメンバーであるaDefItemに適切なアイテム番号をあらかじめ代入しておくなどの処理も必要になります。
　Universal Header Ver.2では、

*item = GetDialogDefaultItem(theDlg);

という表記でもかまいません。この方がすっきりするのですが、DialogRef関連の処理は執筆段階で入手できたSymantec C++の既定値のヘッダでは使えなかったこともあって、とりあえず本書では対象外とさせていただきました。もっとも、Symantec C++ Release4ではヘッダが新しいものに置き換わっているので、GetDialogDefaultItemも利用できます。
　さらに、キャンセルとして、Command+.（ピリオド）を受け付けるようにしていますが、このサンプルでは、文字キーボードの方のピリオドキーかどうかをキーコードで判断しています。ピリオドキーはそれだけではなく、テンキーにもありますので、リストの7行目からのif文は、

if((getEv->modifiers & cmdKey) != 0)	{
       if(   ((getEv->message & keyCodeMask) == 0x2F00)
           ||((getEv->message & keyCodeMask) == 0x4100))	{
                       *item = cancel;
                       return true;
       }
}

にするのが適切でしょう。テンキーのピリオドキーキーコードは0x41です。
（1995年12月18日）

E.T.Oについて

P19では、E.T.O.については、一部の開発者くらいしか必要がないような書き方をしていますが、その心は「とても高価である」ということがあったからです（直接は書いてはいませんが…）。しかしながら、1年ほど前までは、$1000/yearを越えていたものが、あれよあれよと価格が引き下げられ、現在は$195/yearと数分の1のレベルになっています。また、Code WarriorやSymantec C++よりも安く、マック環境ではもっとも低価格の開発ツールとなってしまいました。

そこで、気楽に買えるようになったMPWでもサンプルプログラムを利用できるようにします。もっとも、安いからと言って気楽に使えるツールではないのですが、そのあたりはとりあえず目をつむりましょう。サンプルプログラムをMPWでコンパイルするためのMPWのスクリプトファイルを作成しました。ソースファイルなどを若干修正しなければなりませんが、その方法は添付のテキストファイルで説明してあります。【ダウンロード】
（1996年7月27日）

CodeWarrior Pro1でコンパイル

CodeWarrior Pro1対応のプロジェクトファイルを公開しましたが、その過程での気付いたことをまとめておきましょう。マルチターゲットなど、いろいろ便利になったのですが、的確なエラーメッセージが出ないのはやっぱり仕方ないところかもしれません。同じように悩んでいる人の助けになればと思い、メモを残しておきましょう。

• プロジェクトは、新規プロジェクトから、用意されているひな形を利用して作った。「Basic Toolbox」タイプだが、68k、PPCに加えて、一気にFATを作成できるMultiというのもある。いちおうそれを使うことを目指す。しかし、うまく作れなかった。そこで、68k版、PPC版をそれぞれ造りながら、問題点を詰めて行った。
• まず、どちらも、SillyBallというサンプルソースとリソースがあるので、それは取り除く必要がある。また、TextDrawはANSIのライブラリは使っていないので、それも削除してしまうのでいい。
• ソースやリソースファイルは、フォルダごとドラッグ&ドロップして登録できる。リソースとして用意するものは、.rsrcと.rの両方を用意してある。内容は同じものだが、警告が出るのでとりあえずどちらかにする。ちなみに、最初に出版した頃には、CodeWarriorにはプロジェクトに.rファイルを入れることができず、ToolServerなんかを使っていたのを懐かしく思ったりして。
• PPC版はライブラリが足りないだけで、ライブラリを追加して機能するようになった。Metrowerks/Metrowerks CodeWarrior/MacOS Support/Libraries/MacOS CommonというフォルダにあるDragLibとObjectSupportLibをとりあえず付け加えればOK。
• 68K版で不足するライブラリは、Metrowerks/Metrowerks CodeWarrior/MacOS Support/Libraries/MacOS Common/MacOS 68K/MacOS FilesというフォルダにあるAEObjectSupportLib.oというライブラリ。これをプロジェクトに付け加えればいいのだが、このライブラリが古い形式のため、単純には機能しなかった。このライブラリがToolboxルーチンを呼び出す段階で、16ビットのコールアドレスになっているというメッセージが出たので、「これとToolboxライブラリは同じセグメントにないとだめ」ということが分かる。CodeWarrior Pro1はセグメンテーションは自動的に行うようなのだが、ファイルの順序でライブラリをすべて前の方におさめれば、どうやら同じセグメントに落ち着いたようだ。
• こうしたポイントを守りながら、マルチターゲットのプロジェクトを作成すると、うまく作成できた。特に、AEObjectSupportLib.oとMacOS.libが同じセグメントにないといけないことが、そういうストレートな表現でなかったため、最初にいきなりマルチターゲットをやってみたときに、完全にビルドする方法が分からなかった。
• ほかに、作成するファイル名や、ファイルのクリエイタを入力する必要もある。SIZEリソースのフラグも要チェック。isStationaryAwareフラグは、いずれのプロジェクトでも設定が必要になる。68K版においては、isHighlevelEventAwareのフラグチェックも必要になる。

（1997年9月8日）

CodeWarrior Pro2でコンパイル

Code Warrior Pro1で大きく変わったのに続き、さらにPro2でもソースの修正をしないとコンパイルが通らなくなってしまいました。ヘッダの旧バージョン互換の部分が徐々に省略されてきているからだと思うのですが、いずれにしても、以下のように修正して、対処できました。

• AERegistry.rというファイルがなくなっている

  AppleScript関連での各種の定義定数が含まれているAERegistry.rが、なぜかCW Pro2には含まれていません。ところが、ファイル検索をかけるとCD-ROMには存在しているのですが、なぜかとりだすことはできないのです。ファイルが壊れているのでしょうか？　もとになったと思われるDeveloper CDのUniversal Headerでも、同様に検索はされるのですがファイルの存在がない状態です。それをそのままコピーしたのだと思われます。

  そこで、どうしてもこれを持ってこないといけないのですが、CW Pro1のCD-ROMから持ってくるのがいちばんの早道だと思います。CW Pro1を持っていない、たとえば初めて購入した開発ツールがCW Pro2というユーザーの場合は、若干問題があるかもしれませんが、「だれかからもらう」しかないと思います。もともと、あるはずのファイルが存在していないこと自体が問題ですから。CW Pro1のCD-ROMだと、以下のパスに存在します。

  CWPro 1 Tools:Metrowerks CodeWarrior:MacOS Support:Headers:Rez Headers:AERegistry.r

  このファイルを、CW Pro2の以下のパスに入れておきます。

  Metrowerks:Metrowerks CodeWarrior:MacOS Support:Headers:Rez Headers:

• ヘッダファイルのConstants.hに、以下のヘッダ読み込みを加えて下さい。SysBeep()の定義がSound Managerに移動したためです。

  #include <Sound.h>

• ソースファイルのDocFile.cにおいて、以下のように定義定数を変更して下さい。2箇所あります。

  kIsStationary→kIsStationery

• ソースファイルのDragRecieve.cにおいて、以下のように定義定数を変更して下さい。

  dragInsideSenderApplication→kDragInsideSenderApplication

• ソースファイルのDragTrack.cにおいて、以下のように定義定数を変更して下さい。

  dragTrackingEnterHandler→kDragTrackingEnterHandler

  dragTrackingEnterWindow→kDragTrackingEnterWindow

  dragTrackingInWindow→kDragTrackingInWindow

  dragTrackingLeaveWindow→kDragTrackingLeaveWindow

  dragTrackingLeaveHandler→kDragTrackingLeaveHandler

• ソースファイルのWindowSet.cにおいて、以下のようにプログラムを変更して下さい。DoActivate、DoDeavtivate、ContentsScroll（途中のforのパラメータ中）、GetScrollHandleの各関数定義中に合計4箇所あります。

  curContH = ((WindowPeek)targetWindow)->controlList;
  →curContH = (ControlHandle)((WindowPeek)targetWindow)->controlList;

なお、フロッピーディスクのまっさらの状態からの修正作業をしていおらず、CW Pro1に対応した状態から修正をかけましたので、場合によっては、そちらの修正も御覧ください。

（1998年2月2日）

クリエータの登録

クリエータの登録については、上巻p.51で申し込み用紙があることを記述しています。しかしながら、現在はWebページで受付を行っています。ここ最近に始まったことではないのですが、いちおう記載しておきます。以下のURLが受付ページで、このページで登録後、メールで実際に使えるクリエータを教えてくれるようになります。登録するのはクリエータだけになっています。

http://devworld.apple.com/dev/cftype/main.html

（1998年5月5日）

現在は以下のページで、登録ができるようになっています。

http://developer.apple.com/dev/cftype/information.html

（2000年4月23日）

Carbon情報　TextDrawIIIの対応度は何パーセント？

98年5月のWWDCで、OSのロードマップが修正され、「Carbon API」というコンセプトが提示されました。いろいろ言われていますが、アプリケーションプログラマにとっては、「Mac OSと同じ」ということが重要です。Rhapsodyに移行してしまうとMac OSに対する技術的な蓄積もあまり役にたたなくなってしまったかも知れません。しかしながら、次世代OSである「Mac OS X」では、従来のMac OSのAPIを使いながら、プロテクトメモリなどのモダンなOSの諸機能を使えるわけです。

アップルからは、さっそく、現状のアプリケーションに対して、Carbon対応するにはどの程度の修正が必要かをチェックするソフト「Carbon Dater」がリリースされています。さっそく、本書のサンプルプログラムであるTextDrawIIIを調べてみました。このCarbon Daterは、アプリケーションファイルのデータフォーク、つまりPowerPCの実行オブジェクトを解析して、その中でどんなAPIコールが使われているかをチェックして、サマリー情報をいったんテキストファイルに記載します。それを、指定のメールアドレスに添付して送信して、１時間くらい待つと、結果が電子メールで送られてきます。解析結果をHTMLファイルでもらえます。せっかくですから、アップルの報告結果をそのままお見せします。
→Carbon DaterによるTextDrawIIIの解析結果

解析結果は、アップルから送付されてきたファイルをまったくそのままの状態です。アップル社の著作権表示があるように、アップルによって制作されたアップルが著作権を持つページです。ただし内容的には筆者が制作したソフトウエアを題材に使っているなどの理由から、このページで解析結果を公開することは、アップルに対する著作権侵害には当たらないと判断し、そのままの形で公開します。問題があれば、御指摘ください。

まず、解析結果の最初の表とグラフで、TextDrawIIIで使っているAPIのうち、CarbonでサポートされるAPIがどれくらいかが分ります。9割近くはサポートされるようで、その意味でも高い互換度になるでしょう。大雑把に見て、10%程度の修正でなんとかなりそうです。この解析結果を見た限りの、要チェックポイントをまとめておきます。

• 印刷関連のAPIでコメントがいっぱいついていますが、これは恐らく、周辺機器のドライバ環境が大きく変化することによるもので、アプリケーションにとっては基本的には変化は小規模だと思われます。たとえば、スプールはドライバで持たせるために、スプールのための呼び出し（PrPicFile）は恐らく不要になるのだと思われます。
• ウインドウやダイアログ関連は、基本的にはそのままCarbonに移行できるようですが、APIの名称自体はそこそこ変化があるでしょう。これは、Code Warriorでコンパイルしながらクリアできることかもしれません。ただし、ウインドウの構造体のメンバは直接は利用しないようにということで、現状のユニバーサルヘッダで言えば、WindowRefを主体にした処理、あるいはそれに近いタイプの処理で、ウインドウの構造体を処理することになるでしょう。また、構造体のメンバに直接アクセスしないのは、メニューについても言えるようです。
• メモリ処理はかなり変わりそうですが、NewHandleなどの通常のAPIは継続されるようです。テンポラリメモリが使えなくなるようなので、メモリモデルもかなり動くかもしれません。ゾーンをいじるなど、メモリ処理でトリッキーなことをやっていれば、Carbonでの動作も怪しいでしょう。互換性レポートの中に詳しい記述があります。
• ファイルを開いたり保存したりするときの、いわゆる「標準ダイアログ」はCarbonではサポートされないようです。その代わり、「ナビゲーションサービス」として、標準ダイアログを完全に置き換えるシステムサービスを利用します。これについてはSDKが公開されており、Mac OS 8.5で搭載されるという情報もあり、現状で“プログラミング可能”な新機能だと言えるでしょう。SDKは、Mac OS Xのページからダウンロードできます。
• 発行と引用については、「評価中」となっていますが、アプリケーションの現状を見る限りはサポートされないAPIになるのではないかと思われます。発行と引用も、「リンク」という意味では必要で有用な機能なのですが、実用的に使うための手軽さに欠けていたと評価できるでしょうか。
• テキスト処理についてのシステムAPIに何らかの変更があるようです。名称だけの変更かもしれませんが、できれば、複雑なテキスト処理にも対応してもらいたいところです。

以上のように、Carbonで動作するために変更すべき点は、それほどありません。また、PowerPlantベースでアプリケーションを作っていれば、修正が必要な箇所はもっと少なくなるでしょう。そうした修正はクラスライブラリ内で吸収されることは十分に期待できるでしょう。

Rhapsodyへの移行が主命題となってしまったときは、これまでMac OSに対してつき合ってきたけど、お別れになるのか…と思ってしまったのではないでしょうか。しかし、Carbonによって、Mac OSのAPIがまたメインストリームに戻ってきました。今までの資産が生かせるCarbonには、これからも注目したいと思います。

→アップル社のMac OS X情報
（1998年5月30日）

CodeWarrior Pro4でコンパイル

書籍に添付されているサンプルプログラムTextDrawIIIを、CodeWarrior Pro4でコンパイルする方法を紹介しておきます。このページで紹介しているPro2（Pro3ではPro2までの修正でOK）でコンパイルできる状態からの差分情報を掲載しますので、フロッピーディスクの内容から作業を始めるには、お手数ですが、バージョンを順番に追って修正をかけていってください。また、この修正は、単にサンプルプログラムをコンパイルできるようにするだけのためのもので、Mac OS 8.5の新機能などに対応するものではありません。

修正ファイル：Constants.h

このファイルの最初にヘッダーをインクルードする部分があります。以下のヘッダーファイルもインクルードされるように、コメントを取り去るか、あるいは記述を追加してください。

• #include <AEObjects.h>
• #include <AEPackObject.h>
• #include <ColorPicker.h>
• #include <Devices.h>
• #include <Fonts.h>
• #include <Gestalt.h>
• #include <Lists.h>
• #include <LowMem.h>
• #include <NumberFormatting.h>
• #include <Printing.h>
• #include <Scrap.h>
• #include <StringCompare.h>
• #include <TextUtils.h>
• #include <Traps.h>

（1998年11月26日）