JPH09504897A - オブジェクト指向カーソル・ツール - Google Patents

Abstract

(57)【要約】 本発明のシステムおよび方法はいかなるシステム上の複数のカーソルに対するサポートを有するカーソル・ツール・フレームワークおよびツール・サーバを提供し、カーソルを用いるカーソル・ツールの選択をサポートするものである。フレームワークおよびサーバは、プロセスとは独立した空間内のカーソルに対するカーソル・ツールの関係を容易にして、ツールがプロセスを越えておよびドキュメントを越えて用いられ得るようにする。フレームワークは、用いられるカーソル・ツールおよびキャンバス間の通信およびネゴシエーションのためのディフォルトの機能をも提供する。このネゴシエーションによって、いかなるカーソル・ツールおよびいかなるドキュメントも共に機能して、ドキュメント開発者の知識なしにカーソル・ツールが書き込まれるようにすることができる。フレームワークは、カーソル・ツールがプロセスおよびドキュメントを越えて効率よく分配されるためのインプリメンテーションを提供するので、ツールがドキュメント・データを変更する権利についてドキュメントと首尾よくネゴシエートし終えるような時間までドキュメントがツールを意識する必要がない。

Description

【発明の詳細な説明】 オブジェクト指向カーソル・ツール 著作権表記 本明細書の一部には、著作権保護の対象となる内容が含まれている。著作権所 有者は、米国特許商標庁の特許ファイルまたは記録に記述されている特許文書ま たは特許開示事項を誰かがそのまま複製することに異論を唱えないが、その他の 場合には著作権に係わる一切の権利を留保する。 発明の分野 本発明は、一般的にはコンピュータ・システムにおける改良に関し、特にオブ ジェクト指向オペレーティング・システムにおけるツール・オブジェクトおよび ツール・オブジェクトのメニューを用いるシステムおよび方法に関する。 発明の背景 カーソル・ツールは、ユーザ制御される「カーソル」のふるまいを変えること でユーザのドキュメントまたはフレームとの相互作用の特定のモードを特定する 。例えば、ユーザは「レクタングル（矩形）」カーソル・ツールを選択して、マ ウスボタンを押しながらマウスをドラッグすることで、ドキュメント・ドローイ ング（描画）キャンバス上にレクタングルを生成することをオペレーティング環 境に指示することができる。ツールはデータの選択、操作および生成用のモード を指示することができる。カーソル・ツールの従来技術例はMacPaint（登録商標 ）またはMacDraw（登録商標）のようなアプリケーションにおいて見受けられる 。しかし、これらのアプリケーションは一度に２つ以上のカーソルの管理をユー ザに提供しなかった。さらに、オペレーティング・システムへの統合を行っ て、１つのアプリケーションにおいてアクティブなツールを他のアプリケーショ ンでも機能させることができるようにすることはなされていなかった。カーソル ・ツールとアプリケーションとの間のネゴシエーションの能力も従来技術では知 られてはいなかった。 発明の概要 本発明の革新的システムおよび方法ではオブジェクト指向技術を用いて、複数 のカーソル・ツールを一つのオブジェクト指向オペレーティング・システムに統 合する。この統合は複数のタスクでの複数のカーソル・ツールを同時に管理する ことを含んでいる。ネゴシエーション能力を設けて、任意のカーソル・ツールと 任意のアプリケーションとを共に機能させることができるようにする。この独自 の能力は区画を越えてのメモリ管理を含み、それによりアプリケーションおよび 区分を越えてカーソル・ツールを使用することを可能にしている。オブジェクト 指向のフレームワークによりカーソル・ツールをアプリケーションを越えて分配 するためのアーキテクチャを提供するので、そのためカーソル・ツール機能が必 要になるまではアプリケーション要求はツールについて知らない。技術用語では 、これは、カーソル・ツールがアプリケーションの情報をうまく変更できること が決定された後までは、どんなアプリケーションでもカーソル・ツールの共有ラ イブラリにおいてマッピングすることなしにカーソル・ツールを使用することが できることを意味する。 図面の簡単な説明 図１は、好適実施例によるパーソナル・コンピュータ・システムを示すブロッ ク図である。 図２は、MacDrawで使用される従来技術のカーソル・ツール・クラスタの例を 示す図である。 図３は、好適実施例によるコマンド・パネルを示す図である。 図４は、好適実施例によるコマンド・パネル・バーの例を示す図である。 図５は、好適実施例によるコマンド・パネルの例を示す図である。 図６は、好適実施例によるツール・クラスタの例を示す図である。 図７は、好適実施例による各種の形態のフレームの幾つかの例を示す図である 。 図８は、好適実施例による各種のフレームをもつデスクトップを示す図である 。 図９は、好適実施例によるレクタングル（矩形）カーソル・ツール、クリエー タのユーザ選択を示す図である。 図１０は、好適実施例による選択矢印（アロー）を示す図である。 図１１は、好適実施例によりアクティブなツールになるカーソル・レクタング ル・ツールを示す図である。 図１２は、好適実施例により、非アクティブなドキュメントを通り越して、ア クティブなツールになる選択矢印を示す図である。 図１３は、好適実施例によるスマッジなツール(smudge tool)、セレクタ(sele ctor)／エフェクタ(effector)用の選択プロセスを示す図である。 図１４は、好適実施例により、カーソルが特定のフレームを通り越すときのみ だけスマッジ・ツールを動作可能（イネーブル）にすることを示す図である。 図１５および図１６は、好適実施例により、ツール・カーソルが内容領域を通 り過ぎる際のツール・カーソルの動作を示す図である。 図１７は、好適実施例によるウィンドウおよびフレーム処理をまとめて示す図 である。 図１８は、好適実施例によるツール処理の論理を示す流れ図である。 図１９は、好適実施例によるクラス階層(hierarchy)を示す図である。 図２０は、好適実施例によるTToolServerクラスを示す図である。 図２１は、好適実施例によるコマンド・クラスを示す図である。 図２２は、好適実施例による予め組み込まれたジオメトリー（幾何学的配置） の幾つかを示す図である。 図２３は、好適実施例によるユーティリティ・クラスを示す図である。 発明の詳細な説明 本発明はＩＢＭ（登録商標）社のＰＳ／２（登録商標）またはアップル（登録 商標）社のマッキントッシュ（登録商標）コンピュータのようなパーソナル・コ ンピュータに常駐するオペレーティング・システムの下で実行されるのが好まし い。代表的なハードウェア環境は図１に示され、図１は、組み込みの不揮発性記 憶装置１１を有する慣例のマイクロプロセッサのような中央処理装置１０および システム・バス１２を介して相互接続された多数の他のユニットを有する本発明 によるコンピュータの代表的なハードウェア構成を示す。図１に示されるワーク ステーションは、ランダム・アクセス・メモリ（ＲＡＭ）１４、リード・オンリ ・メモリ（ＲＯＭ）１６、ディスク・ユニット２０およびディスケット・ユニッ ト２１のような周辺装置をバスに接続する入出力アダプタ１８、キーボード２４ 、マウス２６、スピーカ２８、マイクロホン３２、および／またはタッチ・スク リーン装置（図示せず）などのような他のユーザ・インタフェース装置をバスに 接続するユーザ・インタフェース・アダプタ２２、このワークステーションをデ ータ処理ネットワーク２３に接続する通信アダプタ３４、およびバスをディスプ レイ装置３８に接続するディスプレイ・アダプタ３６を含んでいる。このコンピ ュータには、Apple System/7（登録商標）オペレーティング・システムのような オペレーティング・システムを搭載してある。 オブジェクト指向プログラミング技術 好適実施例では、本発明はオブジェクト指向プログラミング技術を用いてＣ++ プログラミング言語で実現されている。当業者によって理解されるように、オブ ジェクト指向プログラミング（ＯＯＰ）のオブジェクトは、データ構造およびデ ータに対するオペレーションを含むソフトウェア・エンティティである。これら のエレメントが一緒になって、オブジェクトが、そのデータ・エレメントで表現 されたその特性、およびそのデータ操作関数で表現されたそのふるまいないし作 用(Behavior)の形態でいかなる実世界のエンティティをも仮想的にモデル化す ることができる。このようにして、オブジェクトは、人々やコンピュータのよう な具体物をモデル化することができ、かつ、数や幾何学的概念のような抽象的概 念をモデル化することができる。オブジェクト技術の利点は次の３つの基本的原 理から得られるものである。それは、カプセル化(encapsulation)、多態(polymo rphism)、および継承(inheritance)である。 オブジェクトは、それらのデータの内部構造とそれらの関数が働くときのアル ゴリズムを隠蔽、すなわちカプセル化する。これらのインプリメンテーションの 細部を見せる代わりに、オブジェクトは、外部情報なしにそれらの抽象化をクリ ーンに表現するインタフェースを提供する。多態はカプセル化をさらに一歩進め たものである。この考え方は、多数の形態で、１つのインタフェースということ である。あるソフトウェア・コンポーネントは、別のコンポーネントがなんであ るかを正確に知ることなしに、その別のコンポーネントを要求することができる 。その要求を受け取ったコンポーネントはその要求を解釈し、その要求をどのよ うに実行すべきかを、その変数とデータに従って決定する。３番目の原理は継承 であり、それにより開発者は、既存の設計やコードを再利用することができる。 この能力を利用することにより、開発者はソフトウェアを初めから作ることを回 避できる。むしろ、継承を通して、開発者はそのふるまいを継承するサブクラス を導出し、そして開発者はその挙動を特定の要求に合ったものにカストマイズす る。 従来技術の手法では、オブジェクトとクラス・ライブラリを手続き型環境にお いて階層化する。市販されている多くのアプリケーション・フレームワークはこ の設計手法を採用している。この設計では、モノリシック・オペレーティング・ システムの上に１つまたは２つ以上のオブジェクト層が置かれている。この手法 では、カプセル化、多態および継承のすべての原理をオブジェクト層において用 い、そして手続き的なプログラミング技法を大幅に改善しているが、この手法に は幾つかの制約がある。これらの困難さは、開発者が、自分自身のオブジェクト を再利用することは容易であるが、他のシステムからのオブジェクトを使用する ことが困難であり、かつ開発者が、手続き型オペレーティング・システム（ＯＳ ）のコールを使用して内部の非オブジェクト層内にまで到達する必要があ ることに起因している。 オブジェクト指向プログラミングがもつもう一つの側面は、アプリケーション を開発するのにフレームワークの手法を採用していることである。フレームワー クの最も合理的な定義の１つとして、イリノイ大学のRalph E．JohnsonとPurdue 大学のVincent F．Russoによるものがある。両氏の１９９１年の論文「オブジェ クト指向設計の再利用」(Reusing Object-Oriented Designs)、イリノイ大学技 術報告書ＵＩＵＣＤＣＳ ９１−１６９６の中で、次のような定義を提案してい る。「抽象クラスは、１組の責任を協力し合って実行する１組のオブジェクトの 設計である。従って、フレームワークは、定義された組の計算責任を協力し合っ て実行する１組のオブジェクト・クラスである。」プログラミングの観点からは 、フレームワークは、本質的には、作業アプリケーションのあらかじめ作られた 構造を提供する、相互に接続されたオブジェクト・クラスの群である。例えば、 ユーザ・インタフェース・フレームワークは、描画ウィンドウ、スクロール・バ ー、メニューなどのサポート、および「デフォルト（省略時）」のふるまいを提 供することができる。フレームワークはオブジェクト技術を基礎にしているので 、このふるまいを継承してオーバライドすることにより、開発者はフレームワー クを拡張し、およびカストマイズしたソルーションを特定の専門分野で作ること ができる。これが慣例のプログラミングに比べて大きな利点であるのは、プログ ラマはオリジナル・コードを変更するのではなく、むしろソフトウェアを拡張す るからである。さらに、フレームワークは、アーキテクチャに関するガイダンス とモデリングを提供するが、それと同時に、それらを解放して、次いで問題領域 に特有の特定のアクションを供給するので、開発者は幾つかのコード層を通って 盲目的に作業する必要がない。 ビジネス的見地からは、フレームワークは、特定の知識分野において専門知識 をカプセル化または具現化する手段と見ることができる。企業の開発組織、独立 ソフトウェア・ベンダ(Independent Software Vendors - ISV)およびシステム・ インテグレータは、製造、会計、または通貨取引きのような特定分野における専 門知識をもっている。この専門知識はそれぞれのコードで具現化されている。フ レームワークによって、企業は、その専門知識を企業のコードで具現化すること により、専門知識の共通の特性を捕捉して、パッケージ化することができる。ま ず、そのようにすると、開発者は専門知識を利用するアプリケーションを作成ま たは拡張できるので、問題がいったん解決されれば、ビジネス・ルールおよび設 計は絶えず実施され、使用されることになる。さらにまた、フレームワークと、 フレームワークの背景にある具現化された専門知識は、製造、会計、またはバイ オテクノロジィのような垂直的マーケットにおいて専門知識を得たこれら組織に とっては、戦略的資産の意味あいをもち、それらの専門知識をパッケージ化し、 再販し、配備し、技術の進歩と普及化を促進するための分配メカニズムをもつ。 歴史的には、フレームワークはコンピューティング・プラットフォーム上の主 流の概念として出現したのは、つい最近のことである。この移行は、Ｃ++のよう なオブジェクト指向言語を利用できるようになったことによって助長されてきた 。伝統的には、Ｃ++は、大抵、商用の場におけるコンピュータよりむしろ、ＵＮ ＩＸシステムと研究者のワークステーション上に搭載されていた。多数の大学お よび研究プロジェクトが、今日の商用フレームワークおよびクラス・ライブラリ の先駆けとなりえたのは、Ｃ++などの言語やSmalltalkなどの他のオブジェクト 指向言語のお陰である。それらの幾つかの例を挙げると、スタンフォード大学の InterViews、カーネギ・メロン大学のAndrewツールキット、チューリッヒ大学の ＥＴ++フレームワークがある。 システムのレベルと問題の性質とに応じて、多種類のフレームワークがある。 フレームワークの種類はユーザ・インタフェースの開発を支援するアプリケーシ ョン・フレームワークから、通信、印刷、ファイル・システム・サポート、グラ フィックなどの基本的システム・ソフトウェアのサービスを提供する低レベルの フレームワークまでにわたっている。商用化されているアプリケーション・フレ ームワークの例を挙げると、MacApp(Apple)、Bedrock(Symantec)、OWL(Borland) 、NeXTStep App Kit(NeXT)、およびSmalltalk-80 MVC(ParcPlace)ある。 フレームワークでプログラミングを行うには、他の種類のシステムに慣れてい る開発者にとっては新しい考え方を必要とする。確かに、このプログラミング は、従来の意味での「プログラミング」とはまったく異なっている。ＤＯＳやＵ ＮＩＸなどの旧スタイルのオペレーティング・システムでは、開発者自身のプロ グラムが構造の全体を提供する。オペレーティング・システムはシステム・コー ルを通してサービスを提供している。つまり、開発者のプログラムはサービスの 必要時にコールを行い、サービスが提供されたとき制御が返却される。プログラ ム構造は制御の流れに基づいており、これは開発者が書くコードに具現化される 。 フレームワークが使用されるときは、これとは反対である。開発者は制御の流 れに責任をもつ必要がなくなる。開発者は、プログラミング・タスクを実行の流 れからとらえて理解しようとする傾向をやめなければならない。それよりも、オ ブジェクトの貴任から思考する必要があり、このことはフレームワークに依存し て、タスクがいつ実行するかを決めることになる。開発者が書いたルーチンは、 開発者が書かなかった、従って開発者が見たこともないコードによって活性化さ れる。制御の流れにおけるこのフリップ・フロップは、手続き型プログラミング だけに経験のある開発者にとっては、大きな心理的障壁となっている。しかし、 このことをいったん理解してしまえば、フレームワーク・プログラミングは、他 の種類のプログラミングよりも作業量がより少なくてすむ。 アプリケーション・フレームワークが開発者にプレハブの機能を提供するのと 同じように、本発明の好適実施例に含まれるようなシステム・フレームワークは 、システム・レベルのサービスを提供することによって同じ概念をてこにし、シ ステム・プログラマのような開発者は、システム・レベルのサービスを用いてサ ブクラス化またはオーバライドして、カストマイズしたソリューションを生成す ることができる。例えば、オーディオ、ビデオ、ＭＩＤＩ、アニメーションなど のような新規かつ種々のデバイスをサポートする基礎を提供できるマルチメディ ア・フレームワークについて考えてみることにする。新しい種類のデバイスをサ ポートする必要がある開発者はデバイス・ドライバを書く必要があろう。フレー ムワークでこれを行うためには、開発者は、その新デバイスに特有の特性とふる まいを供給することのみが必要である。 この場合の開発者は、マルチメディア・フレームワークによって呼び出される ある種のメンバ関数に対するインプリメンテーションを供給することになる。開 発者にとって直接に利点となることは、各カテゴリのデバイスに必要になる汎用 コードがマルチメディア・フレームワークによってすでに用意されていることで ある。このことは、デバイス・ドライバ開発者が書き、テストし、デバッグする コードが少なくなることを意味する。システム・フレームワークを使用するもう １つの例は、ＳＣＳＩデバイス、ＮｕＢｕｓカード、およびグラフィックデバイ スに対する入出力フレームワークを実行することである。継承された機能がある ので、各フレームワークは、そのデバイス・カテゴリに見られる共通の機能に対 するサポートを提供する。他の開発者は、種々の他のデバイスに対してもこれら の首尾一貫したインタフェースに依存する。 好適実施例では、フレームワークの概念を取り入れ、この概念をシステム全体 に適用している。商用または企業の開発者、システム・インテグレータ、または ＯＥＭにとっては、このことは、MacAppのようなフレームワークに対して例示さ れてきたすべての利点が、テキストおよびユーザ・インタフェースのようなもの に対するアプリケーション・レベルのみだけでなく、グラフィックス、マルチメ ディア、ファイル・システム、入出力、テスティングなどのようなサービスに対 するシステム・レベルでも生かせることを意味する。 好適実施例のアーキテクチャでのアプリケーション生成は、本質的には、フレ ーム・ワークプロトコルに準拠するドメイン特有のジグソーパズルのピースを書 くのと似ている。このようにして、プログラミングという概念全体が変わる。複 数のＡＰＩ階層をコールするコードを一行ずつ書くのではなく、ソフトウェアは 、この環境内の既存のフレームワークからクラスを取り出し、次いで、所要に応 じて新しいふるまいを追加したりおよび／または継承したふるまいをオーバライ ドしたりすることによって開発される。 従って、開発者のアプリケーションは、他のすべてのフレームワークのアプリ ケーションと共に書かれ、共有されるコードの集合となる。これが強力な概念と なるが、その理由は、開発者は互いの作品に積み上げるように構築していくこと ができるからである。このことは、必要に応じて、多く、または少なくカストマ イズする柔軟性も開発者に与える。フレームワークには、そのままで使用される ものがある。ある場合には、カストマイズの量は最小になるので、開発者がはめ 込むジグソーパズルのピースは小さくなる。他の場合には、開発者は非常に大幅 な修正を行って、まったく新しいものを生成することもできる。好適実施例では 、図１に示すように、ＲＡＭ１４に常駐して、ＣＰＵ１０の制御を受けるプログ ラムが、オブジェクト指向グラフィック・フレームワークを使用して種々のタス クの管理を受け持っている。そのプログラムはカーソル・ツールを実行するのに 新たなアーキテクチャを使用している。「ツール」は選択するのにクリックオン され得るアイコンと通常関連している。いったん選択されると、ツールはカーソ ルの形を変更し、ユーザにドキュメントのコンテント領域において描画させる。 MacPaintのペイントブラシ・ツールはカーソル・ツールの古典的な例である。こ れらのツールは、カーソルを変更し、カーソルの下でデータに直接に作用するの で、カーソル・ツールと呼ばれている。カーソル・ツールに関連している特徴は 、ツールアイコンをクリックし、現在のカーソルの形を変更することによる選択 を含んでいて、選択したツールをユーザが「保持している」ことを示す。カーソ ル・ツールは、クリエータ、セレクタ、およびセレクタ／エフェクタ(effectors )を含む種々の種類において現われる。クリエータはアクティブなドキュメント のコンテント領域にわたってアクティブである。セレクタおよびセレクタ／エフ ェクタは、アクティブドなキュメントにおいて、理解する種類のフレームにわた ってのみアクティブである。 持続 アップル社のマッキントッシュのコンピュータでは、選択されたカーソル・ツ ールはアプリケーション内で持続する。例えば、もしMacPaintのペイントブラシ (paint-brush)・ツールを選択し、MacDrawに変更し、Rectangleツールを選択し 、それからMacPaintに戻るよう切り替える場合には、選択されたツールはペイン トブラシ、すなわちMacPaint内で選択した最終ツールになるであろう。好適実施 例では、ツールはある場所に持続するが、場所を越えて持続することはない。例 えば、もしレクタングル（矩形）カーソル・ツールが１つのアプリケー ションにおいて選択される場合には、たとえ如何なるフレームまたはドキュメン トがアクティブにされたにしても、そのカーソル・ツールは選択されたカーソル ・ツールのままである。 カーソル・ツールの例 カーソル・ツール・クラスター(Cursor Tool Cluster) クラスターは関連したカーソル・ツールを論理的および可視的にグループ化す る手段である。クラスターは種々のカーソル・ツールを保持するビュー(view)と 考えることができる。ツール・クラスターはそれら自体がパネルではなく、開発 者はクラスターをパネル上で使用することかできる。図２はMacDrawで用いられ る従来技術のカーソル・ツール・クラスターの１例である。 コマンド・パネル(Command Panels) コマンド・パネルはフレーム・ファニチュア上またはフレームのメニューに直 接には現われないフレームのコマンドの全てをグループ化しかつ組織化するもの である。コマンド・パネルは、（ひとまとめにされたまたはされていない）カー ソル・ツール、ボタン、スライダー、プルダウン・メニュー、スクロール・リス ト、テキスト・フィールド、追加パネル、または開発者が生成することができる いかなるカスタム・コントロールを介してこれらのコマンドにインタフェースを 提供する。全てのコマンド・パネルはフレーム作成ツール、即ちパネルによって 表されるタイプのフレームをドローするのに使用することができるカーソル・ ツールを含んでいなければならない。 コマンド・パネルとそのフレームとの間の関係はアプリケーションとそのドキ ュメントとの間の関係に類似している。コマンド・パネルはそのフレームを生成 するのに使用され得、そしてそのフレームおよびそのコンテントを操作(manipul ate)するためのインタフェースの大部分を保持している。しかし、大きな相違が ある。従来技術のツール・システムでは、アプリケーションはそのドキュメント を所有していて、それらのドキュメントを文字通り取り囲んでいる(surrounding )。好適実施例では、ドキュメントは最高位にある。そのドキュメントはフレー ムを所有し、かつ取り囲み、コマンド・パネルはユーザが用いることができる単 なるツールであり、それを使用してドキュメント内にフレームを生成したり、ま たは操作を行う。 このモデルでは、アプリケーションは単にコマンド・パネルおよび静的(stati onery)パッドであり、特別なタイプのフレームに対するコマンドへのインタフェ ースを提供し、かつそのタイプのフレームに対するフレーム生成カーソル・ツー ルを提供するよう設計されている。コマンド・パネルは、単一フレーム・タイプ に作用する制御を一緒にしてグループし、そしてベンダ(vendor)はしばしばそれ らのフレーム・タイプの各々に対するコマンド・パネルを生成し、その結果、コ マンド・パネルはベンダによる制御をグループ化するようになるかもしれない。 例えば、WordPerfectはそれらのWordPerfectフレーム・タイプに対するWordPerf ectコマンド・パネルを開発することになるだろう。グラフ・エディット・アプ リケーションのような共通フレーム・タイプに対しては、幾つかの異なるコマン ド・パネルがあり得る。コマンド・パネルは結局はユーザが構成可能なものであ るから、ユーザがどのベンダを選択しようとも、そのベンダからそれらユーザの イメージ操作制御の全てを単一のコマンド・パネル上にグループ化することがで きた。 コマンドはグローバル・コマンド・パネル・コンテナまたはコマンド・パネル ・バーを介してアクセスすることができる。アクティブなフレームに対するコマ ンド・パネルは制御キー・プレスのような複数キーのシーケンスを有するフロン ト部に置くことができる。図３は好適実施例によるコマンド・パネルであ る。 コマンド・パネル・バーは、ユーザがインストールしたかもしれない種々のコ マンド・パネルを表わすアイコンを含んでいる。さらに加えて、バーの上部の２ つのアイコンは特別である。最も上部のアイコンは常にアクティブなフレームに 対するコマンド・パネルを表わし、そして第２のアイコンはいかなるフレーム・ タイプにも包括的に適用できるツールの集まりを有するコマンド・パネルを常に 含んでいる。それらアイコンは選択矢印、オプションの拡大器(optional magnif ier)およびカラー・グラバー(color-grabber)を含んでいる。コマンド・パネル ・バーが、ドキュメント内またはデスクトップ上のフレームのコマンド・パネル の全てで占められることを示唆した初期の設計と異なって、この設計では、ユー ザはどのパネルが利用できるかを決定する。 ユーザがコマンド・パネルを介して利用できるアクションは、アイコンをクリ ック−ドラッグして、関連したコマンド・パネルを引き出す（プルアウトする） ことができる能力を含んでいる。コマンド・パネルは、コマンド・パネル・バー から除去し、デスクトップ上に配置することもできる。コマンド・パネル・アイ コンを１回クリックすることによって通常はフレーム生成ツールであるデフォル ト・ツールを選択する。選択ツール・コマンド・パネルの場合には、デフォルト ・ツールは矢印選択ツールである。図４は好適実施例によるコマンド・パネル・ バーの１例を示している。 コマンド・パネル・コンテナ(Command Panel Container) ユーザがコマンド・パネルをインストールする場合、コマンド・パネルはワー ク・スペース内のグローバル・コマンド・パネル・コンテナに集められる。ユー ザは、このコンテナ内のパネルに常にアクセスでき、すなわち種々のコマンド・ パネル・バーにそれらコマンド・パネルを位置させることができる。図５は好適 実施例によるコマンド・パネルの１例を示している。 現在のツール対アクティブなツール ユーザはツール・クラスタ内から現在のカーソル・ツールを選択することで現 在のカーソル・ツールをセットする。図６は好適実施例によるツール・クラスタ を示す図である。現在のツールは、ツールが機能し得るスクリーン領域上をユー ザがカーソルを移動させる時のみ、活性化される。カーソルが現在のツールに対 して不適当である領域内にあるときには、いつでも、アクティブなツールは選択 ツールに戻り、そしてカーソルの形は矢印に戻る。 アクティブ領域 アクティブ領域はアクティブなドキュメント(Active document)内にだけある 。アクティブなドキュメント・ファニチュア(furniture)を含むアクティブなド キュメントの外側のどこでも、アクティブなツール(active tool)は選択矢印に なる。アクティブなドキュメント内では、アクティブ領域は現在のツールおよび カーソルの下でのフレームのタイプに依存する。クリック・スルー(click-throu gh)のために、フレームがアクティブか否かは重要ではない。上述した如く、カ ーソル・ツールは３つのカテゴリー：クリエータ、セレクタ、およびセレクタ／ エフェクタになっている。 ・クリエータは新データ、すなわち円形ドローイング・ツールを生成する。 ・セレクタは既存のデータ、すなわちPhotoshopのMagic Wandを選択する。 ・セレクタ／エフェクタはデータ、すなわちMacPaintの消去ツールを選択し、 かつ変える。 クリエータ・カーソル・ツールは組込むことができる全てのフレーム上でアク ティブである。もしユーザが円形データ・タイプなしにフレーム上で円形を描く 場合には、ツール・フレームワーク(Tool Framework)は、円形を理解する新たな フレームを生成し、その円形をその新たなフレーム内に配置し、そしてその新た なフレームを既存フレームに組込む。この明瞭なフレーム生成は、ユーザが必要 とするところで、必要とする時に、まず適切なフレームを生成する必要なしに、 ユーザがデータを生成することを可能にする。セレクタおよびセレクタ／エフェ クタ・カーソル・ツールは、それらが理解できるタイプのフレーム上でだけアク ティブである。例えば、MacPaint消去ツールはMacPaintフレーム上でだけアクテ ィブである。上述の全ての他のフレーム上で、アクティブなツールは選択矢印に なる。 図７は好適実施例による種々のタイプのフレームの幾つかの例を示している。 アクティブなフレーム(Active frame)７００、アクティブでないフレーム(Inact ive frame)７２０、PinkDrawフレーム７１０、テキスト・フレーム(Text Frame) ７４０の各々は顕著な特徴を有している。図８は好適実施例による種々のフレー ムを有するデスクトップを示している。この図では、ユーザは２つのドキュメン トをオープンにしていて、その１つがアクティブ８００であり、他方が非アクテ ィブ８１０である。両ドキュメントは２のフレーム、１つのPinkDrawフレームと １つのテキスト・フレームとを有している。ユーザはPinkDrawのコマンド・パネ ル８３０からツールを選択している。図９は好適実施例によるレクタングル（矩 形）・カーソル・ツールおよびクリエータのユーザ選択を示している。アクティ ブなドキュメントのコンテント領域（ルートフレーム(root-frame)）の外側では 、アクティブなツールは選択矢印である。図１０は好適実施例による選択矢印を 示している。図１１は好適実施例によるアクティブなツールになるカーソル矩形 ツールを示している。図１２は好適実施例により、非アクティブなドキュメント を通過して、アクティブなツールになる選択矢印を示している。 図１３は好適実施例によるスマッジ・ツール(smudge tool)、セレクタ／エフ ェクタ用の選択プロセスを示している。図１４は好適実施例により、カーソルが 特定のフレームを通過するときのみスマッジ・ツールをイネーブルにすることを 示す。図１５および図１６は好適実施例により、ツール・カーソルがコンテント 領域を通過する際のツール・カーソルの動きを示す図である。カーソルがアクテ ィブなドキュメントのコンテント領域および他のPinkDrawではないフレームのコ ンテント領域を通過する際に、アクティブなツールは選択ツールになる。 コマンド・パネルのアクセス(accessing)／検索 コマンド・パネルをアクセスするのに複数の方法がある。ユーザはアイコンを ダブルクリックすることでグローバル・パネル・コンテナまたは任意の他のワー ク・スペース・コンテナ内からパネルをオープンすることができる。パネル・バ ー上に配置されているいかなるパネルに対しても、ユーザは単にパネルのアイコ ンを選択して検索することができる。ユーザがフレームを選択する場合には、ユ ーザは「Show command panel」コマンドを発生することができ、そしてワーク・ スペースが現在のフレームのタイプに対するディフォルト・コマンド・パネルを オープンする。従って、もしPinkDrawフレームを選択し、「Show commandpanel 」を選ぶと、ワーク・スペースはPinkDrawコマンド・パネルをオープンする。 フレーム・タイプごとの複数のコマンド・パネル いくつかのドキュメントのタイプはいくつかのアプリケーションによってオー プンすることができる。例えば、Painter、MacPaint、Photoshop、MacDraw、お よびTeachTextは、すべて、ＰＩＣＴファイルをオープンすることができる。好 適実施例によれば、イメージおよびテキストなどのあるフレームのタイプは多く の異なるコマンド・パネルを有する。特定のフレームで作業中に全ての可能なコ マンド・パネルの中から選ぶためには、フレームの特性シートによって、ユーザ がコマンド・パネルを選択し、および特定のフレームのタイプに対するディフォ ルト・コマンド・パネルをセットすることさえもできる。「Show command panel 」コマンドはディフォルト・コマンド・パネルをオープンする。 フレームおよびウィンドウの活性化 ウィンドウおよびフレームが如何に活性化されるかを理解することは重要であ る。その理由は、選択矢印以外のツールがアクティブなウィンドウ内でのみアク ティブであるからである。活性化を論じる場合には、考慮しなければならない２ つの問題点がある。第一に、ウィンドウまたはフレームはいつ活性化されるのか ？ 第二に、非アクティブなフレームまたはウィンドウへの最初のクリックが如 何にデータに作用するか？ フレーム フレームはマウス・ダウンして活性化しなければならない、その理由は、それ らの活性化フィードバックはユーザが開始しているアクションにとって重要かも しれないからである。例えば、もしユーザが矩形カーソル・ツールでフレームを クリック・ダウンすると、フレームは、矩形がクリップされる場所をユーザが知 ることができるようにその境界を示すように活性化しなければならない。非アク ティブなフレーム内での最初のクリックによって活性化させるのみならず、クリ ック・スルー効果のために、フレームのコンテンツは、フレームがすでにアクテ ィブであったかのようにふるまう。従って、もし消去カーソル・ツールが選択さ れ、そして非アクティブなフレームを横切ってドローするように用いられると、 検出された最初のクリックによって幾つかのデータを消去する。 ウィンドウ マウス・アップ・イベントがウィンドウの境界内で起こる時にウィンドウは活 性化される。マウス・アップは、ウィンドウの境界内でのクリックの後またはユ ーザがオブジェクトをウィンドウ内にドラッグしている時にマウスボタンを離す 際に行われ得る。ウィンドウはマウス・アップまで活性化されないので、アクテ ィブなツールはドラッグしている間は常に選択矢印になる。現在のツールが選択 矢印以外の何かである場合には、ドラッグが完了してターゲット・ウィンドウが 活性化した後においてのみ活性化される。非アクティブなウィンドウ内の最初の クリックは、オブジェクトを選択またはドラッグする以外に、ウィンドウの内容 に影響することはできない。最初のクリックは、ダメージを与えることは何も しないので、ユーザがセレクタ／エフェクタ・ツールをスクリーンを横切ってス ワィプ(swipe)することによってデータを偶発的に破壊することはできないよう にすることが重要である。しかし、最初のクリックでデータを選択し、およびド ラッグすることにより、ドラッグ−アンド−ドロップの動作は促進される。ウィ ンドウはマウス・アップまで活性化されないので、非アクティブなウィンドウを フロント部に移すことなしにオブジェクトは非アクティブなウィンドウから選択 され、そしてアクティブなウィンドウにドラッグされることができる。図１７は 好適実施例によるウィンドウおよびフレーム処理を要約している。 ツール・アーキテクチャの概説 ツール・システムは、フレームおよびドキュメントを横切って用い得るカーソ ル・ツールを開発する構造を提供し、および（ツール・パレットのような）ツー ル選択コントロールからユーザのデータに作用することができるフレームへツー ルを転送する必要なシステム・サービスを提供する。TToolクラスはツール選択 コントロールからツールを転送するシステム・サービスを提供する。TToolはTTo olInteractor、カーソル・グラフィック、パレット・グラフィック、テキスト・ ネーム、およびタイプ・ネゴシエーション情報を含む単純なクラスである。TToo lInteractorはTInteractorの直截的なサブクラスである。TToolInteractorはビ ューおよびプレゼンテーションをインタアクタ(interactor)に通過させるプロト コルのみを加算する。ユーザがツールを有する適切なフレームにおいていったん マウス−ダウンをすれば、TToolInteractorはそのフレーム内に見えるデータを 変更する。パレット・グラフィック、およびテキスト・ネームは、識別グラフィ ックまたはテキスト・ストリングを表示する現在のツールをセットするコントロ ールにより用いられる。カーソル・グラフィックは、ツールが用いられ得るフレ ーム上をツールが横切る時に、カーソルが取り込む形である。タイプ・ネゴシエ ーション情報はツールが作用し得る選択タイプのリストである。このリストはツ ールが所定のフレームにおいて機能できるか否かを決定するために用いられる。 現在のツールのセッティングおよび分配 ３つのオブジェクトは現在のツールをセットおよび分配するよう協調して作業 する。それらはSetCurrentToolCmd、ToolServer、およびToolNegotiatorである 。 SetCurrentToolCmd 活性化される時、SetCurrentToolCmdは所定のTToolを選び、それをToolServer に送る。SetCurrentToolCmdはボタンおよびツール・パレットのようなコントロ ールに配置されるよう設計されている。開発者は非常にしばしば一組のボタンか らツール・パレットを構成し、各ボタンがSetCurrentToolCmdを有し、各コマン ドが異なるTToolを保持している。 ToolServer（ツール・サーバ） ToolServerのジョブはツールをカーソルに関連させることである。 SetCurrentToolCmdがツールおよびカーソルをToolServerに送るときに、サーバ は所定のカーソルに対する現在のツールとしてツールをセットする。その後に、 ビューが所定のカーソルに対する現在のツールを求めるときに、ToolServerはカ ーソルを調べ、そしてツールをToolNegotiatorを介して要求中のビューに通過さ せる。 ToolNegotiator（ツール・ネゴシエータ） ToolNegotiatorの役割は、ビューとネゴシエートし、ついでネゴシエーション が成功した場合に、現在のツールをそのビューに転送することである。カーソル が実行(enter)されると、以下の順序のコマンドが生じる。第一に、カーソルは アクティブなフレームを越えて通過する。次に、フレームのコンテント・ビュー は「CursorEntered」通知を受け、そしてToolServerからネゴシエータを要求す る。次に、ToolServerは現在のツールに対するネゴシエータを構成し、およびそ のネゴシエータを要求中のビューに送り、そしてビューはツール・ネゴシエータ に選択を与え、およびコマンドを実行してカーソルの形を変える。最後に、ツー ル・ネゴシエータはその選択タイプのリストをビューによって提供される選択の タイプと比較する。選択がツールが理解できるタイプである場合には、ネゴシエ ータはカーソルの形を現在のツールのカーソル・グラフィックに変える。 マウス・ダウンに関するコールの順序 多くのカーソル環境では、ビューは、マウス・ダウンしたカーソルが最も最近 にネゴシエートしたものと同じであったということは確証できないので、ビュー はToolServerからネゴシエータを再び要求しなければならない。サーバはネゴシ エータを返し(return)、そしてビューは選択をネゴシエータに渡す、すなわちパ スする。ネゴシエーションが成功すると、ネゴシエータは現在のToolInteractor を要求する。すなわち、ツールが選択を理解すると、ネゴシエータはToolIntera ctorをビューに返す。そのビューは適切な値をToolInteractorにセットし、相互 作用を開始する。この時点において、インタアクタ(interactor)が引き継いでユ ーザ相互作用の実行を進める。 フロー・ダイアグラム 図１８は好適実施例によるツール処理の論理を示すフロー・ダイアグラムであ る。処理は、ツールパレット１８４０が特定のツールの選択を検出した１８００ のところにおいて開始する。１８００において、現在のツールは活性化され、そ して現在のツールに関連する情報がToolServer１８１０に通過させられる。Tool Server１８１０は、次にツール・ネゴシエータ１８３０によりコールされて、To olServer１８１０へのコール１８２０を介してツールの適切な特性を活性化する 。ToolServer１８１０は、次にツール・ネゴシエーション・メッセージ １８２０を介してのアプリケーションへのステータス（状態）情報をツール・ネ ゴシエータ１８３０に送り返して、ディスプレイを更新する。 TAbstractTool 図１９は好適実施例によるクラス階層を示すブロック図である。ここで特に関 心のあることは、ツールのI.D.を得るTGlobalID GetID() const;およびツールの I.D.をセットするvirtual void SetID(TGlobalID);である。カーソル・ツールの フレームワークはツールのグローバルI.D.を用いてToolServer内でそのグローバ ルI.D.を一意的に識別し、および適切なツールに変更された旨の通知をツール・ セッティング・コマンドに供給する。 TTool TToolはツールを定義する抽象的なスーパークラスである。TToolまたToolServ erと交信する幾つかの静的メソッドをも有している。TToolのサブクラスは実際 にはほとんど作業をしない。それらのサブクラスは、メニューおよびツール・パ レットに対するグラフィックスおよびテキスト・ネーム、アクティブな時にツー ルを表すカーソル・グラフィック、ツールが有効である選択タイプのリストを提 供し、そして、それらはユーザが選択されたツールを有する有効なフレームにお いてマウス・ダウンする時に活性化されるインタアクタ(interactor)のサブクラ スを作成する。フレームにおいてデータを生成または変更する実際の作業を実行 するオブジェクトはインタアクタである。 純粋仮想メソッド(Pure Virtual Methods) virtual MGraphic* CreatePaletteGraphic() const=0; サブクラスは、ツール・パレットまたはメニュー上で用いるべき新たなMGraph icを返さなければならない。 virtual void GetPaletteText(TText&) const=0; サブクラスは、TTextのテキストをツールを表すメニュー・アイテムに適して いるストリングにセットしなければならない。 virtual MGraphic* CreateCursorGraphic() const=0; サブクラスは、ツールがアクティブな時にカーソルとして用いるべき新たなMG raphicを返さなければならない。 virtual TToolInteractor* CreateInteractor(TToken) const=0; サブクラスは、ユーザが有効なフレームにおいてマウス・ダウンする時に開始 すべき新たなTToolInteractorを返さなければならない。パスイン(Passed in)さ れたトークン(token)はクリック・イン(Clicked in)されたフレームを表す選択 のタイプである。TToolはトークンを用いて受け取るフレームのタイプに従って 異なるインタアクタを生成することができる。 virtual void CreateTypeInfoList(TSequence&) const=0; サブクラスは、ツールがその中で作業できる各モデルから選択の各タイプに対 するトークン(token)でシーケンスを充足しなければならない（TType オブジェ クトが利用できるようになると、トークンは各適切な選択に対するTTypeで置き 換えられる）。例えば、もしツールがGrafEditモデルおよびTTextContainerモデ ルで作業するならば、サブクラスはTGrafEditSelection::kTypeおよびTTextSele ction::kTypeをシーケンスに配置するであろう。 さらに、ツールはブーリアン(Boolean)メソッドによってセットされた２つの ふるまいを有している。 Boolean IsOneShot() const; デフォルトをFALSEへ。「One-shot（ワンショット）」ツールは単一の使用に だけ選択される。ツールがいったん用いられると、ToolServerは現在のツールを デフォルト・ツール（選択矢印）に自動的に切り替える。デフォルトにより、こ のメソッドはFALSEを戻して、ユーザが新たなツールをパレットまたはメニュー から選択するまではツールが現在のツールのままになるようにする。 void SetIsOneShot(Boolean isOne=TRUE); この方法を用いてツールをワンショットまたはそうでないよう動的にセットす る。例えば、パレット開発者は、ユーザがパレットにおいて１回だけクリックす る場合には、ツールを常にワンショットにセットするが、ユーザが２回クリック する場合には、継続的(sticky)である（ワンショットでない）ようセットする。 virtual Boolean IsCreationTool() const; デフォルトをFALSEへ。データを生成できるツールはいかなる（ＡＮＹ）組込 みフレームにおいても有効である。もしツールが用いられるべきフレームの明示 の知識を有さない場合には、フレームワークはツールが知っている新たなフレー ムを生成および組込みする。現在は、フレームワークは組込み支持（サポート） を提供しないので、ツールがフレームを明示的に生成および組込むことができる 場合にのみこのメソッドをオーバライドする。 ToolServerをアクセスする静的メソッド static void SetCurrentTool(const TTool& theTool); 「theTool」を現在のツールとしてセットする。 staticTTool* CopyCurrentTool(); 現在のツールのコピーを返す。 static TToolNegotiator* CopyCurrentToolNegotiator(); 現在のツールのための新たなTToolNegoriatorを返す。 static TTool* CopyDefaultTool(); システム・デフォルト・ツールのコピーを返す。目下のところ、デフォルト・ツ ールはTSelectionArrowである。 static void SetToDefaultTool(); 現在のツールをデフォルト・ツールにセットする。 通知インタレスト(interests)を生成する静的メソッド static TInterest* CreateCurrentToolChangedInterest(); 現在のツールが変わる度毎に通知を受けるのに用いられるインタレストを返す。 static TInterest* CreateCurrentToolTypeChangedInterest(); 現在のツールが異なるクラスのツールに変わる度毎に、通知を受けるのに用いら れるインタレストを返す。 TToolSurrogate 非常に単純なTAbstractToolサブクラス。そのサブクラスはデータ・メンバを 加算しない。そのただ関心のあるメソッドはTToolSurrogatesがいかなるTAbstra ctToolにもセットできるように定義されたオペレータ（演算子）である。 TSelectionArrow 以下の属性を有する単純なTToolサブクラス。 Palette Graphic（パレット・グラフィック）：標準ピンク矢印 Cursor Graphic（カーソル・グラフィック）：標準ピンク矢印 Palette Text（パレット・テキスト）：「矢印」 Type Info:TModelSelection::kType。矢印はいずれのフレームにおいても有効で ある。 Tool Interactor（ツール・インタアクタ）：なし。選択矢印はそのインタアク タに対してNILを返す。クリック−インしたフレームはそれ自体の選択インタア クタを提供しなければならない。 TToolNegotiator TToolNegotiatorsは受取りチームにおける現在のツールを表す軽量の一定の構 造形態をもつ(monomorphic)オブジェクトである。例えば、カーソルがアクティ ブなドキュメントにおけるフレームを通過する時、そのフレームはTToolNegotia torを通過する。フレームがTToolNegotiatorとネゴシエートして、カーソルの形 を変えるかどうかをネゴシエータに知らせる。１回のマウス・ダウンでフレーム もTToolNegotiatorを得て、現在のツールがフレーム内で有効であるかどうかを 知るためにネゴシエーションする。もしそうならば、フレームはTToolNegotiato rからToolInteractorを得て相互作用を開始する。 TToken Accepts(const TModelSelection&) const; 現在のツールが所定の選択に対して有効であり、所定の選択の明示的な知識を 有する場合には、選択のタイプを返す。もし現在のツールが生成ツールであり、 現在の選択が組込み選択であるだけの理由で所定の選択に対して有効であれば、 TTool::kEmbeddingSelectionsを返す。ツールが所定の選択に対して有効でない 場合にはTTool::kSelectionRejectedを返す。 void AdjustCursorShapeFor(const TModelSelection&) const; ツールが所定の選択に対して適用できる場合には、カーソルの形を現在のツー ルの形にセットする。 TToolInteractor* CreateInteractor(const TModelSelection&) const; まず、選択用のAcceptsをコールする。現在のツールが所定の選択を受け付け る場合には、ツールのインタアクタを返す。そうでなければ、NILを返す。共通 の使用は次の通りである： TToolInteractor* anInteractor=NIL; TToolNegotiator* negotiator=TTool::CopyCurrentToolNegotiator(); if (anInteractor = negotiator->CreateInteractor(aSelection)) anInteractor->StartTracking(); Else{ // 選択インタアクタを開始 } TToken GetToolType()const; 現在のツールのタイプを返す。 TToolInteractor TToolInteractorは、サブクラスが相互作用状態にときどき通過させるビュー および選択をセッティングしかつ得るためのメソッドを有する。 TToolInteractorsはワンショットのツールで生成されたかどうかが分かる。それ らがワンショットのツールで生成されたならば、 TToolInteractor::StopTrackingにおけるTTool::SetToDefaultToolをコールする 。 void SetView(TView*); void SetSelection(TModelSelection&); TView* GetView() const; TModelSelection* GetSelection() const; 発呼者(CALLER)／ディスパッチャ(DISPATCHER)のクラス TToolServer TToolServerはツール・サーバをインプリメントするディスパッチャ・クラス である。図２０は好適実施例によるTToolServerクラスのダイアグラム図である 。 TToolServerCaller TToolServerCallerは、TToolによって用いられて、ToolServerと交信するディ スパッチャ・クラスである。これらのうちの１つを例示するかまたは１つに直接 に話すべきではない。 コマンド・クラス TSetCurrentToolCmd ToolServerにおける現在のツールをその限界ツール(bound tool)にセットする 。図２１は好適実施例によるコマンド・クラスを示す。 TSetCurrentToolCmd(const TTool& theTool); theToolを有するコマンドをその限界ツールとして構成する。 void SetTool(const TTool& theTool); theToolをコマンドの限界ツールとしてセットする。そのコマンドは、古いツ ールがあった場合には、その古いツールを破棄する。 Boolean GetSelected(); コマンドの限界ツールが現在のツールであるか否か（すなわち、このコマンド を保持するコントロールが「選択された」としてそれ自体を示すべきかどうか） によって返す。 void SetSelected(Boolean); コントロールのCommandBooleanSetterとして用い得るが、実際にはなにもしな い。そのコマンドはToolServerからの通知にだけ基づいたその選択された状態を セットする。 TInterest* CreateSelectionStateChangedInterest() const; このインタレストを用いて、特別なコマンドの選択された状態が変化する時に 通知を受け取る。そのコマンドは、コントロールが TSetCurrentToolCmd::ConnectData() をコールする時に、このインタレストを用 いる。 TSetToDefaultToolCmd 現在のツールをデフォルト・ツールにセットする。 カーソル・グラフィックス 予め組込まれた幾何(geometry)を有するMGraphicサブクラス。図２２は予め組 込まれた幾何の幾つかを示す。 TCrossHairGraphic TExGraphic TArrowGraphic ユーティリティ・クラス TToolInstanceInterest このインタレストはTAbstractToolで構成される。それは現在のツールになるT AbstractToolの特別の瞬時でのインタレストを表現する。図２３は好適実施例に よるユーティリティ・クラスを示す。 TToolInstanceInterest(const TAbstractTool&， MNotifier*, const TToken&); TToolChangedNotification ToolServerは、現在のツールが変わる度毎にTToolChangedNotificationを伝え る、すなわちスロー(throw)する。通知は新たな現在のツールに対するTToolSurr ogateおよびそのクラスのネームを保持している。 通知からデータを抽出するメソッド TToolSurrogate GetToolSurrogate() const; TToken GetToolType() const; TCursorToolException Cursor Toolのフレームワークによりスローされた例外サブクラス。 TCursorToolException により定義されたエラー kNoBoundCursor = 0x1D02 制限のないカーソルを有するTSetCurrentToolCmd::Do()called。この例外は現 在では用いられていない。カーソル・サーバが複数のカーソルを支持する時にス ローされる。その時に、プログラマはそれを生じる前にツールとカーソルの双方 をコマンドに結合することが必要となる。 kNoBoundToolInCommand = 0x1D02 コマンドが制限ツールを持たない時に、制限ツールを必要とするTSetCurrentT oolCmd上のメソッドをコールしようとする時にスローされる。 kNoBoundToolInServer = 0x1D03 現在のツールがセットされる前に、カレントツールを必要とするTToolServer 上のメソッドをコールしようとする時にスローされる。 本発明を特定のシステム環境における好適実施例に基づいて述べてきたが、本 発明は、以下の特許請求の範囲精神および範囲内において、他のおよび異なるハ ードウェアおよびソフトウェア環境の下での変更例を以て実施することができる ことを当業者は認識するであろう。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ， ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，Ｇ Ｂ，ＨＵ，ＪＰ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＵ，ＬＶ ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ， ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＫ，ＵＡ，ＵＺ，ＶＮ 【要約の続き】 メントがツールを意識する必要がない。

Claims (1)

1. 【特許請求の範囲】 １．メモリ、グラフィック、ビュー・オブジェクト、および取付けられたディス プレイを有するコンピュータオペレーションを実行する方法であって、 （ａ）選択信号を検出するステップと、 （ｂ）該選択信号が検出される時にカーソルの位置に対応するグラフィック・ オブジェクトを識別するステップと、 （ｃ）前記位置に対応するウィンドウを決定するステップと、 （ｄ）前記位置に対応するグラフィック・オブジェクトにおけるオブジェクト を決定するステップと、 （ｅ）前記選択信号が検出される時にカーソルの位置に基づいて特定のビュー ・オブジェクトに関連するコマンド・オブジェクトを実行するステップと、 （ｆ）該コマンド・オブジェクトに関連するツール・オブジェクトをツール・ サーバ・オブジェクトにパスさせるステップと、 （ｇ）該ツール・サーバ・オブジェクト内のカーソルに対する現在のツールを 前記ツール・オブジェクトにセットするステップと、 （ｈ）前記ツール・サーバ・オブジェクトを介して、前記ツール・オブジェク トとアプリケーションをリンクするステップと を具えたことを特徴とする方法。 ２．請求項１に記載の方法において、前記ツール・オブジェクトと前記アプリケ ーションをアドレス空間を横切ってリンクさせるステップを具えたことを特徴と する方法。 ３．請求項１に記載の方法において、複数のツール・オブジェクトのメニュー内 の１つのツール・オブジェクトを可視的に変更してアクティブなカーソル・ツー ルを示すステップを具えたことを特徴とする方法。 ４．請求項１に記載の方法において、複数のツール・オブジェクトのメニューか ら１つのツール・オブジェクトを選択するステップを具えたことを特徴とする方 法。 ５．請求項１に記載の方法において、複数のツール・オブジェクトのメニュー内 の１つのツール・オブジェクトを表示するステップを具えたことを特徴とする方 法。 ６．請求項１に記載の方法において、前記ツール・オブジェクトの状態を示すフ レームを表示するステップを具えたことを特徴とする方法。 ７．請求項１に記載の方法において、前記ツール・オブジェクトに基づいてカー ソルを変えるステップを具えたことを特徴とする方法。 ８．請求項１に記載の方法において、前記ツール・オブジェクトの状態に基づい てカーソルを変えるステップを具えたことを特徴とする方法。 ９．（ａ）プロセッサと、 （ｂ）該プロセッサに取付けられ、該プロセッサの制御下にある記憶装置と、 （ｃ）該プロセッサに取付けられ、該プロセッサの制御下にあるディスプレイ と、 （ｄ）選択信号を検出する手段と、 （ｅ）該選択信号が検出される時にカーソルの位置に対応するグラフィック・ オブジェクトを識別する手段と、 （ｆ）前記位置に対応するウィンドウを決定する手段と、 （ｇ）前記位置に対応するグラフィック・オブジェクトにおけるビュー・オブ ジェクトを決定する手段と、 （ｈ）前記選択信号が検出される時に前記カーソルの位置に基づいて特定のビ ュー・オブジェクトに関連するコマンド・オブジェクトを実行する手段と、 （ｉ）該コマンド・オブジェクトに関連するツール・オブジェクトをツール・ サーバ・オブジェクトにパスする手段と、 （ｊ）前記ツール・サーバ・オブジェクト内の前記カーソルに対する現在のツ ールを前記ツール・オブジェクトにセットする手段と、 （ｋ）前記ツール・サーバ・オブジェクトを介して、前記ツール・オブジェク トとアプリケーションをリンクさせる手段と を具えたことを特徴とする装置。 １０．請求項９に記載の装置において、前記ツール・オブジェクトと前記アプリ ケーションをアドレス空間を横切ってリンクさせる手段を具えたことを特徴とす る装置。 １１．請求項９に記載の装置において、複数のツール・オブジェクトのメニュー 内の１つのツール・オブジェクトを可視的に変更してアクティブなカーソル・ツ ールを示す手段を具えたことを特徴とする装置。 １２．請求項９に記載の装置において、複数のツール・オブジェクトのメニュー から１つのツール・オブジェクトを選択する手段を具えたことを特徴とする装置 。 １３．請求項９に記載の装置において、複数のツール・オブジェクトのメニュー 内の１つのツール・オブジェクトを表示する手段を具えたことを特徴とする装置 。 １４．請求項９に記載の装置において、前記ツール・オブジェクトの状態を示す フレームを表示する手段を具えたことを特徴とする装置。 １５．請求項９に記載の装置において、前記ツール・オブジェクトに基づいて前 記カーソルを変える手段を具えたことを特徴とする装置。 １６．請求項９に記載の装置において、前記ツール・オブジェクトの状態に基づ いて前記カーソルを変える手段を具えたことを特徴とする装置。 １７．メモリ、オブジェクト指向オペレーティング・システムにおけるオブジェ クト、少なくとも１つのカーソル、および取付けられたディスプレイを有するコ ンピュータのオペレーションを実行する方法であって、 （ａ）カーソルが前記ディスプレイ上の領域に入ったことを検出するステップ と、 （ｂ）その検出されたカーソルに対応する現在のツールを得るステップと、 （ｃ）現在のツールに対応するツール・ネゴシエータ・オブジェクトを得るス テップと、 （ｄ）前記現在のツールが前記ディスプレイ上の領域内で有効か否かを決定す るために前記ツール・ネゴシエータ・オブジェクトをコールするステップと、 （ｅ）前記現在のツールに対応するグラフィック・オブジェクトを得るステッ プと、 （ｆ）前記カーソルを該グラフィック・オブジェクトに変えるステップと を具えたことを特徴とする方法。 １８．請求項17に記載の方法において、前記ツール・ネゴシエータ・オブジェク トのネゴシエーションは、 （ａ）前記ツールに関連する選択タイプのリストを得るステップと、 （ｂ）前記選択タイプのリストを前記ディスプレイ上の領域に関連するデータ に関連する選択タイプのリストと比較するステップと を具えたことを特徴とする方法。 １９．請求項１７に記載の方法において、 （ａ）マウス・イベントを検出するステップと、 （ｂ）前記検出されたカーソルに対応する現在のツールを得るステップと、 （ｃ）その現在のツールに対応するツール・ネゴシエータ・オブジェクトを得 るステップと、 （ｄ）前記現在のツールが前記ディスプレイ上の領域内で有効か否かを決定す るために前記ツール・ネゴシエータ・オブジェクトをコールするステップと、 （ｅ）前記ツール・ネゴシエータからツール・インタアクタを得るステップと 、 （ｆ）そのツール・インタアクタに制御を移すステップと、 （ｇ）前記ツール・インタアクタの制御の下でツール特有のアクションをディ スプレイ上の領域に供給するステップと、 を具えたことを特徴とする方法。 ２０．請求項１７に記載の方法において、フレームを前記ディスプレイ上の領域 に組込むステップとを具えたことを特徴とする方法。