Ko-Window プログラマーズマニュアル 「ユーザーイベントの割り当て方法」 ●昔のユーザーイベント Ko-Window では、ユーザーアプリケーション用に EventUser を用いることができま す。v2.00 等の昔のサーバーでは、利用方法に特に取り決めはなく、FINDER.win の ファイル名転送に ComBuffer が使われていただけでした。そのため実際は FINDER とぶつからないように、きわめてトリック的な使い方が必要で、その頃の影響が今の USK_WIN 等の独自のフォント転送フォーマットに残されています。 ●システムで決まっているユーザーコード それを考慮してか、従来使われていなかった ComData を識別コードとし、実際の データは常に ComBuffer の示すポインタで転送するよう prog.doc で取り決めが行 なわれました。 イベント構造体の中で、UserEvent で主に用いられるのは次の２つです。 int ComData 32bit の整数値 void *ComBuffer データ領域へのアドレス 各アプリケーションは、EventUser を受け取る場合には必ず ComData を参照し、そ の値によって ComBuffer からデータを得ます。ComData が自分の欲しいイベントデー タでないなら、受け取りません。 prog.doc の取り決めでは、ComData で使用する識別コードは UserPaste UserString UserStrings UserSheet の４つのみ規定されています。これらは今までのアプリケーションで慣例的に使われ てきたいくつかの暗黙のルールのようなものがありますので、それを説明します。 ComData が UserPaste の時の ComBuffer は、char* であり、Clip Board の内容 を示しています。これは通常、ウィンドウマネージャーが発するイベントです。アプ リケーションはこれをキー入力として受け取るものもありますが、いきなり単体のファ イル名としてアクションを起こす場合もあります。そのへんの使い分けが、UserString と微妙に違います。もし複数行にデータが渡る場合は、その区切りは改行キーコード になります。データの終わりは '\0' です。 ComData が UserString では、ComBuffer はやはり char* であり、こちらはただ の文字列を転送する場合によく用いられます。受け取り側はそれをキー入力やファイ ル名等必要に応じて処理します。または外部からの制御コマンドの送信に使われるこ ともあります。 ComData が UserStrings では、ComBuffer は char** です。これは FINDER での ファイル名転送フォーマットからきています。KF 等でもこれを用いますので、通常 この UserStrings が送られてきたら、1つ以上のファイル名を示すポインタ配列への ポインタと見てまず間違いないでしょう。もちろん、ただの複数文字列として転送に 用いることもできます。Command.win 等では受け取った場合はただのキー入力になり ます。 ComData が UserSheet の場合では、ComBuffer は必ず Sheet* でテキストのグラ フィックパターンを示します。PED や背景等で使う３階調モノクロのビットマップで す。Ko-Window 上でのパターン転送では、必ずこのイベントが使われています。（唯 一の例外が USK_WIN, TC_WIN 等の旧型フォントデータです） case UserEvent: switch( info->ComData ){ default: return FALSE; case UserStrng: case UserPaste: KeyString( (char*)info->ComBuffer ); break; case UserStrings: : : } return TRUE; UserEvent 受取例の一部 (よく用いられるパターン) ●ユーザーコードの拡張 さて、上記以外のデータを転送する必要が生じた場合どうすればいいのでしょうか。 prog.doc では、UserSheet から続くコードを便宜割り当てユーザー側で使用できる ように書いていますが、それでは他の人とコードの取合いになってしまい都合が悪い のです。 そこで、今までの私の各種アプリケーションでは、以下のようなルールによってユー ザーコードを使用してきました。 ・単純なデータは文字列で転送する (UserString/UserStrings) 文字列でデータを判別し、各ファンクションコードは文字列先頭の識別子 で判定する。 ・各アプリケーションのコントロールファンクション呼び出しは、半角４文 字以内で識別子を付け、それをそのまま 32bit の ComData として呼び出 す。 ここで、アプリケーションのコントロールファンクションについてちょっとだけ説 明します。今まで私が組んできたプログラムは、早期からウィンドウ間通信の柔軟性 を大切にしてきました。できるだけデータはウィンドウ外部と任意にやりとりでき、 さらに外部から簡単なイベントコードでそのアプリケーションをコントロールするこ とができます。 例えば、KF なら ComData= 'KF' として、ComBuffer に実行させたいファンクショ ン命令文字列のアドレスを入れて転送すると、KF はそれに従った動作をします。つ まり共通性を持たせるデータだけでなく、その動作をも他のアプリケーションに公開 してしまうのです。 これは、Command.win でも KX_Term20 でもなんでも、内部で複雑な動作のできる 重要なアプリケーションは全部持っています。 そこで、このような外部からそのアプリケーション独自のイベントが必要な場合に は、KF なら 'KF' 、KX_Term20 なら 'K20' というようにコード割り当てを行ないま す。 もちろん、たった４文字なので衝突が起こらないとも限りませんが、わかりにくい コードを順に割り当てるよりはかなり良いのではないでしょうか。よって、今後この ようなユーザーコードの使用法を使うようにしましょう。また、今まではどちらかと いうと隠し機能的な扱いであったコントロールファンクションですが、今後識別子を ドキュメント等で積極的に公開していくことにしましょう。 識別子の付け方は、むやみやたらに用いずできるだけそのアプリケーションが連想 できるもの、バージョン名等を含ませずに、同じアプリケーションなら一貫してその コードが使えること。もちろん、原則として１アプリケーションは１識別子を用い、 機能の分岐は ConBuffer を使います。ComBuffer はできるだけ文字列へのポインタと し、直接データを持たず、将来そのアプリケーションで機能拡張が行なわれても問題 ないようにしましょう。 １番いいのは UserStrings のように、ポインタ配列へのポインタとし、最初のポ インタは、正式なプログラム名で始まる機能を表す文字列を格納します。それ以後の ポインタは引数として、機能によってさまざまなデータを置くことができます。 (もちろん、強制ではありません) 話はそれますが、上記のコントロールファンクションで述べたように、Ko-Window の１つの顔として、この柔軟なウィンドウ間通信があげられるようさまざまやってき ました。ですから、ぜひ皆さんのプログラムも、もっとウィンドウ間通信のやりとり の重要性に理解を示し、積極的にアプリケーションに組み込んでみて下さい。 1993/4/20 小笠原博之 oga@dgw.yz.yamagata-u.ac.jp DenDenNET: DEN0006 COR.