バグへの対処ルーチンを自作のアプリケーションに組み込み、すべてのEdit TextコントロールをEditUnicodeTextコントロールに切り替えて動作確認してみました。すると、またまた不可思議なことが起こることに気づきました。文字を入力しようとコントロール内をマウスクリックをすると、表示されているテキストフォントの種類が切り換わるのです。文字入力中は一定のフォントで表示されていますが、ウィンドウを切り替え、アクティブ・インアクティブなどにした瞬間にも同様な現象が生じます。

どうも、システムがコントロールの再描画時にかってにフォントの種類を切り換えているようです。これでは、フォントサイズの問題が解消されたとしても、ほとんど利用価値がありません。ところが、バグ再現用のサンプルとして作成していた小さなアプリケーションでは、同様な状況でもフォントは切り換わりません？製品とサンプルアプリはいったいどこが違うのか？色々と調べた結果、どうも起動されているアプリケーションが英語スクリプト対応なのか？日本語スクリプト対応なのか？により現象が異なるようです。

アプリケーションのディフォルト対応スクリプトは、パッケージ内に保存されているInfo.plistの「CFBundleDevelopmentRegion」キーで設定できます。ここを「English」と記述すると「Osaka」がディフォルトとなり、「Japanese」と記述すれば「ひらぎの角ゴPro3」がディフォルトとなります。パッケージのResourcesフォルダには、対応する言語のInfoPlist.stringsを保存したフォルダも必要です。英語用にはEnglish.lprojという名称のフォルダを、日本語用にはJapanese.lprojという名称のフォルダを用意します。

今回の不可思議な現象は、日本語対応アプリケーションにおいて、フォントサイズだけを変更してもフォントの種類までが「Osaka」に切り換わってしまうのが原因のようです。英語対応アプリケーションはディフォルトが「Osaka」ですので、現象が発覚しないわけです。加えて、タブコントロール内に配置したUnicodeEditTextカラムでは、タブを切り替えるたびに、内容が「ひらぎの角ゴPro3」で表示されてしまいます。これでは、何有るごとにフォント表示が切り換わる非常に見苦しい状態であり、とても採用する気にはなれません。

まあ、これもバグなんでしょうが、最初にフォントの種類を「ひらぎの角ゴPro3」に設定しておけば問題ないはずです。よって、前回のsetMyControlFontSize()ルーチンを以下のように変更して試してみました。



/* 　48166はひらぎの角ゴPro3のフォント番号 　*/

この対策により、フォントの種類は切り換わらなくなりました。さあ、これで完璧だ！と思ったのですが、まだまだ続きがありました。コントロールに文字を入力していない状態で、編集メニューから「取り消し」（Undo）を選択すると、フォンサイズが小さいサイズ（10ポイント?）に戻ってしまうのです。どうも、APIで行ったフォント変更が編集処理として認識されており、Undoで元の状態に戻るのが原因のようです（涙）。いやぁ〜、相手もかなり手ごわい！

よし、それならばCarbon EventでUndoが発生した時に割り込みを入れて....と考えてみましたが、さすがにここまで来るとくたびれてしまい「バグが取れるまで待とうか...」という気持ちになります（笑）。これ以上複雑な対策用コードに組み込むと、逆にバグが取れて正常な状態に戻った時に、コードを戻し忘れて弊害が発生する懸念もあります。「バグ対策が次の瞬間バグになる」と言う、開発者がもっとも恐れている現象ですね。

戦いは終わりました...。現在このバグはMac OS X 10.2.4でも改善されていません。多分10.2の間はそのまま放置されるでしょう。今回の戦いは敗北に終わりましたが（笑）、筆者自身としては多くのことを学ぶことができ、スキルアップにはバグとの格闘が一番であると再認識した良い経験となりました。

おわり