|
6.18 【AEDataModel.hのバグ？】
まず、5.21に書いた「Phutを隠す」問題について。アンカーを設定してあるウィンドウが隠れてしまうというのはすぐにわかったのだが、どこがまずいのかを特定するのに時間がかかってしまった。
原因は、GetWindowBounds()の呼び出しだった。このルーチンを呼んだ時にアプリケーションが隠されているとウィンドウが非表示になってしまうらしいのだ。結局、これを呼んだあとにウィンドウが隠されてしまっていたら表示しなおすという方法により解決。「再表示」されたことがわかるのであれば楽だが（あるいは「隠された」状態であることがわかるのでもいいけど）、その方法がわからなかったので。
そういえば、いつからかわからないが、Phut carbonでNavi iRaeを使用してもデバッガに落ちなくなった（この件について書いたのは2.23らしい）。その時とNavi iRaeのバージョンは変わっていないし、CrabonLibがバージョンアップしたからなのかなぁ。
もう一つ、CarbonLib関係のこと。アプリケーションを切り替えた時にパレットが隠れてしまう問題については、CarbonLib
1.0.4を入れることによって解決するようだ。この件について報告いただいた方、ありがとうございます。
5.27に書いた「Postino QuoColor」と「Proformance3」とのコンフリクトの件。この症状は、コントロールパネルでフォントキャッシュを有効にした場合に起こるそうだ。内部でどういう処理をしているのかはわからないが、おそらくキャッシュにヒットした時にはQuickDrawをバイパスしているのであろう。となると対処のしようがないわけで、この件に関してはこれで終わり。
PhutをAppleScript対応にしようかなと思い、少しずつ手をつけているところ。QT-Qで作成したソースをコピーしてきたりして、各オブジェクトのプロパティが取りだせる（GET）ところまでは完成。パレット内の各アイテムの指定については、DragStripが「button
1 of ...」という実装をしていたのでそれに倣う。本当は{3,4}とかいう形で指定できたらいいのだが、どうも無理みたいだし。
QT-Qの時は、アプリケーションの下にウィンドウクラスがあるという単純な形だったので指定されたオブジェクトを取り出す部分はそれほど苦労しなかったのだが（ま、初めてだったのでたいへんだったけど）、今回はウィンドウクラスの下にボタンクラスを用意したためその間の処理に手間取った。ボタンを指定するトークンには「どのウィンドウのボタンか」という情報がいるわけで、これをどうやって渡すかという部分。サンプルコードを参考にして適当に
/* ウィンドウトークンからボタントークンを作成 */
pascal OSErr CoerceWindowToButton(const AEDesc *theAEDesc,
DescType toType,
long handlerRefCon,
AEDesc *result)
{
#pragma unused (toType,handlerRefCon)
ButtonToken aToken;
OSErr err;
AEDesc aDesc = {typeNull,NULL};
WindowToken aWindowToken;
Size actualSize;
err=AECoerceDesc(theAEDesc,typeMyWindow,&aDesc);
if (err != noErr) goto done;
GetRawDataFromDescriptor(&aDesc,(Ptr)&aWindowToken,
sizeof(aWindowToken),&actualSize);
aToken.tokenWindow=aWindowToken.tokenWindow;
err=AECreateDesc(typeMyButton,(Ptr)&aToken,sizeof(aToken),result);
done:
if (aDesc.dataHandle)
AEDisposeDesc(&aDesc);
return(err);
}
|
こんなコードを書いてみたら、これがまたあっさりと動いた（汗）。このコードはAECoerceDesc()から内部的に呼ばれるもので、AEInstallCoercionHandler()で組み込んでおく。要は、「○○のタイプから××のタイプに変換する命令が来たらここを呼んでね」というルーチンになるわけ。中で使っている「ButtonToken」とか「WindowToken」とか「TypeMyButton」とかは自分で定義したもの。これらがなにを意味しているかは別に重要ではなくて、あくまで「こういう概念です」という説明なので深く考えないように。
このルーチンをインストールするのにAEInstallCoercionHandler()を使うと書いたが、そこに少し問題がある。Classicアプリを作っているのであればなにも困ることはないが、Carbonアプリではコンパイル時にエラーが出てしまうのだ。
CarbonとAppleScriptをサポートしているサンプルコードなんて見たことがないし、さっぱり原因がわからない。同じようにインストールするオブジェクトアクセッサの方は正常にコンパイルできるのでそれらのヘッダファイルを比較してみると、どうも「AEDataModel.h」がおかしいようだ。
具体的には、255行の「typedef UniversalProcPtr AECoercionHandlerUPP;」を削除、259行、267行、273行の「AECoercionHandlerUPP」を「AECoerceDescUPP」に変更すればコンパイルできるようになる（CarbonSDK
1.0.4付属のもの、およびUniversal Interfaces 3.3.2付属のものともに）。アプリケーションも正常に動作したし、この変更でおそらく大丈夫だと思うが、問題点など発見された方は御一報いただけるとうれしい。また、もしこの問題で困っているかたがいらしたら、なにかの参考になれば。
6.3に書いたSSIでテキストカウンタの件を書こうかなと思ったけど、長くなってきたので今回はこのへんで。
|