以前説明したように、アプリケーション側からEditUnicodeTextコントロールの中身を削除したい場合には、以下のルーチンを実行します。

SetControlData( chd,kControlNoPart,kControlEditTextTextTag,0,NULL );

これにより、カラムに入力されていたテキストは奇麗さっぱり消えてしまいます。かってにフォントサイズが小さくなるのなら、アプリケーション側で強制的にフォントサイズを元に戻したらOKだろうと試してみましたが、敵もそれほど甘くはありません（笑）。効果無しです。今回遭遇した「フォントサイズ縮小化現象」を詳しく調べてみると、以下の事実が判明しました。

・コントロールを作成した直後に上記ルーチンを実行しても現象は出ない。
・一度もテキストを入力しなければ上記ルーチンを何回繰り返しても現象は出ない。
・一度でもカラムにテキストを入力すると上記ルーチンの実行で現象が出る。
・コントロールを一度破棄して再度作成すれば一回目の入力のみ現象は出ない。
・この現象で一度文字サイズが小さくなると強制的に文字サイズを変更しても無駄。

ダイアログを閉じた時に、DisposeWidnow()でウィンドウを破棄してしまえば、そこに配置されたコントロールも破棄されてしまい、この現象には遭遇し難いと思われます。ところが、ウィンドウをHideWindow()で閉じ、次の機会にShowWindow()で開くような処理では話は別です。コントロールもそのままの状態で残っていますので、入力されているテキストを初期化のためにクリアすると、以降は入力文字のフォントサイズが小さくなってしまうわけです。筆者の開発しているアプリケーションの状況は、まさに後者に相当しています。

だったら、一度ウィンドウをDisposeWidnow()し作り直せば良いと思われるでしょうが（実際にそうなんですが）、ウィンドウには非常に数多くのコントロールが配置されており、それらをNibファイルから呼び込みウィンドウを作る処理に結構な時間がかかるのです。つまり、一度作成したウィンドウをHideWindow()で閉じるのは、次の機会に高速でウィンドウを表示させるための準備なのです。これならば、ユーザが処理待ちでイライラするのは、最初のオープンの一回だけですみます。

というわけで、色々と試してみたところ、とりあえず以下の回避方法が考えられることが分かりました。

・コントロールを配置したウィンドウを初期化（文字クリア）の度に再構築する。
・対象となるEditUnicodeTextコントロールを初期化の度に一度廃棄して再構築する。
・バックスペース等のキー入力をCarbon Evenとしてコントロールに送ってやる。
・最初から小さくなった時のフォントサイズで文字入力するようセットしておく（笑）。

結局どれもこれも（実現できないわけではないでが）その場しのぎの対策でしかありません。せっかく構築したユーザインターフェースオブジェクトを、初期化の度に破棄していたのでは、何のためにNIbファイルを活用したのか分からなくなります。当然、こんな理不尽な現象を回避するためだけにソスコードを醜くする事にも納得がいきません。本当にこの現象はバグなのか？もっとスマートな回避方法はないのか？筆者のテキストクリアの方法は間違っていないのか？色々と疑問が湧いてきます。結局、こうした疑問に一人で悩んでいても袋小路行き止まりでしょう。ここは、ちゃんとApple社の正式見解を聞くのが近道であるという結論に達しました。

そこで次回は、最後の頼み綱としてのdts@apple.comサービスの登場となります。

つづく