JPH09204312A

JPH09204312A - 多数のウィンドウのイベント分散を合併する方法およびシステム

Info

Publication number: JPH09204312A
Application number: JP8345919A
Authority: JP
Inventors: W Hiisaa Gregory; グレゴリー・ダブリュ・ヒィサー; John Nelson Christopher; クリストファー・ジョン・ネルソン; Jeffrey Purple Lance; ランス・ジェフリー・パープル; Allen Williamson Ray; レイ・アレン・ウィリアムソン; Yun Yan Chin; チン・ユン・ヤン
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1996-01-16
Filing date: 1996-12-25
Publication date: 1997-08-05

Abstract

(57)【要約】（修正有）【課題】コンピュータ・システム内で多数のソフトウェ
ア・システムに対してイベント分散を提供する。【解決手段】ユーザ入力イベントがもしメニュー・アク
セス・イベントであるならば、システムは、メニュー・
バー・イベント・ハンドラによってそのイベントを処理
し、ユーザ入力イベントがもしそうではないならば、そ
のイベントが正規のイベントであるかどうかを判定し、
もしそうであるならば、そのイベントが意味イベントで
あるかどうかを判定し、意味イベントであるならば、そ
れを意味インタフェース・イベント・ハンドラに送り、
もしそうではないならば、そのイベントのタイプを決定
し、そのイベントのソフトウェア・システム宛先を決定
しそこにディスパッチする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はデータ処理システム
に関する。より詳細には、本発明は、多重ソフトウェア
・システム環境において共用イベント分散を提供するこ
とに関する。

【０００２】

【従来の技術】コンピュータ・システムは当業者には周
知であり、米国ビジネスのあらゆる側面に浸透してい
る。ビジネス界におけるコンピュータの拡散の一つの理
由は、コンピュータ・システムが多様な仕事を効率的に
実行する能力にある。そのような仕事を実行するために
コンピュータ・システムによって使用される機構が「コ
ンピュータ・プログラム」と呼ばれている。

【０００３】コンピュータ・システムそのものと同様、
コンピュータ・プログラムも長年にわたって進化した。
今日、コンピュータ・プログラムは、異なるプラットフ
ォームどうしでの価格適合性が重大な問題になるところ
にまで拡散した。共通の基準を提供するための一つの試
みは、オブジェクト指向プログラミング（ＯＯＰ）に頼
ることである。通常、ＯＯＰは、一つのオブジェクト
が、そのオブジェクトによって制御される情報に対して
コンピュータ・システムが実行する個々の操作または一
群の操作を表すため、コンピュータ・プログラマの能率
を大幅に増すと考えられている。これらのオブジェクト
は、特定の仕事を実行するために他のエージェントと協
同するアナトモナス（anatomonous）エージェントのよ
うなものである。コンピュータ・プログラム全体がオブ
ジェクトの群によってできていることもあるし、一つの
特定のタスクまたはサブタスクを実行するために、オブ
ジェクトがより従来的なコンピュータ・プログラムによ
って単にアクセスされるだけのこともある。

【０００４】いくつかのグラフィカル・ユーザ・インタ
ーフェース・システムがオブジェクト指向プログラミン
グのインプリメンテーションに頼っている。そのような
システムの一つがOpenDocシステムである。OpenDocは、
複合ドキュメントに用いるためのＡＰＩおよびソフトウ
ェアの集合である。これは、範囲および機能においてオ
ブジェクト連結貼り込みに類似しているが、Microsoft
社ではなくＣＩ Labsから出されたものである。Compone
nt Integration Lab（ＣＩ Labs）は、１９９３年９月
に、Apple、ＩＢＭ、Novell、Oracle、SunSoft、WordPe
rfectおよびXeroxによって設立された。OpenDocを記載
する詳細は以下の二つの文献に開示されている。一つ
は、OpenDoc: The New Shape of Softwareと題するもの
（CI Labs、１９９４年、１〜８頁）である。もう一つ
は、Robert Orfali、Dan HarkeyおよびJeri Edwardsに
よる、Client/Server Components: CORBA Meets OpenDo
cと題するもの（Object Magazine、１９９５年５月）で
ある。

【０００５】OpenDocは、複合ドキュメントのためのベ
ンダ固有のオープン基準になることを意図している。
「複合ドキュメント」とは、多数の異なる種類の内容か
らなり、それらすべてが一つのファイルを共用している
ドキュメントである。これらのドキュメントは、ほぼい
かなるタイプのデータ、例えば表、チャートおよびテキ
ストならびに画像、音声、ノート・カードもしくは３Ｄ
グラフィックスを含むことができる。

【０００６】OpenDocは、Macintoshによってそのオペレ
ーティング・システム（ＯＳ７）中にインプリメントさ
れ、また、MicrosoftによってWindows中にインプリメン
トされている。

【０００７】OpenDocは、これまでのところ、Ｘウィン
ドウ・プラットフォームが設けられているUnixソフトウ
ェア・システム中にはインプリメントされていない。Op
enDocがインプリメントされている他のソフトウェアに
おいては、これらのシステムは、一つの扱われるイベン
ト・メソッド（もしくはオブジェクト）を介してすべて
のイベントを受けるためのパート・ハンドラを必要と
し、したがって、これらのプラットフォームにおける既
存のアプリケーションは、OpenDocパート・ハンドラに
変換されたとき、広範囲に書き直されなければならな
い。

【０００８】OpenDocをUnixソフトウェア・システム、
好ましくはＩＢＭ社によって提供されるＡＩＸシステム
に移植する目標の一つは、既存のMotifおよびXlibアプ
リケーションを、コードを最大限に再利用しながら、Op
enDocオブジェクトまたはパート・ハンドラに変換でき
るようにすることである。問題は、既存のグラフィカル
・ユーザ・インターフェース・アプリケーション・コー
ドが、Ｘイベント・コールバック関数を幅広く用いて構
成されており、OpenDocパート・ハンドラ・コードが、
すべてのイベントを、パート・ハンドラのハンドル・イ
ベント・メソッドである一つのエントリ・ポイントに運
ぶために、OpenDocディスパッチまたはオブジェクトに
依存して構成されていることにある。OpenDocオブジェ
クトはまた、標準のXlibイベント列の一部ではない特定
のイベント・タイプをも予期する。

【０００９】Unix環境においてOpenDocイベントとＸウ
ィンドウ・イベントとの分散の合併を可能にする機構が
なければ、市販のコンピュータ・ユーザは、Unixベース
のＸウィンドウ・プラットフォームにおいてOpenDocの
利益を十分に享受することは絶対にできない。

【００１０】

【発明が解決しようとする課題】したがって、本発明の
一つの目的は、データ処理システムを提供することにあ
る。

【００１１】本発明のもう一つの目的は、多重ソフトウ
ェア・システム環境において共用イベント分散を提供す
ることにある。

【００１２】

【課題を解決するための手段】前記の目的は、以下に記
載するようにして達成される。本発明にしたがって、多
数のアクティブなグラフィカル・ユーザ・インターフェ
ース・ソフトウェア・システムを支援するコンピュータ
・システムが開示される。典型的なコンピュータ・シス
テムは、バスと、中央処理装置と、バスを介して中央処
理装置に結合されたコンピュータ・システム・メモリと
を含む。通常は動作中にコンピュータ・システム・メモ
リにロードされる共用ソフトウェア・システム・イベン
ト・ディスパッチャが、ユーザ入力イベントを、入力イ
ベントのタイプおよびその予定の宛先に基づいて、適切
なソフトウェア・システムに宛てて送る。コンピュータ
・システムはさらに、共用ソフトウェア・システム・イ
ベント・ディスパッチャによって処理するためのユーザ
入力イベントを受ける、共用ソフトウェア・システム・
イベント・ディスパッチャに関連するイベント待ち行列
を含む。さらには、イベント・ディスパッチャによって
処理するためのユーザ入力イベントをメニュー・イベン
トまたは意味イベントのいずれかとして識別する共用ソ
フトウェア・システム・シェルが設けられている。また
さらに、ディスパッチャに接続されたディスパッチ・モ
ジュールが、各イベントに関連する適切なパート・ハン
ドラによる操作のために、ディスパッチャによって受け
られ、分散された、選択されたイベント・タイプを扱
う。

【００１３】好ましい実施態様においては、ソフトウェ
ア・システムの二つは、OpenDocソフトウェア・システ
ムおよびＸウィンドウ・ソフトウェア・システムであ
る。両ソフトウェア・システムとも、所与のイベントの
タイプおよび宛先によって識別される。所与のパート・
ハンドラは、定義されたアービトレーションおよびフォ
ーカス・セットに基づいて選択される。

【００１４】また、コンピュータ・システム内で多数の
ソフトウェア・システムに対してイベント分散を提供す
る方法が開示される。この方法はまず、ユーザ入力イベ
ントを受け、次に、そのユーザ入力イベントがメニュー
・アクセス・イベントであるかどうかを判定する。ユー
ザ入力イベントがメニュー・アクセス・イベントである
ならば、システムは、コンピュータ・システム内でメニ
ュー・バー・イベント・ハンドラによってそのメニュー
・アクセスを処理する。ユーザ入力イベントがメニュー
・アクセスではないならば、システムは、そのユーザ入
力イベントが正規のイベントであるかどうかを判定す
る。ユーザ入力イベントが正規のイベントであるなら
ば、システムは、そのイベントが意味イベントであるか
どうかを判定し、意味イベントであるならば、そのイベ
ントを意味インタフェース・イベント・ハンドラに送
る。イベントが意味イベントではないならば、システム
は、そのイベントのタイプを決定する。イベントのその
宛先またはソフトウェア・システム宛先を決定すると、
システムは、イベントをその決定したソフトウェア・シ
ステム宛先にディスパッチする。

【００１５】本発明の上記ならびにさらなる目的、特徴
および利点は、以下の詳細な記載において明白に理解さ
れるであろう。

【００１６】

【発明の実施の形態】図面、特に図１を参照すると、本
発明の方法を具現化するために用いることができるデー
タ処理システムの好ましい実施態様が示されている。図
示するように、データ処理システム１０は、システム装
置１２と、ディスプレイ装置１４と、キーボード１６
と、マウス１８と、プリンタ２０とを含む。当該技術に
おいて周知であるように、システム装置１２は、入力装
置、例えばキーボード１６、マウス１８またはローカル
・エリア・ネットワーク・インタフェース（図示せず）
から、処理すべきデータを受ける。マウス１８は、好ま
しくは、データ処理システム部品およびアプリケーショ
ン・プログラムを含むハードウェアおよびソフトウェア
・システム・オブジェクトが、ディスプレイ装置１４内
に表示された関連の図形オブジェクトの選択および操作
によって制御されるグラフィカル・ユーザ・インターフ
ェース（ＧＵＩ）とともに用いられる。データ処理シス
テム１０はマウス１８を備えた状態で示されているが、
当業者であれば、グラフィックス・タブレット、スタイ
ラス、ライト・ペン、ジョイスティック、パック、トラ
ックボール、トラックパッドおよびＩＢＭ社のTrackPoi
nt（商標）をはじめとする他の図形ポインティング装置
を用いてもよいことを認識するであろう。データ処理シ
ステム１０は、ディスプレイ装置１４およびプリンタ２
０を介して出力データをユーザに提示する。データの記
憶および検索を支援するため、システム装置１２はさら
に、周知の方法でシステム装置１２に接続されたディス
ケット・ドライブ２２、ハードディスク・ドライブ２３
およびＣＤ−ＲＯＭドライブ２４を含む。当然、当業者
であれば、他の従来の構成部品をもシステム装置１２に
接続できることを認識するであろう。

【００１７】次に図２を参照すると、データ処理システ
ム１０のシステム装置１２の主要構成部品のブロック図
が示されている。図示するように、システム装置１２
は、ソフトウェア指示を実行する中央処理装置（ＣＰ
Ｕ）２６を含む。ＣＰＵ２６にはいかなる適切なマイク
ロプロセッサを用いてもよいが、ＣＰＵ２６は、好まし
くは、ＩＢＭ Microelectronics社から市販されているP
owerPC（商標）ラインのマイクロプロセッサの１種であ
る。あるいはまた、ＣＰＵ２６は、多数のベンダから市
販されている８ＯＸ８６マイクロプロセッサの１種とし
て具現化することもできる。ＣＰＵ２６に加えて、任意
の算術コプロセッサ２７、キャッシュ制御装置２８およ
びキャッシュ・メモリ３０が高速ＣＰＵローカル・バス
２５に結合されている。算術コプロセッサ２７は、ＣＰ
Ｕ２６よりも効率的に数学的計算を実行する、ＣＰＵ２
６とは別個の任意のプロセッサである。算術コプロセッ
サによって提供される性能の利点はＣＰＵ２６の機能強
化、例えば多数の浮動小数点実行装置の具現化によって
も達成することができるため、算術コプロセッサ２７は
任意に用いられる。キャッシュ・メモリ３０は、頻繁に
アクセスされるデータおよび指示を記憶する小型の高速
メモリである。キャッシュ３０の動作は、キャッシュ３
０の内容のディレクトリを維持し、選択されたキャッシ
ュ一貫性プロトコルを執行するキャッシュ制御装置２８
によって制御される。

【００１８】ＣＰＵローカル・バス２５がバッファ３２
に結合されて、ＣＰＵローカル・バス２５とシステム・
バス３４との間に通信を提供している。このシステム・
バスは、バッファ３２とさらなるバッファ３６との間に
延びている。システム・バス３４は、バス制御およびタ
イミング装置３８と、中央アービタ４８およびＤＭＡ制
御装置４１を含む直接メモリ・アクセス（ＤＭＡ）装置
４０とに接続されている。ＤＭＡ制御装置４１は、ＣＰ
Ｕ２６を関連させないメモリ・アクセスを支援する。直
接メモリ・アクセスは通常、データをＲＡＭ５８とイン
テリジェント周辺装置、例えばディスク・アダプタ８２
との間で直接伝送するために用いられる。多数の周辺装
置からのＤＭＡ要求は中央アービタ４８によって裁定さ
れる。以下に説明するように、中央アービタ４８はま
た、拡張バス４４に結合された装置へのアクセスを、ア
ービトレーション制御バス４２を介して伝送される制御
信号によって規制する。

【００１９】ＣＰＵ２６は、メモリ制御ユニット５２、
アドレス・マルチプレクサ５４およびデータ・バッファ
５６を含むメモリ制御装置５０を介して、揮発性ランダ
ム・アクセス・メモリ（ＲＡＭ）５８からのデータおよ
び指示にアクセスし、また、データをそこに記憶する。
メモリ制御ユニット５２は、読み出しイネーブルおよび
書き込みイネーブル信号を生成してデータの記憶および
検索を容易にし、ＣＰＵ２６によって用いられる仮想ア
ドレスをＲＡＭ５８内の物理アドレスにマッピングする
アドレス翻訳機能を含む。当業者であれば察知しうるよ
うに、ＲＡＭ５８は、データ処理システム１０に電力が
供給されている間、オペレーティング・システムおよび
アプリケーション・ソフトウェアのセグメントを記憶す
る個々の揮発性メモリ・モジュールを数多く含む。ソフ
トウェア・セグメントは、それぞれが均等な数の仮想メ
モリ・アドレスを含む１個以上の仮想メモリ・ページに
分割される。ソフトウェアの実行が、ＲＡＭ５８内に記
憶することができるよりも多くのページの仮想メモリを
要する場合、現在必要とされないページが必要なページ
と交換され、それら必要なページが不揮発性記憶装置２
２〜２４の中に記憶される。

【００２０】メモリ制御装置５０はさらに、ＲＡＭ５８
内の特定のアドレスを選択するアドレス・マルチプレク
サ５４と、ＲＡＭ５８から読み出され、そこに記憶され
るデータを緩衝記憶するデータ・バッファ５６とを含
む。メモリ制御装置５０はまた、システム・プロセスお
よびユーザ・プロセスを各プロセスに割り当てられた仮
想アドレス空間内に隔離するメモリ保護を提供する。し
たがって、ユーザ・モードで動作するプログラムは、そ
の仮想アドレス空間に割り当てられたメモリにしかアク
セスすることができない。すなわち、ユーザ・モードの
プログラムは、プロセス間のメモリ共用が支援され、そ
のプログラムが適切なアクセス特権を有しない限り、別
のプロセスの仮想アドレス空間内のメモリにはアクセス
することができない。

【００２１】さらに図２を参照すると、バッファ３６
が、システムバス３４と拡張バス４４との間にインタフ
ェースを提供している。拡張バス４４には、アダプタ・
カードを受け入れるための多数の入出力スロット４６が
接続されており、これらがさらに入出力装置またはメモ
リに接続されていてもよい。アービトレーション制御バ
ス４２がＤＭＡ制御装置４１および中央アービタ４８を
入出力スロット４６およびディスク・アダプタ８２に結
合している。バス・アービトレーション・プロトコルを
インプリメントすることにより、中央アービタ４８は、
拡張カード、制御装置およびＣＰＵ２６による拡張バス
４４へのアクセスを規制する。加えて、中央アービタ４
８は、拡張バス４４に結合されたバス・マスタの間で拡
張バス４４の所有権に関してアービトレーションを下
す。バス・マスタ支援は、プロセッサおよびその支援チ
ップを含むバス・マスタ・アダプタの追加によって拡張
バス４４のマルチプロセッサ構成を作り出すことを可能
にする。

【００２２】システムバス３４は、バッファ６６を介し
て平面入出力バス６８に結合されている。平面入出力バ
ス６８には、ディスプレイ・アダプタ７０、ディスク・
アダプタ８２、不揮発性ＲＡＭ７４、クロック７２、シ
リアル・アダプタ７８、タイマ８０、読み出し専用メモ
リ（ＲＯＭ）８６、ＣＤ−ＲＯＭアダプタ８８、キーボ
ード／マウス制御装置８４、ネットワーク・アダプタ８
５、モデム８７およびパラレル・アダプタ７６をはじめ
とする多様な入出力アダプタおよび他の周辺部品が取り
付けられている。ディスプレイ・アダプタ７０は、ＣＰ
Ｕ２６からのグラフィックス・データを、ディスプレイ
装置１４を駆動するのに用いられるＲ、ＧおよびＢ画像
信号に変換する。オペレーティング・システムおよび動
作中のアプリケーション・ソフトウェアに依存して、視
覚的出力は、テキスト、グラフィックス、アニメーショ
ンおよびマルチメディア画像を含むことができる。ディ
スク・アダプタ８２は、ハードディスク・ドライブ２４
およびディスケット・ドライブ２２へのデータの記憶お
よびそこからのデータの検索を制御する。ディスク・ア
ダプタ８２は、ドライブ２２および２３内でのドライブ
読み／書きヘッドの位置決めや、ドライブ２２および２
３とＣＰＵ２６との間の媒介のようなタスクを扱う。不
揮発性ＲＡＭ７４は、データ処理システム１０の現在の
構成を表すシステム構成データを記憶する。例えば、不
揮発性ＲＡＭ７４は、ハードディスク・ドライブ２４ま
たはディスケット・ドライブ２２に挿入されたディスケ
ットの容量、ディスプレイ装置１４のタイプ、ＲＡＭ５
８の空き容量および現在のシステム構成を表す情報を含
む。データ処理システム１０の電源を絶ったとしても、
これらのデータは不揮発性ＲＡＭ７４に記憶されたまま
残る。

【００２３】クロック７２は、時刻の計算のためにＣＰ
Ｕ２６によって実行されるアプリケーション・プログラ
ムによって用いられる。シリアル・アダプタ７８は、デ
ータ処理システム１０を使用可能にして、遠隔データ処
理システムまたは周辺装置と通信させる同期または非同
期のシリアル・インタフェースを提供する。シリアル通
信は、シリアル通信プロトコル、例えばＲＳ−２３２、
ＲＳ−４２２などによって支配される。タイマ８０は、
データ処理システム１０内の一つ以上の選択されたイベ
ントを計時するためにアプリケーションまたはオペレー
ティング・システム・ソフトウェアによって用いること
ができる多数のインタバル・タイマを含む。

【００２４】ＲＯＭ８６は通常、ＣＰＵ２６がＤＯＳオ
ペレーティング・システムの下で動作しているときにユ
ーザ透過的な入出力を提供する基本入出力システム（Ｂ
ＩＯＳ）を記憶する。ＢＩＯＳはまた、起動時にシステ
ム・セットアップを実行するパワー・オン自己試験（Ｐ
ＯＳＴ）診断ルーチンを含む。例えば、ＰＯＳＴは、ハ
ードウェアに問い合わせを行い、ＢＩＯＳデータ・エリ
ア（ＢＤＡ）を割り当て、割り込みベクトル・テーブル
を構成してＲＯＭ８６内の割り込み扱いルーチンを指し
示し、タイマ８０、クロック７２およびシステム装置１
２中の他の装置を初期化する。ＣＤ−ＲＯＭアダプタ８
８は、ＣＤ−ＲＯＭドライブ２４を平面入出力バス３４
とインタフェースさせて、ＣＤ−ＲＯＭドライブ２４に
装填された光ディスクからのデータの検索を支援する。
キーボート／マウス制御装置８４は、システム装置１２
をキーボード１６および図形ポインティング装置、例え
ばマウス１８とインタフェースさせる。以下さらに詳細
に説明するように、キーボート／マウス制御装置８４
は、マウス１８の各増分移動を示す直列信号をマウスか
ら受ける。

【００２５】最後に、システム装置１２は、データ処理
システム１０と周辺装置または他のデータ処理システム
との間の通信を容易にするネットワーク・アダプタ８
５、モデム８７およびパラレル・アダプタ７６を含む。
ネットワーク・アダプタ８５は、データ処理システム１
０を、図示しないローカル・エリア・ネットワーク（Ｌ
ＡＮ）に接続するのに用いられる。ＬＡＮは、データ処
理システム１０のユーザに対し、遠隔コンピュータまた
はネットワーク論理記憶装置を用いて、ソフトウェアを
含む情報を電子的に通信する手段を提供する。さらに
は、ＬＡＮは、データ処理システム１０がＬＡＮにリン
クされた他のデータ処理システムとでタスクを分担する
ことを可能にする分散処理を支援する。モデム８７は、
データ処理システム１０と別のデータ処理システムとの
間の、標準の電話回線を介する通信を支援する。例え
ば、モデム８７を用いて、データ処理システム１０をオ
ンライン情報サービス、例えばProdigy Services社によ
ってサービスマーク「PRODIGY」の下で提供される情報
サービスに接続してもよい。このようなオンライン・サ
ービス提供業者はしばしば、モデム８７を介してデータ
処理システム１０にダウンロードすることができるソフ
トウェアを提供する。さらには、モデム８７を通じて、
データ処理システム１０は、他のソフトウェアのソー
ス、例えばサーバ、電子掲示板およびインターネットも
しくはワールド・ワイド・ウェブにアクセスすることが
できる。パラレル・アダプタ７６は、パラレル・ポート
を介してプリンタ制御信号および出力データをプリンタ
２０に伝送する。

【００２６】多くのデータ処理システムに典型的である
ように、起動直後、データ処理システム１０の種々のハ
ードウェア構成部品はそれぞれ自らの内部リセット手続
きを実行して、安定な既知の状態を再び得る。これらの
リセット手続きが完了すると、ＣＰＵ２６がＲＯＭ８６
内でＰＯＳＴコードを実行して、システムのハードウェ
アを初期化し、ＢＩＯＳデータ・エリアをセットアップ
し、ベクトル・テーブルおよびその他のタスクを構成
し、割り込ませる。ＰＯＳＴに続き、「ブートストラッ
プ」または一次オペレーティング・システム・ローダが
動作して、オペレーティング・システム（ＯＳ）１００
（図３を参照）のセグメントをＲＡＭ５８にロードし、
本発明の好ましい実施態様においてはＩＢＭ社から市販
されているＡＩＸを含むＯＳ１００の実行を開始する。

【００２７】次に図３を参照すると、起動直後のデータ
処理システム１０のソフトウェア構成が図示されてい
る。図示するように、データ処理システム１０のソフト
ウェア構成は、カーネル１０２を含むＯＳ１００と、ア
プリケーション・プログラム・インタフェース（ＡＰ
Ｉ）１１０を介してＯＳ１００と通信する一つ以上のア
プリケーション１０８とを含む。カーネル１０２は、装
置ドライバ、例えば図形ポインタ装置ドライバ１０４お
よびディスプレイ装置ドライバ１０６によってデータ処
理システム１０のハードウェア構成部品の動作を制御す
る最低レベルのＯＳ１００を含む。

【００２８】図示するように、図形ポインタ装置ドライ
バ１０４およびディスプレイ装置ドライバ１０６は、キ
ーボード／マウス制御装置８４およびディスプレイ・ア
ダプタ７０とそれぞれ通信して、マウス１８（底面図で
示す）およびディスプレイ装置１４とデータ処理システ
ム１０との相互接続を支援する。マウス１８のトラック
ボール１９の動きに応答して、マウス１８は、トラック
ボール１９の方向および回転を表すアナログ図形ポイン
タ信号をキーボード／マウス制御装置８４に伝送する。
キーボート／マウス制御装置８４は、アナログ図形ポイ
ンタ信号をデジタル化し、デジタル化した図形ポインタ
信号を図形ポインタ装置ドライバ１０４に伝送し、その
後、このドライバがデジタル化した図形ポインタ信号を
解釈し、解釈した図形ポインタ信号をカーネル１０２内
の図形ポインタ速度モジュール１１２に送る。図形ポイ
ンタ速度モジュール１１２は、解釈された図形ポインタ
信号を修飾して、マウス１８を用いて操作される図形ポ
インタの移動を減速または加速させる。そして、図形ポ
インタ速度モジュールは、修飾され、解釈された図形ポ
インタ信号を画面モニタ・モジュール１１４に渡し、こ
のモジュールが、ディスプレイ装置１４内の図形ポイン
タの位置に基づいてＧＵＩ動作を実行する。例えば、画
面モニタ・モジュール１１４は、ユーザがウィンドウ内
の位置を選択したことに応答して、ＧＵＩ内でウィンド
ウを浮き出させる。加えて、本発明によると、画面モニ
タ・モジュール１１４は、図形ポインタがディスプレイ
装置１４内に表示された装置（widget）内に配置された
ときの図形ポインタの走査速度を選択的に制御する。最
後に、図形ポインタ信号はディスプレイ装置ドライバ１
０６に渡され、このドライバが、図形ポインタ信号中の
データおよび他の表示データをディスプレイ・アダプタ
７０に送り、このアダプタが、その表示データを、ディ
スプレイ装置１４を駆動するのに用いられるＲ、Ｇおよ
びＢ信号に変換する。このように、マウス１８のトラッ
クボール１９の動きが、ディスプレイ装置１４内に表示
される図形ポインタの相当する動きを生じさせる。

【００２９】好ましいＯＳ１００は、図形表示にＸウィ
ンドウシステムを使用するUnixベースのオペレーティン
グ・システム、例えばＩＢＭ社によって提供されるＡＩ
Ｘである。OpenDocシステムは、既存のMotifおよびXlib
アプリケーションを、コードを最大限に再利用しなが
ら、ソフトウェア部品であるOpenDocオブジェクトに変
換することを可能にする。残念ながら、既存のアプリケ
ーションのグラフィカル・ユーザ・インターフェース・
アプリケーション・コードは、XEventコールバック関数
を広く使用して構成されており、OpenDocパート・ハン
ドラ・コードは、すべてのイベントを一つのエントリポ
イントに運ぶために、OpenDocのODDispatcherオブジェ
クトに依存して構成されている。さらに、OpenDocオブ
ジェクトはまた、標準のXlibイベント列の一部ではない
特定のイベント・タイプを予期する。

【００３０】本発明は、OpenDocイベント・ディスパッ
チャをXt組み込み関数イベント・ディスパッチャと合併
することによってこれらの欠点を解消する。すべてのイ
ベントは、標準的なXlibイベントであろうとOpenDoc合
成イベントであろうと、XEvent待ち行列に通して送られ
る。OpenDocディスパッチャ・オブジェクトは、OpenDoc
ユーザ・モデルに基づいて分散しなければならない最小
限のイベントだけを拾い出し、他のイベントがXt組み込
み関数ディスパッチャを通って落ちることを許す。これ
が、既存のXlibアプリケーションがOpenDocオブジェク
トに変換されたとき、それらのアプリケーションがすべ
てのイベント扱いコードを保持することを許す。

【００３１】この解決方法を実行する際の難点は、Open
Docディスパッチャによて扱わなければならないイベン
トおよびXt組み込み関数に渡さなければならないイベン
トの最少セットを定義することにある。OpenDocディス
パッチャによって扱うイベントと、組み込み関数ディス
パッチャによって扱うイベントとの分割が正しく行われ
ると、Motif装置をOpenDocパート・ハンドラ・オブジェ
クトに変換することはしごく易しい。イベントの分散が
正しく成されないならば、Motif装置が期待どおりに挙
動しない、すなわち、イベント分散に関してMotifが行
う仮定によって装置が停止するか、あるいは、変換Open
Docオブジェクトどうしが複合ドキュメント環境におい
て互いに協同しない。ここで、本発明の利点をよりよく
理解するために、Apple Computer社によって提供される
MacintoshのOpenDocインプリメンテーションの概要を述
べる。

【００３２】図４のブロック図に示すMacintoshのOpenD
ocシステムの中には、OpenDocプロセスに用いるため
の、通常はＯＳ７オペレーティング・システムを使用す
るMacintosh互換性コンピュータ・システム上に、通常
はＡＩＸで使用される一つのＸウィンドウ・イベント待
ち行列に類似した一つのイベント待ち行列２１０があ
る。すべてのイベントがOpenDocシェル・オブジェクト
２１２を介してOpenDocディスパッチャ２１８に送ら
れ、このディスパッチャが逆にそれらのイベントを適切
なOpenDocパート・ハンドラ２２０に送る。これらは、
ユーザ入力（ＵＩ）イベントとしても知られるマウスの
クリックおよびキーの押下２１４の結果であるか、ある
いは、AppleEventsまたはSemanticEventsもしくはHighL
evelEventsとして様々に知られる部品間メッセージ２１
６の結果である。すべてのイベントは、OpenDocディス
パッチャ・オブジェクトによって処理され、MacＯＳの
システム・ディスパッチャは使用されない。

【００３３】このインプリメンテーションにおいては、
イベント・データは、MacＯＳに固有であるEventRecord
として知られる構造にフォーマットされる。EventRecor
dは、Appleイベント・レコードがXEventデータ構造ほど
多くの情報を含まないことにおいてだけ、Ｘウィンドウ
・システム中でXEvent構造と同じ機能を果たす。AppleE
ventRecordは以下の構造を有している。

【００３４】 struct EventRecord { short what; //イベントのタイプ（mouseDown、KeyDownなど） long message; //タイプ・フィールドのさらなる分類（どのキーか？） long when; //イベントが発生したときクロックが刻時 Point where; //イベントが発生したときのカーソル位置 short modifiers;//修飾キー（Ctrl、Altなど）の状態 };

【００３５】OpenDocシェル２１２は、Macintoshバージ
ョンにしたがって、OpenDocデータ構造を初期化したの
ち、Ｘウィンドウ・アプリケーションに用いるXtMainLo
op()に類似したイベント処理ループ中に載る。このイベ
ント処理ループは、ODDispatcherオブジェクトのメンバ
変数であるfExitフラグが立てられるまで続く。fExitの
値は、ODDispatcher->should exit ()メソッドを呼び出
すことによってアクセスされる。

【００３６】その処理ループの最上レベルが、WaitNext
Event()として知られる関数を使用して次のイベントを
イベント待ち行列２１０から読み出し、そのイベント・
レコード構造を、OpenDocシェル・オブジェクトのDispa
tchEvent()メソッドに渡す。

【００３７】ディスパッチャ２１８のDispatchEvent()
メソッドは、イベントをそのタイプにしたがって範疇分
けし、種々のイベント・タイプ範疇を扱うのに特定のメ
ソッドを呼び出す。MouseDown、KeyDown、Macintosh OS
EventおよびHighLevelEventの各イベントを扱うための
ある特定のメソッドがある。先の４タイプのイベントで
はないイベントを扱うためのデフォルト・メソッドがOD
Dispatcher->dispatch()メソッドである。MouseDown、K
eyDown、OSEventおよびHighLevelEventのイベント・タ
イプを扱うためのすべての特別なイベント扱いメソッド
は、最終的には、基本のODDispatcher->dispatch()メソ
ッドをも呼び出す。

【００３８】MouseDownイベントを扱うためのODDispatc
her２１８のマウスおよびキー・イベント・モジュール
（DispatchMouseDownEvent()）が、どのMacintoshウィ
ンドウの中でそのイベントが発生したかを判定する（Ev
enRecord構造中の「where」フィールドの使用によ
る）。このイベントがメニュー内で起こったならば、Di
spatchMenuEvent()メソッドが呼び出される。そうでな
ければ、HandleMouseDownInWindow()がメソッド呼び出
される。

【００３９】DispatchMenuEvent()メソッドは、UpdateM
enus()メソッドを呼び出して、OpenDocメニューが正し
くセットされたことを確認したのち、ODDispatcher->Di
spatch()メソッドを呼び出して「モニタ」パートにその
イベントのことを知らせ、選択されたメニュー項目がパ
ートのメニューに載っているならば、そのパートにイベ
ントを扱わせる。ODDispatcher->Dispatch()メソッドが
kODFalseの結果を返すならば、これは、メニュー・イベ
ントがどのパート固有メニューにも載っておらず、した
がって、OpenDocシェル２１２がそれを扱わなければな
らないことを示す。シェルのHandleMenuCommand()メソ
ッドが呼び出され、このメソッドが、どのシェル「メニ
ュー・コマンド」が選択されたかを判定し（EventRecor
d中の「メッセージ」フィールドに基づく）、そのコマ
ンドをインプリメントする適切なシェル関数が呼び出さ
れる。

【００４０】類似のコードがKeyDownイベントを扱い、
それが「メニュー」イベントに相当するのか、あるい
は、パート・ハンドラに渡す（ODDispatcher機構を介し
て）べき通常のKeyDownイベントであるのかを判定す
る。

【００４１】HighLevelEventを扱うための特殊なメソッ
ドは、OpenDocのODSessionオブジェクトのGetMessageIn
terface()メソッドを呼び出して、ODMessageInterface
オブジェクトにアクセスする。ODMessageInterfaceオブ
ジェクトのProcessSemanticEvent()メソッドが呼び出さ
れ、同時にHighLevelEventがパラメータとして渡され
る。HighLevelEventのさらなる処理は、MessageInterfa
ceオブジェクトによって実施され、そのOpenDocサブシ
ステムの設計ドキュメントでカバーされている。HighLe
velEvent処理の結果、HighLevelEventタイプに特定的に
登録された目標パート・ハンドラのコールバック・ルー
チンが呼び出される。

【００４２】MacintoshのODDispatcherオブジェクトのD
ispatch()メソッドまたはディスパッチ２１８はまず
「空」イベントがないかチェックし、それらを扱うため
の特殊なメソッドを呼び出す。Ｘウィンドウ・システム
については「空」イベントはなく、したがって、これは
ＡＩＸポートについては不要である。このイベント・タ
イプの「モニタ」パートのリストが検索され、登録され
たモニタごとにDispatch()メソッドが呼び出される。こ
れらのモニタは、イベントを扱いはせず、ただそれを審
査するだけである。最後に、そのイベント・タイプにつ
いてODDispatchモジュール２２２が検索され、そのDisp
atch()メソッドが呼び出される。このメソッドはブール
値を返し、この値が、全ODDispatcher::Dispatch()返し
値として使用される。そのイベント・タイプについてOD
DispatchModuleが登録されていないならば、「handed＝
kODFalse」の返し値が使用される。

【００４３】Macintoshインプリメンテーションにおけ
るODDispatchModuleクラスは、実際には、ODStandardDi
spatchModuleクラスを誘導するのに使用されるベース・
クラスである。このODStandardDispatchModuleクラスは
逆に、ポインタをMacDispatchModuleクラスに対して単
に保持して、このクラスのメソッドが最後に呼び出され
るものになるようにする。

【００４４】MacDispatchModuleクラスは、OpenDocのＵ
Ｉを実際に定義するすべての論理をカプセル化する。Ma
cDispatchModuleは、例えばMouseDownイベントを扱うた
めの基礎をなすＵＩツールキットの規則に依存するので
はなく、その中に、OpenDoc域のどこにカーソルがある
のか、また、それがいかにして現在のアクティブなパー
トおよびマウス「FocusOwner」に関連するのかを判定す
るコードを有している。ＡＩＸポートがXlib、Xt組み込
み関数およびMotifツールキットならびにそれらの既存
のＵＩ挙動規格を利用するならば、このコードの大部分
は不必要である。

【００４５】すべてのMacDispatchModule論理がDispatc
hTheEvent()メソッドに宛てて送られ、このメソッド
が、そのイベントの目標に相当するODFrameおよびODFac
etポインタに渡される。DispatchTheEvent()メソッド
は、ODFrame->GetPart()への呼び出しによってパート・
ハンドラ２２０を検索し、パート・ハンドラのHandleEv
ent()メソッドを呼び出そうと試みて、イベントならび
に与えられたFrameおよびFacetポインタに通過する。パ
ート・ハンドラが、それがイベントを扱わなかったとい
うことを示す値を返すならば、DispatchTheEvent()メソ
ッドは、FrameプロパティDoesPropagateEvent()をチェ
ックし、目標フレームのContainingFrameを使用してそ
のイベントを扱おうと試みる。

【００４６】目標パート・ハンドラのHandleEvent()メ
ソッドが呼び出されると、受け取られたＵＩイベントに
相当するパートについて適切な関数を実行するかどうか
はパート・ハンドラ・コードしだいである。

【００４７】FocusSets（種々のイベント・タイプのも
の）およびFocusOwner（イベントが生成されたときカー
ソルがどこに位置しているかにかかわらず、どのパート
・ハンドラがこのタイプのイベントを受けるか）のOpen
Doc概念は、プラットフォーム非依存的な方法でインプ
リメントされる。これはちょうど、イベント・タイプお
よび、所有権が変更される（通常、別のFrameがアクテ
ィブなFrameになる）までこれらのイベント・タイプを
所有する関連のODFrameオブジェクトのテーブルであ
る。

【００４８】Macintosh上には一つのイベント待ち行列
があり、また、Ｘウィンドウ・システム中にも一つのイ
ベント待ち行列があるため、本発明は、同じ基本的なイ
ベント送達設計を使用する。合併したイベント・ディス
パッチの例を図５のブロック図に示す。すべてのイベン
ト（それらのタイプが何であっても、すなわちＵＩイベ
ントでも意味イベントでも）は、XEventとしてＸウィン
ドウのイベント待ち行列３０２に送られる。OpenDocシ
ェル３０４が、OpenDocデータ構造を初期化したのち、f
Exitフラグが立てられるまで、待ち行列からXEventを受
け取る（XtAppNextEvent()を用いる）。

【００４９】イベント処理ループの最上レベルは次のよ
うなものである。

【００５０】

【００５１】ＡＩＸのOpenDocインプリメンテーション
は、XEvent構造を、MacintoshのEventRecord構造ではな
く、OpenDocディスパッチャ３０６のDispatchEvent()メ
ソッドに渡す。ＡＩＸのDispatchEvent()メソッドは、X
Event構造の「タイプ」フィールドを審査することによ
り、イベント・タイプを決定しなければならない。ＡＩ
ＸのOpenDocライブラリの中で回付されるすべてのODEve
ntはXEventになる。これは、ODEventタイプをXEventに
変更し、ODEventDataをXEventデータ構造として定義す
ることによって達成される。

【００５２】MacintoshのOSEventおよびHighLevelEvent
タイプに相当する自然な同等なXEventは存在しない。し
たがって、ＡＩＸのOpenDocインプリメンテーションに
おいては、それらは、ＸClientMessageタイプ・イベン
トとしてＡＩＸのHighLevelEventハンドラ３０８に送ら
なければならない。実際、MacintoshのOSEventは、アプ
リケーションに対し、いつその「処理状態」が変化した
か（すなわち、ユーザによってアクティブなアプリケー
ションに移されたか）を知らせるためだけに使用され
る。このようなイベント・タイプ支援はＡＩＸインプリ
メンテーションにとって不必要である。

【００５３】HighLevelEventタイプは、意味イベント
（HighLevelEvent）を他のアプリケーションからＯＳＡ
イベント・マネージャ３１０を介して送るためだけに使
用される（OpeDocとは別のデーモン・プロセス）。した
がって、HighLevelEventとしてさらに決定することがで
きるClientMessageタイプ・イベントがＡＩＸインプリ
メンテーションで受けるられるごとに、HandleHighLeve
lEvent()を呼び出すことができる。

【００５４】mouseDownおよびkeyDownイベントをMacint
oshインプリメンテーションで捕らえる目的は、それが
「メニュー」イベントであるのか、あるいはパートにと
っての通常のＵＩ活動でしかないのかを判定することで
ある。ＡＩＸインプリメンテーションにおいては、ODMe
nuBarオブジェクト３１２が、そのイベントがODMenuBar
３１２によって扱われるべきかどうかを判定し、すなわ
ち、それが「メニュー」イベントではないならば、その
イベントは正常にディスパッチされる。これは、ODMenu
Bar３１２についてＡＩＸプラットフォーム固有のメソ
ッドを使用してイベントを審査し、扱う。

【００５５】したがって、ＡＩＸにおけるDispatchEven
t()メソッドの基本構造は次のとおりである。

【００５６】 switch (XEvent.type) { case ButtonPress: case KeyPress: if (! fMenuBar->HandleEvent(XEvent)) this->Dispatch (XEvent); break; case ClientMessage: if (! this->HandleHighLevelEvent(XEvent)) this->Dispatch (XEvent); break; default: this->Dispatch(XEvent); break; }

【００５７】ODMenuBar３１２のHandleEvent()メソッド
は、OpenDocサブシステムの設計ドキュメントに記載さ
れている。

【００５８】ＡＩＸのOpenDocシェル３０４のHandleHig
hLevelEvent()メソッドは、Macintoshインプリメンテー
ションに類似している。これは、MessageInterfaceオブ
ジェクトのメソッドを呼び出して、HighLevelEventの処
理を扱う。ＡＩＸバージョンはまず、このClientMessag
eが、他のClientMessageのXEventではなく、本当にHigh
LevelEvnetであるかどうかを判定したのち、それをOpen
DocのODMessageInterfaceオブジェクトに渡さなければ
ならない。これは、そのイベントに関連するＸアトムを
審査する（ClientMessageイベントを「サブタイプ」す
る手段として）ことによって実施される。イベントがＯ
ＳＡ意味イベントではないならば、個々のパート・ハン
ドラ（特にTaligentパート・ハンドラ）が自らのＸClie
ntMessageイベントのセットを用いるかもしれないた
め、このイベントは扱われないままODDispatcherに返さ
れる。ＡＩＸのMessageInterfaceの設計はMacintoshイ
ンプリメンテーションとは異なるが、それらの差違は、
SemanticInterface、MessageInterfaceおよびNameResol
verサブシステムの設計ドキュメントでカバーされてい
る。

【００５９】ＡＩＸのODDispatcherオブジェクト３１４
は、イベントを二つの方法、すなわち（１）Macintosh
および他のプラットフォームが使用するものと同じOpen
DocのODDispachModule機構を使用する方法、および
（２）デフォルト・イベント送達機構としてのＸウィン
ドウ・イベント・システム・ディスパッチャ３０６（Xt
DispatchEvent()）を介する方法でパート・ハンドラに
送ることができるという意味で、より融通性である。パ
ート・ハンドラ開発者は、最初の方法を用い、受け取る
ことを期待する特定のイベント・タイプについてDispat
chModuleを作成することを奨励されるべきである。多数
のパート・ハンドラが同じイベント・タイプを予期して
いるかもしれないとき、これが、ODDispatcher３１４
が、アービトレーションおよびフォーカス・セットのOp
enDoc概念に基づいて、イベントを特定のパート・ハン
ドラの中央HandleEvent()メソッドに宛てて送ることを
可能にする。

【００６０】しかし、競合、例えばタイマ・イベント
と、正確なパート・ハンドラ宛先（ＸウィンドウＩＤ）
がイベント中にすでに貼り込まれているＸ WorkProcイ
ベントとの競合がないならば、Ｘイベント・ディスパッ
チャ３０６を「最後の手段」として使用することが、イ
ベント・タイプの送達にはより効率的であるかもしれな
い。標準のＸイベント・ディスパッチャはすでに数多く
のイベント・タイプについて正確なコールバック呼び出
しを扱い、パート・ハンドラは、単にそのコールバック
を登録し（典型的なＸウィンドウ・アプリケーションが
現在そうするように）、この特定のパート・ハンドラに
とって特定のイベントが起こるたびにこのルーチンが呼
び出されるということを知ることができる。

【００６１】以下、ODDispatcher３１４のDispatch()メ
ソッドの基本疑似コードを記す。

【００６２】 /* モニタ・リストを取得し、このイベント・タイプに登録されたモニタごとにDispatch()メソッドを呼び出す。*/ monitors = GetMonitors (eventType); for (module=First(); iter.IsNotComplete(); module=Next()) module->Dispatch(event); /* このイベント・タイプのDispatchModuleを取得し（登録されているならば）、そのDispatch()メソッドを呼び出す。このイベント・タイプにDispatchModuleがないならば、XtDispatchEvent() を呼び出し、インストールされたXtコールバックがそれを扱う。 */ handled = kODFalse; if (module = GetDispatchModule(eventType)) { handled = module->Dispatch(event); } if (! handled) { XtDispatchEvent(XEvent); handled = kODTrue; } return handled;

【００６３】ODStandardDispatchModuleクラス３１６の
ＡＩＸバージョンは、Macintoshインプリメンテーショ
ンよりも少ない特殊なメソッドを含んで異なるイベント
・タイプを扱う。具体的には、NULLイベント、OSEvent
およびHighLevelEventタイプを扱うための特殊メソッド
は、ＡＩＸインプリメンテーションでは不必要である
（MacintoshのNULLおよびOSEventsに相当するＸイベン
トはなく、HighLevelEventは、イベント分散サイクル中
のより早い段階で扱われる）。そのうえ、ＵＩイベン
ト、例えばmouseDown、mouseUp、keyDouwn、keyUpを扱
う特殊メソッドは、MacintoshのToolboxのＵＩ（すなわ
ち、GoAwayボックス、Growボックス、ZoomInおよびZoom
Outボックス）を扱うコードを含まない。Ｘウィンドウ
・システムにおける同等なウィンドウ・マネージャ・タ
イプの操作は、OpenDocシェル３０４により、そのシェ
ルがＸウィンドウ・マネージャに登録する方法を用いて
（XmAddWMProtocolCallback()ＡＰＩを用いる）捕らえ
られるＸウインドウ・システム・メッセージをもたら
す。メニュー・イベントはすでにキャッチされ、ＡＩＸ
設計のODMenuBarオブジェクトによって扱われている。

【００６４】したがって、ＡＩＸインプリメンテーショ
ンにおいては、OSStandardDispatchModule３１６は、Bu
ttonPressおよびKeyPressイベントのみをパート・ハン
ドラ３１８のHandleEvent()メソッドに送る。ButtonPre
ssイベントは、ＸウィンドウＩＤをODEventDataの一部
として含み、これが、そのイベントが属するパート・ハ
ンドラを識別する。KeyPressイベントは、どのハンドラ
がKeyFocusTokenの現在のイベント・アービトレータ・
フォーカスを有しているかに基づいて、適切なパート・
ハンドラに送られる。

【００６５】基本的なODStandardDispatchModuleのDisp
atch()メソッドの疑似コードは次のとおりである。

【００６６】 switch (XEvent.type) { case ButtonPress: return this->DispatchButtonPressEvent (XEvent); break; case ButtoRelease: return this->DispatchButtonReleaseEvent (XEvent); break; case KeyPress: return this->DispatchKeyPressEvent (XEvent); break; case KeyRelease: return this->DispatchKeyReleaseEvent (XEvent); break; default: return kODFalse; break; }

【００６７】図６は、ＡＩＸのOpenDocディスパッチャ
３１４を通過する典型的なイベントの流れを示すブロッ
ク図である。ブロック６１０で、図５のOpenDocディス
パッチ論理へのイベントが受けられる。まずブロック６
１２で、シェル３０４が、ボタンの押下またはキーの押
下が起こったかどうかを判定する。起こったならば、シ
ステムはブロック６１４に進み、それがメニュー・イベ
ントであるかどうかを判定したのち、ブロック６１６に
進み、そこでメニュー・バー３１２がそのイベントを扱
う。ボタンの押下またはキーの押下が起こっていない
か、メニュー・イベントが決定されていないならば、シ
ステムはブロック６１８に進む。ブロック６１８で、シ
ステムは、Xclientメッセージを受けたかどうかを判定
し、受けたならば、ブロック６２０に進む。ブロック６
２０で、システムは、Xclientメッセージ・イベントが
意味イベントであるかどうかを判定し、意味イベントで
あるならば、ブロック６２２に進む。ブロック６２２
で、システムは、そのイベントを扱うためにそれを意味
インタフェースに送る。あるいは、イベントがXclient
メッセージ・イベントでも意味イベントでもないなら
ば、システムはブロック６２８に進む。ブロック６２８
で、システムは、イベント・タイプのモニタが必要かど
うかを判定し、必要ならば、ブロック６３０に進み、そ
こで、システムはモニタにイベントを監視させる。その
後、あるいはモニタが不要の場合、システムはブロック
６３２に進み、そこでシステムは、イベント・タイプの
ディスパッチ・モジュールが必要であるかどうかを判定
する。必要ならば、システムは、ブロック６３４に進
み、そこで、システム・ディスパッチがディスパッチ・
モジュールを使用して、どのパートかを見いだし、イン
プリメントされるならばPart::HandleEvent()メソッド
を呼び出す。その後、あるいはディスパッチ・モジュー
ルが不要の場合、システムは、ブロック６３６で、イベ
ントをさらなる処理に備えてディスパッチするためにXt
ディスパッチ・イベント・メソッドに進む。

【００６８】上述したように、本発明の態様は、コンピ
ュータ・システム上で具現化しうる特定の「メソッド・
ステップ」に関する。代替態様においては、本発明は、
コンピュータ・システムとで使用するためのコンピュー
タ・プログラム製品として具現化することもできる。当
業者であれば、本発明の関数を定義するプログラムを、
以下を含む多様な形態、すなわち（ａ）非書き込み可能
な記憶媒体（例えばコンピュータ内の読み出し専用メモ
リ装置、例えばＲＯＭ８６もしくはＣＤ−ＲＯＭドライ
ブ２４によって読み出し可能な光ディスク）に永久的に
記憶された情報の形態、（ｂ）書き込み可能な記憶媒体
（例えばディスケット・ドライブ２２内のフロッピー・
ディスクもしくはハードディスク・ドライブ２４）に更
新可能に記憶された情報の形態、または（ｃ）通信媒
体、例えばコンピュータもしくは電話ネットワークを介
してコンピュータに運ばれる情報の形態（これらに限定
はされない）でコンピュータに送達できるということを
容易に察知するはずである。したがって、そのような媒
体が、本発明のメソッド関数に指図するコンピュータ読
み出し可能な指示を運ぶとき、それが本発明の代替態様
を表すということを理解すべきである。

【００６９】まとめとして、本発明の構成に関して以下
の事項を開示する。（１）多数のアクティブなグラフィカル・ユーザ・イン
ターフェース・ソフトウェア・システムを支援するコン
ピュータ・システムにおいて、バスと、中央処理装置
と、前記バスを介して前記中央処理装置に結合されたコ
ンピュータ・システム・メモリと、ユーザ入力イベント
を、入力イベントのタイプおよびその予定の宛先に基づ
いて、適切なソフトウェア・システムに宛てて送る、前
記コンピュータ・システム・メモリ中に位置する共用ソ
フトウェア・システム・イベント・ディスパッチャと、
を含むことを特徴とするコンピュータ・システム。（２）前記共用ソフトウェア・システム・イベント・デ
ィスパッチャによって処理するためのユーザ入力イベン
トを受ける、前記共用ソフトウェア・システム・イベン
ト・ディスパッチャに結合されたイベント待ち行列をさ
らに含む上記（１）記載のコンピュータ・システム。（３）前記ユーザ入力イベントをメニュー・イベントま
たは意味イベントのいずれかとして識別する、前記イベ
ント待ち行列および前記イベント・ディスパッチャに結
合された共用ソフトウェア・システム・シェルをさらに
含む上記（１）記載のコンピュータ・システム。（４）前記イベントに関連する適切なパート・ハンドラ
によって操作するための、前記イベント・ディスパッチ
ャによって受けられ、分散された、選択されたイベント
・タイプを扱う、前記イベント・ディスパッチャに接続
されたディスパッチ・モジュールをさらに含む上記
（１）記載のコンピュータ・システム。（５）前記ソフトウェア・システムの一つがOpenDocソ
フトウェア・システムである上記（１）記載のコンピュ
ータ・システム。（６）前記OpenDocソフトウェア・システムが前記イベ
ントのタイプおよび宛先によって識別される上記（５）
記載のコンピュータ・システム。（７）前記所与のパート・ハンドラが、定義されたアー
ビトレーションおよびフォーカス・セットに基づいて選
択される上記（６）記載のコンピュータ・システム。（８）前記ソフトウェア・システムの一つがＸウィンド
ウ・ソフトウェア・システムである上記（１）記載のコ
ンピュータ・システム。（９）前記Ｘウィンドウ・ソフトウェア・システムが前
記イベントの前記宛先およびタイプによって識別される
上記（８）記載のコンピュータ・システム。（１０）同じコンピュータ・システム上で動作すること
ができる多数のアクティブなグラフィカル・ユーザ・イ
ンターフェース・ソフトウェア・システムを支援するた
めのコンピュータ・プログラム製品において、ユーザ入
力イベントを、入力イベントのタイプおよびその予定の
宛先に基づいて、適切なソフトウェア・システムに宛て
て送る、前記ソフトウェア・システムの間でソフトウェ
ア・システム・イベントをディスパッチするためのコン
ピュータ使用可能コード手段と、前記ソフトウェア・シ
ステムによって共用される前記ソフトウェア・システム
・イベント・ディスパッチ手段によって処理するための
ユーザ入力イベントを行列させるためのコンピュータ使
用可能コード手段と、を含むことを特徴とするコンピュ
ータ・プログラム製品。（１１）前記ユーザ入力イベントをメニュー・イベント
または意味イベントのいずれかとして識別するためのコ
ンピュータ使用可能コード手段をさらに含む上記（１
０）記載のコンピュータ・プログラム製品。（１２）前記イベントに関連する適切なパート・ハンド
ラによって操作するための、前記ディスパッチ手段によ
って受けられ、分散された、選択されたイベント・タイ
プを扱うためのコンピュータ使用可能コード手段をさら
に含む上記（１０）記載のコンピュータ・プログラム製
品。（１３）前記ソフトウェア・システムの一つがOpenDoc
ソフトウェア・システムである上記（１０）記載のコン
ピュータ・プログラム製品。（１４）前記OpenDocソフトウェア・システムが前記イ
ベントのタイプおよび宛先によって識別される上記（１
３）記載のコンピュータ・プログラム製品。（１５）前記所与のパート・ハンドラが、定義されたア
ービトレーションおよびフォーカス・セットに基づいて
選択される上記（１４）記載のコンピュータ・プログラ
ム製品。（１６）前記ソフトウェア・システムの一つがＸウィン
ドウ・ソフトウェア・システムである上記（１０）記載
のコンピュータ・プログラム製品。（１７）前記Ｘウィンドウ・ソフトウェア・システムが
前記イベントの前記宛先およびタイプによって識別され
る上記（１６）記載のコンピュータ・プログラム製品。（１８）多数のアクティブなグラフィカル・ユーザ・イ
ンターフェース・ソフトウェア・システムを動作させる
コンピュータ・システムにおける、前記多数のソフトウ
ェア・システムに対してイベント分散を提供する方法に
おいて、ユーザ入力イベントを受けるステップと、前記
ユーザ入力イベントがメニュー・アクセス・イベントで
あるかどうかを判定するステップと、前記ユーザ入力イ
ベントがメニュー・アクセス・イベントであるならば、
前記コンピュータ・システム内のメニュー・バー・イベ
ント・ハンドラによって前記メニュー・アクセス・イベ
ントを処理するステップと、前記ユーザ入力イベントが
メニュー・アクセス・イベントではないならば、前記ユ
ーザ入力イベントが正規のイベントであるかどうかを判
定するステップと、前記ユーザ入力イベントが正規のイ
ベントであるならば、前記イベントが意味イベントであ
るかどうかを判定し、意味イベントであるならば、前記
イベントを意味インタフェース・イベント・ハンドラに
送るステップと、前記イベントが意味イベントではない
ならば、前記イベントのタイプを決定するステップと、
前記イベントのソフトウェア・システム宛先を決定する
ステップと、前記イベントを前記ソフトウェア・システ
ム宛先にディスパッチするステップと、を含むことを特
徴とする方法。

【図面の簡単な説明】

【図１】本発明の方法を具現化するために用いることが
できるデータ処理システムの好ましい実施態様を示す図
である。

【図２】データ処理システムのシステム装置の主要構成
部分を示すブロック図である。

【図３】起動直後のデータ処理システムのソフトウェア
構成を示す図である。

【図４】Macintosh互換性コンピュータ・システムにお
ける一つのイベント待ち行列を示すブロック図である。

【図５】本発明にしたがって合併されるイベント・ディ
スパッチャを示すブロック図である。

【図６】本発明によるＡＩＸのOpenDocディスパッチャ
を通過する典型的なイベントの流れを示すブロック図で
ある。

【符号の説明】

３０２Ｘイベント待ち行列３０４ＡＩＸ OpenDocシェル３０６Ｘイベント・ディスパッチャ３０８ＡＩＸ HighLevelEventハンドラ３１００ＳＡイベント・マネージャ３１２ＡＩＸ ODMenuBar ３１４ＡＩＸ ODdispatcher ３１６ＡＩＸ OSStandardDispatchModule ３１８ＡＩＸ OpenDocパート・ハンドラ

───────────────────────────────────────────────────── フロントページの続き (72)発明者クリストファー・ジョン・ネルソンアメリカ合衆国78752、テキサス州オースティンミィランダ・ドライブ 6803 (72)発明者ランス・ジェフリー・パープルアメリカ合衆国78751、テキサス州オースティンデュバル・ストリート 4800 (72)発明者レイ・アレン・ウィリアムソンアメリカ合衆国78727、テキサス州オースティンエヴァーレストレーン 4615 (72)発明者チン・ユン・ヤンアメリカ合衆国カリフォルニア州サラトガプエンテコート 20000

Claims

【特許請求の範囲】

【請求項１】多数のアクティブなグラフィカル・ユーザ
・インターフェース・ソフトウェア・システムを支援す
るコンピュータ・システムにおいて、バスと、中央処理装置と、前記バスを介して前記中央処理装置に結合されたコンピ
ュータ・システム・メモリと、ユーザ入力イベントを、入力イベントのタイプおよびそ
の予定の宛先に基づいて、適切なソフトウェア・システ
ムに宛てて送る、前記コンピュータ・システム・メモリ
中に位置する共用ソフトウェア・システム・イベント・
ディスパッチャと、を含むことを特徴とするコンピュー
タ・システム。
【請求項２】前記共用ソフトウェア・システム・イベン
ト・ディスパッチャによって処理するためのユーザ入力
イベントを受ける、前記共用ソフトウェア・システム・
イベント・ディスパッチャに結合されたイベント待ち行
列をさらに含む請求項１記載のコンピュータ・システ
ム。
【請求項３】前記ユーザ入力イベントをメニュー・イベ
ントまたは意味イベントのいずれかとして識別する、前
記イベント待ち行列および前記イベント・ディスパッチ
ャに結合された共用ソフトウェア・システム・シェルを
さらに含む請求項１記載のコンピュータ・システム。
【請求項４】前記イベントに関連する適切なパート・ハ
ンドラによって操作するための、前記イベント・ディス
パッチャによって受けられ、分散された、選択されたイ
ベント・タイプを扱う、前記イベント・ディスパッチャ
に接続されたディスパッチ・モジュールをさらに含む請
求項１記載のコンピュータ・システム。
【請求項５】前記ソフトウェア・システムの一つがOpen
Docソフトウェア・システムである請求項１記載のコン
ピュータ・システム。
【請求項６】前記OpenDocソフトウェア・システムが前
記イベントのタイプおよび宛先によって識別される請求
項５記載のコンピュータ・システム。
【請求項７】前記所与のパート・ハンドラが、定義され
たアービトレーションおよびフォーカス・セットに基づ
いて選択される請求項６記載のコンピュータ・システ
ム。
【請求項８】前記ソフトウェア・システムの一つがＸウ
ィンドウ・ソフトウェア・システムである請求項１記載
のコンピュータ・システム。
【請求項９】前記Ｘウィンドウ・ソフトウェア・システ
ムが前記イベントの前記宛先およびタイプによって識別
される請求項８記載のコンピュータ・システム。
【請求項１０】同じコンピュータ・システム上で動作す
ることができる多数のアクティブなグラフィカル・ユー
ザ・インターフェース・ソフトウェア・システムを支援
するためのコンピュータ・プログラム製品において、ユーザ入力イベントを、入力イベントのタイプおよびそ
の予定の宛先に基づいて、適切なソフトウェア・システ
ムに宛てて送る、前記ソフトウェア・システムの間でソ
フトウェア・システム・イベントをディスパッチするた
めのコンピュータ使用可能コード手段と、前記ソフトウェア・システムによって共用される前記ソ
フトウェア・システム・イベント・ディスパッチ手段に
よって処理するためのユーザ入力イベントを行列させる
ためのコンピュータ使用可能コード手段と、を含むこと
を特徴とするコンピュータ・プログラム製品。
【請求項１１】前記ユーザ入力イベントをメニュー・イ
ベントまたは意味イベントのいずれかとして識別するた
めのコンピュータ使用可能コード手段をさらに含む請求
項１０記載のコンピュータ・プログラム製品。
【請求項１２】前記イベントに関連する適切なパート・
ハンドラによって操作するための、前記ディスパッチ手
段によって受けられ、分散された、選択されたイベント
・タイプを扱うためのコンピュータ使用可能コード手段
をさらに含む請求項１０記載のコンピュータ・プログラ
ム製品。
【請求項１３】前記ソフトウェア・システムの一つがOp
enDocソフトウェア・システムである請求項１０記載の
コンピュータ・プログラム製品。
【請求項１４】前記OpenDocソフトウェア・システムが
前記イベントのタイプおよび宛先によって識別される請
求項１３記載のコンピュータ・プログラム製品。
【請求項１５】前記所与のパート・ハンドラが、定義さ
れたアービトレーションおよびフォーカス・セットに基
づいて選択される請求項１４記載のコンピュータ・プロ
グラム製品。
【請求項１６】前記ソフトウェア・システムの一つがＸ
ウィンドウ・ソフトウェア・システムである請求項１０
記載のコンピュータ・プログラム製品。
【請求項１７】前記Ｘウィンドウ・ソフトウェア・シス
テムが前記イベントの前記宛先およびタイプによって識
別される請求項１６記載のコンピュータ・プログラム製
品。
【請求項１８】多数のアクティブなグラフィカル・ユー
ザ・インターフェース・ソフトウェア・システムを動作
させるコンピュータ・システムにおける、前記多数のソ
フトウェア・システムに対してイベント分散を提供する
方法において、ユーザ入力イベントを受けるステップと、前記ユーザ入力イベントがメニュー・アクセス・イベン
トであるかどうかを判定するステップと、前記ユーザ入力イベントがメニュー・アクセス・イベン
トであるならば、前記コンピュータ・システム内のメニ
ュー・バー・イベント・ハンドラによって前記メニュー
・アクセス・イベントを処理するステップと、前記ユーザ入力イベントがメニュー・アクセス・イベン
トではないならば、前記ユーザ入力イベントが正規のイ
ベントであるかどうかを判定するステップと、前記ユーザ入力イベントが正規のイベントであるなら
ば、前記イベントが意味イベントであるかどうかを判定
し、意味イベントであるならば、前記イベントを意味イ
ンタフェース・イベント・ハンドラに送るステップと、前記イベントが意味イベントではないならば、前記イベ
ントのタイプを決定するステップと、前記イベントのソフトウェア・システム宛先を決定する
ステップと、前記イベントを前記ソフトウェア・システム宛先にディ
スパッチするステップと、を含むことを特徴とする方
法。