● MOSA MPJ digital（2001/02/12）
〜 コントロールを使おう！ 最終回 〜
このコラムは、MOSAの会員にのみ配布されているプログラマ向け
デジタルマガジン MPJ digitalの2001年01月号に執筆したものです。
今回は、筆者が今まで利用してきた色々な種類のコントロールの特徴についてお話したいと思います。また、Mac OS XでAuqaベースのコントロールを利用する時の注意事項などについても言及してみます。
現時点（2001年1月9日）でのCarbonアプリケーションの最新開発環境は、以下のApple SDKサイトに登録されている「CarbonLib 1.2 SDK」です。このSDKには、デベロッパーが長らく待たされていたCarbonLib v1.2のGM（ゴールデンマスター）版が含まれています（ただしUniversal Interfacesはβ版のまま）。また、このSDKから正式に、Carbonアプリケーション用として新規追加された「Carbon Event Manager」が利用できるようになりました。実はCarbon Event Managerは、CarbonLib v1.1からサポートされているのですが、どうもこのバージョン（v1.1）は世に出ないような雰囲気です。Carbon Eventは、今までのようなイベントループによる分岐を使わず、Apple Eventで用いた手法を拡張し、発生したEventを各オブジェクトにリンクさせたEvent Handlerで処理する設計になっています。
Carbon Eventの詳しい内容については別の機会に解説するとして、SDKに含まれている「Universal Interfaces3.4b3」のCarbonEvents.hのコメントを頼りに、さっそくコントロールに関係するCarbon Eventの実装にチャレンジしてみました。ところが、CarbonEvents.hに定義されている「eventKind」（Carbon Eventの種類）の幾つかをあれこれと試してみたのですが、どうもその中の「kEventControlHit」しか実装されていない感じなのです。
図1-CarbonEvents.hに定義されているコントロールの関するeventKind
つまり、コントロールに対しては、まだすべての機能が実装されていないわけですね。まあ、Carbon Event Managerに関してのドキュメントやサンプル（特にコントロールに関して）が絶対的に不足している現状では、筆者の試し方に問題があるかもしれません。この件は、AppleからCarbon Event Managerに関する正式なドキュメントが発表された時点で、再度確認してみたいと思っています。
まず、インライン用編集テキストコントロール「kControlEditTextInlineInputProc」（procID=276）についての注意点を取り上げてみます。以前にも説明しましたが、通常の編集テキストコントロール「kControlEditTextProc」はprocID=272なのですが、インライン用にはprocID=276が定義されています。日本語対応のアプリケーションでは、通常後者のコントロールを利用するのが普通です。ところが、筆者の開発しているCarbonアプリケーションをCarbonLib v1.04もしくはv1.2の環境で起動すると、モーダルダイアログ上にインライン用編集テキストコントロールを配置しても、インライン入力ができないという不都合が発覚しました（涙）。
Carbonアプリケーションでない場合には、モーダルダイアログ上の編集テキストアイテム（コントロールでない）でインライン入力を行いたい場合には、その'DLOG'リソースのrefConフィールドに'tmDI'というパラメータを設定しておくと言うルールがありました。
図2-'DLOG'リソースのrefConフィールドに設定した'tmDI'の十進表記
これが原因ではないかと推測し、今まで通りrefConフィールドに'tmDI'を設定してみたのですが、やはりダメでした。この現象をバグとしてAppleに報告したところ、「refConフィールドに'tmTE'を設定してみてくれ」という返事が来ました。しかし、指摘されたタイプを設定してもやはりダメなのです（'tmTE'なんてのもあったのか？）。だいたい、コントロールタイプがインライン入力用なのですから、そんな設定をしなくてもちゃんと動いてくれるのが正しい姿ではないでしょうか？現在は、確認後の現象を再度報告してありますが、「うちのCarbonアプリケーションのモーダルダイアログでは、インライン用編集テキストコントロールでちゃんとインライン入力ができているぞ」という方がいらっしゃいましたら、ぜひご連絡いただけると助かります。
次は、Resorcererのタイプメニューで「イメージの泉」（笑）と表記されているImage Wellコントロール「kControlImageWellProc」についてです。このコントロールでは3Dボタンの表面に色々なタイプの画像を表示することができます。表示できる画像の種類には、ICONデータやリソース、PICTデータやリソースなどがあります。どのようなタイプの画像が利用できるのかは、Controls.hの「ControlContentType」に定義されていますので参照してみてください。
図3-ControlContentTypeの種類とControlButtonContentInfo構造体
実際にコントロールに画像をセットする場合には、画像タイプ（ControlContentTypeのどれか）と、その画像に関する情報を「ControlButtonContentInfo」構造体の適切なメンバーに代入してから、SetImageWellContentInfo()を呼びます。逆に、コントロールにセット済みの画像情報を得るのには、GetImageWellContentInfo()を使います。ここでは、Image WellコントロールにPICT画像（PicHandleとして渡す）をセットするためのsetItemPicture()ルーチンと、設定済みコントロールからPICT画像を得るためのgetItemPicture()ルーチンを例題として示しておきます。
図4-setItemPiture()とgetItemPicture()サンプルルーチン
アプリケーションによっては、あるオブジェクトのカラー情報をダイアログにより変更させたい場合があります。例えばワープロなどで、表示テキストの文字カラーや背景カラーの変更をプオプションとして提供しているような場合です。こうした場合には、GetColor()でSystem標準のColor Picker（カラー選択ダイアログ）をオープンすることになるのですが、当然、現在設定されているカラーをダイアログ上にのどこかに表示しておく必要があります。本当ならば、Image WellコントロールのControlContentTypeに「カラー表示」というタイプがあり、その情報をRGBColorで渡せば3Dボタンが任意のカラーで表示できると助かるのですが、残念ながらそのような設定はありません。そこで、以下に示すmakeColorPicture()ルーチンを用いて単色カラーのPICT画像を作り、それをsetItemPicture()ルーチンでセットしてやります。
図5-カラー表示用のPICT画像を作成するmakeColorPicture()ルーチン
これにより3Dボタンの表面が好みのカラー表示に変わり、このボタンをクリックすることでColor Pickerを表示させ、その後setItemPicture()で再度ボタンのカラーを変更してやります。ダイアログでの作業が終了したら、カラー3Dボタンに利用していたPICT画像（PicHandle）をgetItemPicture()で呼び出し、KillPicture()で削除しておくことも忘れないでください。
図6-標準的なImage WellコントロールとカラーPICT画像をセットした例
前回、Tabコントロールを作成する場合には、'CNTL'に加えて'tab#'リソースを用意する必要があるとお話しました。Tabコントロールの場合、各Tabに表示するタイトル（文字列）やアイコン情報を'CNTL'リソース単独では設定しきれないので、分離させて'tab#'リソースに保存しているわけです。これと同様な準備をしなければいけないコントロールに、リストボックスコントロール「kControlListBoxProc」（ProcID=352）があります。リストボックスコントロールの場合には、リストボックスの行数やカラム数、セルの高さや幅、左右スクロールの有無といった情報を、'CNTL'リソースとは別に'ldes'リソースに保存しておきます。
図7-リストボックス用に'CNTL'リソースとは別に'ldes'リソースを作る
Resorcererにより'ldes'リソースを編集したら、そのリソースのID番号を'CNTL'リソース側の「ldes ID」（通常の初期値のカラム）に入力しておきます。これでリストボックスに必要なリソースの準備は完了となります。また、リソースからではなくソースコード内で新規にリストボックスコントロールを作成する場合には、CreateListBoxControl()というAPIが用意されています。
System 7時代のチェックボックスは、ダイアログでマウスクリックされた時点で、SetControlValue()を使い値（ゼロか1）を代入しないと、チェックした状態を保持（表示）できませんでした。ところが現在、「kControlCheckBoxAutoToggleProc」（procID=371）という新しいチェックボックスコントロールが用意されており、今までの不便を改善しています。このコントロールはマウスクリックにより状態を切り替え、その値（チェックなら1、そうでないならゼロ）を自動代入してくれます。つまり、自分自身の状態を管理しているわけです。ラジオボタンコントロールでも同様な性質を持つ「kControlRadioButtonAutoToggleProc」（rocID=372）が用意されています。注意する点は、Resorcererのコントロールタイプのメニュー項目には、これらのコントロールが無いことです。メニュー項目に無いコントロールの'CNTL'リソースを作りたい場合には、編集ダイアログの「ProcID」カラムに、ControlDefinitions.hに定義されている値を直接入力してしまいます。メニューに定義されていない値を入力すると、Popupボタンの設定項目が「旧ボタン」となってしまいますが、気にする必要はありません。最近では、オリジナルから少しだけ性質を変えたコントロールが多数定義されています。これらの中には、Resorcererのタイプメニューでは選択できない物もありますので、最新のControlDefinitions.hを参照して、自分の目的に合ったコントロールを探してみてください。
最後に、Carbonアプりケーションを開発する場合に避けて通ることはできないコントロールのAqua化についての解説をしておきます。通常、アピアランス対応のダイアログに配置されているコントロールは、Mac OS X環境では自動的にAqua表示されます。ですからAqua化と言っても特別な作業は必要ありませんし、それほど難しいわけではありません。しかし、Mac OS 9上では美しくレイアウト表示されているコントロールでも、Mac OS XのNaitive環境で起動しAqua表示にしてみると数々の不都合が起こることに気づきます。例えば、古典的なボタン、ポップアップメニュー、ラジオボタン、チェックボックスをAquaベースの物と比較してみると、中に表示するテキスト（タイトル）の文字長に注意する必要があります。文字長がコントロールの矩形枠（表示枠）ぎりぎりだと、Mac OS Xで表示された場合にタイトルの左右が切れてしまいます。Aqua化を考慮すると、コントロール内のテキストの左右には適度なスペースが必要なようです。同様にMac OS 8から導入された新しい3Dボタン（Bevel Button）などにおいても文字長テキストの文字長の問題は存在しているようです。
Mac OS 8や9では、パレットやツールバー用として小さな3Dボタンを接触させて並べるケースが多々ありました。例えばワープロのツールバーは、書式の種類などを小さな3Dボタンで切り替えるようにレイアウトされています。こうした3Dボタンのレイアウトも、Aquaベースでは問題が発生します。あまり接近させると、ボタンが隣と重なってしまい、右側が欠けた状態で表示されるのです。Aquaベースでは、小さなボタンであっても隣との間に数ピクセルの間隔を入れる必要がありそうです。このスペースの問題は、Tabコントロールにも存在します。AuqaベースのTabコントロールには、タブのすぐ下に8ピクセル幅の色付きラインが入っています。この変更のおかげで、タブのすぐ下に配置したボタンなどのコントロールがこのラインと重なり、みっともない状態になることがあります。
以下の例は、私がMac OS 9環境で開発したアプリケーションウィンドウの一部を示しています。
図8-Mac OS XでAqua化されたコントロールを表示するとレイアウトが乱れる
コントロールのレイアウトをまったく変更せずにCarbon化するとこうなってしまうという悪い例です。ボタンの文字は欠けていますし、その影の部分が下のカラーパレットの一部を消しています。また、密着させた3Dボタンは隣のボタンの一部を消していることも分かります。アプリケーションによっては、システムリソースからアイコンなどを流用している場合も注意が必要になります。当然、Mac OS Xでリソースとして用意されていないアイコンは表示できません。例えばSystemフォルダ内で利用されている「フォントフォルダ」や「アップルメニューフォルダ」のアイコンを利用しようとしても、Mac OS Xでは表示できないわけです。Mac OS Xへの移行を考えると、システムリソース内のオブジェクト（アイコンやカーソルやPICT）の利用は避けた方が賢明のようです。
チェックボックスコントロールに関して、もう一つだけ注意点を上げておきます。以下は、やはり私が開発しているアプリケーションのダイアログの一部を抽出した例です。
図9-Mac OS XでAqua化されたチェックボックスは表示サイズが可変である
Mac OS 9上では綺麗にチェックボックスが並んでいますが、これをMac OS X環境で表示するとチェックボックスのサイズがバラバラになってしまいます。これは、Aquaベースのチェックボックスやラジオボタンが、その矩形枠の高さに合わせてサイズ（見た目）を変えるようになったためです。Mac OS 8や9では、コントロールの矩形枠の高さを変えても、チェックボックスやラジオボタンのサイズに変化はありませんでした。ですから、かなりいい加減なサイズで並べたとしても見た目は問題が無かったわけです。しかし、Mac OS Xでは見事にバラバラになってしまいます。Applが提示している推奨サイズは18ピクセルとなっていますので、几帳面にサイズを合わせてレイアウトする必要があります。