今回遭遇した現象がたとえバグであったとしても、それに対して簡単な（自分の作業にマッチした）回避方法が存在していれば、それほど大きな問題にはなりません。Apple社の技術者から直接情報を引き出せるはずのDTS（Developer Technical Support）には、そうした回答を返してくれることを期待するわけです。そのためには、現象をより詳しく説明したメールを送付する必要があります。また、それ以上に効果的なことは、現象を再現させた簡単な「サンプルソースコード」をメールに添付することです。

まずはそれを起動してもらい、先方でも同じ現象が出ることを確認してもらいます。もし現象が出なければ、その問題は自分のマシン環境が起因するローカルな問題となります。そうした場合には、問題への対応方法が随分と変わるはずです。もし同じ現象が確認されれば、そのサンプルを使い、すぐさま対処方法を探ってもらえます。返答をもらうまでの相手側の調査工程も短縮化されますので、双方にとって大きなメリットとなります。

今回は、ダイアログにExitTextとEditUnicodeTextの2つのコントロールを配置し、「文字クリア」というボタンをクリックすると、両方の入力テキストがクリアされるサンプルアプリケーションを作成して添付しました。ボタンをクリックした後、両方のカラムでテキストを入力してもらえれば、EditUnicodeTextの方だけフォントサイズが小さくなるので、異常が起こっていることは一目瞭然です。今回メールに添付したサンプルソースコードの主用部分は、以下のようになります。



displayMyWindow()ルーチンは、Main.nibファイルから「MainWindow」と名称が付いたウィンドウを呼び出し、Carbon Event HandlerとしてmyWindowEventHandler()ルーチンをインストールします。そのウィンドウには、CommandID='clea'の「文字クリア」ボタン、Control ID=3のEditUnicodeTextコントロール、ID=4のExitTextコントロールの3つが配置されています。ユーザが「文字クリア」ボタンをクリックすると、イベントクラスがkEventClassCommandでイベント種類がkEventProcessCommandのCarbon Eventが発生します。この時にCommandIDが'clea'であれば、Handler側でSetControlData()を呼び出し、両方のカラム（コントロール）のテキストを削除します。

筆者のマシン環境では、開発中のアプリケーションだけではなく、このサンプルアプリケーションでも例の現象が起こりました。さて、サンプルコードを確認してくれているDTS側からの回答はどうだったでしょうか？

次回は、その回答と問題解決のための新たなアイデアについてお話したいと思います。

つづく