オブジェクト指向カーソル・ツール
【課題】本発明のシステムおよび方法はいかなるシステム上の複数のカーソルに対するサポートをも有するカーソル・ツール・フレームワークおよびツール・サーバを提供し、カーソルを用いるカーソル・ツールの選択をサポートする。
【解決手段】フレームワークおよびサーバは、プロセスとは独立した空間内のカーソルに対するカーソル・ツールの関係を容易にして、ツールがプロセスを越えておよびドキュメントを越えて用いられ得るようにする。フレームワークは、用いられるカーソル・ツールおよびキャンバス間の通信およびネゴシエーションのためのディフォルトの機能をも提供する。このネゴシエーションによって、いかなるカーソル・ツールおよびいかなるドキュメントも共に機能して、ドキュメント開発者の知識なしにカーソル・ツールが書き込まれるようにすることができる。
【解決手段】フレームワークおよびサーバは、プロセスとは独立した空間内のカーソルに対するカーソル・ツールの関係を容易にして、ツールがプロセスを越えておよびドキュメントを越えて用いられ得るようにする。フレームワークは、用いられるカーソル・ツールおよびキャンバス間の通信およびネゴシエーションのためのディフォルトの機能をも提供する。このネゴシエーションによって、いかなるカーソル・ツールおよびいかなるドキュメントも共に機能して、ドキュメント開発者の知識なしにカーソル・ツールが書き込まれるようにすることができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にはコンピュータ・システムにおける改良に関し、特にオブジェクト指向オペレーティング・システムにおけるツール・オブジェクトおよびツール・オブジェクトのメニューを用いるシステムおよび方法に関する。
【背景技術】
【０００２】
著作権表記
本明細書の一部には、著作権保護の対象となる内容が含まれている。著作権所有者は、米国特許商標庁の特許ファイルまたは記録に記述されている特許文書または特許開示事項を誰かがそのまま複製することに異論を唱えないが、その他の場合には著作権に係わる一切の権利を留保する。
【０００３】
発明の背景
カーソル・ツールは、ユーザ制御される「カーソル」のふるまいを変えることでユーザのドキュメントまたはフレームとの相互作用の特定のモードを特定する。例えば、ユーザは「レクタングル（矩形）」カーソル・ツールを選択して、マウスボタンを押しながらマウスをドラッグすることで、ドキュメント・ドローイング（描画）キャンバス上にレクタングルを生成することをオペレーティング環境に指示することができる。ツールはデータの選択、操作および生成用のモードを指示することができる。カーソル・ツールの従来技術例はMacPaint（登録商標）またはMacDraw(登録商標）のようなアプリケーションにおいて見受けられる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、これらのアプリケーションは一度に２つ以上のカーソルの管理をユーザに提供しなかった。さらに、オペレーティング・システムへの統合を行って、１つのアプリケーションにおいてアクティブなツールを他のアプリケーションでも機能させることができるようにすることはなされていなかった。カーソル・ツールとアプリケーションとの間のネゴシエーションの能力も従来技術では知られてはいなかった。
【課題を解決するための手段】
【０００５】
本発明の革新的システムおよび方法ではオブジェクト指向技術を用いて、複数のカーソル・ツールを一つのオブジェクト指向オペレーティング・システムに統合する。この統合は複数のタスクでの複数のカーソル・ツールを同時に管理することを含んでいる。ネゴシエーション能力を設けて、任意のカーソル・ツールと任意のアプリケーションとを共に機能させることができるようにする。この独自の能力は区画を越えてのメモリ管理を含み、それによりアプリケーションおよび区分を越えてカーソル・ツールを使用することを可能にしている。オブジェクト指向のフレームワークによりカーソル・ツールをアプリケーションを越えて分配するためのアーキテクチャを提供するので、そのためカーソル・ツール機能が必要になるまではアプリケーション要求はツールについて知らない。技術用語では、これは、カーソル・ツールがアプリケーションの情報をうまく変更できることが決定された後までは、どんなアプリケーションでもカーソル・ツールの共有ライブラリにおいてマッピングすることなしにカーソル・ツールを使用することができることを意味する。
【発明を実施するための最良の形態】
【０００６】
本発明はＩＢＭ（登録商標）社のＰＳ／２（登録商標）またはアップル（登録商標）社のマッキントッシュ（登録商標）コンピュータのようなパーソナル・コンピュータに常駐するオペレーティング・システムの下で実行されるのが好ましい。代表的なハードウェア環境は図１に示され、図１は、組み込みの不揮発性記憶装置１１を有する慣例のマイクロプロセッサのような中央処理装置１０およびシステム・バス１２を介して相互接続された多数の他のユニットを有する本発明によるコンピュータの代表的なハードウェア構成を示す。図１に示されるワークステーションは、ランダム・アクセス・メモリ（ＲＡＭ）１４、リード・オンリ・メモリ（ＲＯＭ）１６、ディスク・ユニット２０およびディスケット・ユニット２１のような周辺装置をバスに接続する入出力アダプタ１８、キーボード２４、マウス２６、スピーカ２８、マイクロホン３２、および／またはタッチ・スクリーン装置（図示せず）などのような他のユーザ・インタフェース装置をバスに接続するユーザ・インタフェース・アダプタ２２、このワークステーションをデータ処理ネットワーク２３に接続する通信アダプタ３４、およびバスをディスプレイ装置３８に接続するディスプレイ・アダプタ３６を含んでいる。このコンピュータには、Apple System/7（登録商標）オペレーティング・システムのようなオペレーティング・システムを搭載してある。
【０００７】
オブジェクト指向プログラミング技術
好適実施例では、本発明はオブジェクト指向プログラミング技術を用いてＣ++プログラミング言語で実現されている。当業者によって理解されるように、オブジェクト指向プログラミング（ＯＯＰ）のオブジェクトは、データ構造およびデータに対するオペレーションを含むソフトウェア・エンティティである。これらのエレメントが一緒になって、オブジェクトが、そのデータ・エレメントで表現されたその特性、およびそのデータ操作関数で表現されたそのふるまいないし作用(Behavior)の形態でいかなる実世界のエンティティをも仮想的にモデル化することができる。このようにして、オブジェクトは、人々やコンピュータのような具体物をモデル化することができ、かつ、数や幾何学的概念のような抽象的概念をモデル化することができる。オブジェクト技術の利点は次の３つの基本的原理から得られるものである。それは、カプセル化(encapsulation）、多態(polymorphism)、および継承(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内で選択した最終ツールになるであろう。好適実施例では、ツールはある場所に持続するが、場所を越えて持続することはない。例えば、もしレクタングル（矩形）カーソル・ツールが１つのアプリケーションにおいて選択される場合には、たとえ如何なるフレームまたはドキュメントがアクティブにされたにしても、そのカーソル・ツールは選択されたカーソル・ツールのままである。
【００２２】
カーソル・ツールの例
・ 多角形カーソル・ツール：
【００２３】
【００２４】
・ 矢印選択カーソル・ツール：
【００２５】
【００２６】
・ カラー・グラバー(color-grabber)(「アイ・ドロッパー(eye-dropper)」) カーソル・ツール：
【００２７】
【００２８】
カーソル・ツール・クラスター(Cursor Tool Cluster)
クラスターは関連したカーソル・ツールを論理的および可視的にグループ化する手段である。クラスターは種々のカーソル・ツールを保持するビュー(view)と考えることができる。ツール・クラスターはそれら自体がパネルではなく、開発者はクラスターをパネル上で使用することかできる。図２はMacDraw で用いられる従来技術のカーソル・ツール・クラスターの１例である。
【００２９】
コマンド・パネル(Command Panels)
コマンド・パネルはフレーム・ファニチュア上またはフレームのメニューに直接には現われないフレームのコマンドの全てをグループ化しかつ組織化するものである。コマンド・パネルは、（ひとまとめにされたまたはされていない）カーソル・ツール、ボタン、スライダー、プルダウン・メニュー、スクロール・リスト、テキスト・フィールド、追加パネル、または開発者が生成することができるいかなるカスタム・コントロールを介してこれらのコマンドにインタフェースを提供する。全てのコマンド・パネルはフレーム作成ツール、即ちパネルによって表されるタイプのフレームをドローするのに使用することができるカーソル・ツールを含んでいなければならない。
【００３０】
コマンド・パネルとそのフレームとの間の関係はアプリケーションとそのドキュメントとの間の関係に類似している。コマンド・パネルはそのフレームを生成するのに使用され得、そしてそのフレームおよびそのコンテントを操作 (manipulate)するためのインタフェースの大部分を保持している。しかし、大きな相違がある。従来技術のツール・システムでは、アプリケーションはそのドキュメントを所有していて、それらのドキュメントを文字通り取り囲んでいる (surrounding) 。好適実施例では、ドキュメントは最高位にある。そのドキュメントはフレームを所有し、かつ取り囲み、コマンド・パネルはユーザが用いることができる単なるツールであり、それを使用してドキュメント内にフレームを生成したり、または操作を行う。
【００３１】
このモデルでは、アプリケーションは単にコマンド・パネルおよび静的(stationery)パッドであり、特別なタイプのフレームに対するコマンドへのインタフェースを提供し、かつそのタイプのフレームに対するフレーム生成カーソル・ツールを提供するよう設計されている。コマンド・パネルは、単一フレーム・タイプに作用する制御を一緒にしてグループし、そしてベンダ(vendor)はしばしばそれらのフレーム・タイプの各々に対するコマンド・パネルを生成し、その結果、コマンド・パネルはベンダによる制御をグループ化するようになるかもしれない。例えば、WordPerfect はそれらのWordPerfect フレーム・タイプに対するWordPerfect コマンド・パネルを開発することになるだろう。グラフ・エディット・アプリケーションのような共通フレーム・タイプに対しては、幾つかの異なるコマンド・パネルがあり得る。コマンド・パネルは結局はユーザが構成可能なものであるから、ユーザがどのベンダを選択しようとも、そのベンダからそれらユーザのイメージ操作制御の全てを単一のコマンド・パネル上にグループ化することができた。
【００３２】
コマンドはグローバル・コマンド・パネル・コンテナまたはコマンド・パネル・バーを介してアクセスすることができる。アクティブなフレームに対するコマンド・パネルは制御キー・プレスのような複数キーのシーケンスを有するフロント部に置くことができる。図３は好適実施例によるコマンド・パネルである。
【００３３】
コマンド・パネル・バーは、ユーザがインストールしたかもしれない種々のコマンド・パネルを表わすアイコンを含んでいる。さらに加えて、バーの上部の２つのアイコンは特別である。最も上部のアイコンは常にアクティブなフレームに対するコマンド・パネルを表わし、そして第２のアイコンはいかなるフレーム・タイプにも包括的に適用できるツールの集まりを有するコマンド・パネルを常に含んでいる。それらアイコンは選択矢印、オプションの拡大器(optional magnifier)およびカラー・グラバー(color-grabber) を含んでいる。コマンド・パネル・バーが、ドキュメント内またはデスクトップ上のフレームのコマンド・パネルの全てで占められることを示唆した初期の設計と異なって、この設計では、ユーザはどのパネルが利用できるかを決定する。
【００３４】
ユーザがコマンド・パネルを介して利用できるアクションは、アイコンをクリック−ドラッグして、関連したコマンド・パネルを引き出す（プルアウトする）ことができる能力を含んでいる。コマンド・パネルは、コマンド・パネル・バーから除去し、デスクトップ上に配置することもできる。コマンド・パネル・アイコンを１回クリックすることによって通常はフレーム生成ツールであるデフォルト・ツールを選択する。選択ツール・コマンド・パネルの場合には、デフォルト・ツールは矢印選択ツールである。図４は好適実施例によるコマンド・パネル・バーの１例を示している。
【００３５】
コマンド・パネル・コンテナ(Command Panel Container)
ユーザがコマンド・パネルをインストールする場合、コマンド・パネルはワーク・スペース内のグローバル・コマンド・パネル・コンテナに集められる。ユーザは、このコンテナ内のパネルに常にアクセスでき、すなわち種々のコマンド・パネル・バーにそれらコマンド・パネルを位置させることができる。図５は好適実施例によるコマンド・パネルの１例を示している。
【００３６】
現在のツール対アクティブなツール
ユーザはツール・クラスタ内から現在のカーソル・ツールを選択することで現在のカーソル・ツールをセットする。図６は好適実施例によるツール・クラスタを示す図である。現在のツールは、ツールが機能し得るスクリーン領域上をユーザがカーソルを移動させる時のみ、活性化される。カーソルが現在のツールに対して不適当である領域内にあるときには、いつでも、アクティブなツールは選択ツールに戻り、そしてカーソルの形は矢印に戻る。
【００３７】
アクティブ領域
アクティブ領域はアクティブなドキュメント(Active document) 内にだけある。アクティブなドキュメント・ファニチュア(furniture) を含むアクティブなドキュメントの外側のどこでも、アクティブなツール(active tool) は選択矢印になる。アクティブなドキュメント内では、アクティブ領域は現在のツールおよびカーソルの下でのフレームのタイプに依存する。クリック・スルー(click- through)のために、フレームがアクティブか否かは重要ではない。上述した如く、カーソル・ツールは３つのカテゴリー：クリエータ、セレクタ、およびセレクタ／エフェクタになっている。
・クリエータは新データ、すなわち円形ドローイング・ツールを生成する。
・セレクタは既存のデータ、すなわちPhotoshop のMagic Wandを選択する。
・セレクタ／エフェクタはデータ、すなわちMacPaintの消去ツールを選択し、かつ変える。
【００３８】
クリエータ・カーソル・ツールは組込むことができる全てのフレーム上でアクティブである。もしユーザが円形データ・タイプなしにフレーム上で円形を描く場合には、ツール・フレームワーク(Tool Framework)は、円形を理解する新たなフレームを生成し、その円形をその新たなフレーム内に配置し、そしてその新たなフレームを既存フレームに組込む。この明瞭なフレーム生成は、ユーザが必要とするところで、必要とする時に、まず適切なフレームを生成する必要なしに、ユーザがデータを生成することを可能にする。セレクタおよびセレクタ／エフェクタ・カーソル・ツールは、それらが理解できるタイプのフレーム上でだけアクティブである。例えば、MacPaint消去ツールはMacPaintフレーム上でだけアクティブである。上述の全ての他のフレーム上で、アクティブなツールは選択矢印になる。
【００３９】
図７は好適実施例による種々のタイプのフレームの幾つかの例を示している。アクティブなフレーム(Active frame)７００、アクティブでないフレーム(Inactive frame)７２０、PinkDrawフレーム７１０、テキスト・フレーム(Text Frame)７４０の各々は顕著な特徴を有している。図８は好適実施例による種々のフレームを有するデスクトップを示している。この図では、ユーザは２つのドキュメントをオープンにしていて、その１つがアクティブ８００であり、他方が非アクティブ８１０である。両ドキュメントは２のフレーム、１つのPinkDrawフレームと１つのテキスト・フレームとを有している。ユーザはPinkDrawのコマンド・パネル８３０からツールを選択している。図９は好適実施例によるレクタングル（矩形）・カーソル・ツールおよびクリエータのユーザ選択を示している。アクティブなドキュメントのコンテント領域（ルートフレーム(root-frame)）の外側では、アクティブなツールは選択矢印である。図１０は好適実施例による選択矢印を示している。図１１は好適実施例によるアクティブなツールになるカーソル矩形ツールを示している。図１２は好適実施例により、非アクティブなドキュメントを通過して、アクティブなツールになる選択矢印を示している。
【００４０】
図１３は好適実施例によるスマッジ・ツール(smudge tool) 、セレクタ／エフェクタ用の選択プロセスを示している。図１４は好適実施例により、カーソルが特定のフレームを通過するときのみスマッジ・ツールをイネーブルにすることを示す。図１５および図１６は好適実施例により、ツール・カーソルがコンテント領域を通過する際のツール・カーソルの動きを示す図である。カーソルがアクティブなドキュメントのコンテント領域および他のPinkDrawではないフレームのコンテント領域を通過する際に、アクティブなツールは選択ツールになる。
【００４１】
コマンド・パネルのアクセス(accessing) ／検索
コマンド・パネルをアクセスするのに複数の方法がある。ユーザはアイコンをダブルクリックすることでグローバル・パネル・コンテナまたは任意の他のワーク・スペース・コンテナ内からパネルをオープンすることができる。パネル・バー上に配置されているいかなるパネルに対しても、ユーザは単にパネルのアイコンを選択して検索することができる。ユーザがフレームを選択する場合には、ユーザは「Show command panel」コマンドを発生することができ、そしてワーク・スペースが現在のフレームのタイプに対するディフォルト・コマンド・パネルをオープンする。従って、もしPinkDrawフレームを選択し、「Show command panel 」を選ぶと、ワーク・スペースはPinkDrawコマンド・パネルをオープンする。
【００４２】
フレーム・タイプごとの複数のコマンド・パネル
いくつかのドキュメントのタイプはいくつかのアプリケーションによってオープンすることができる。例えば、Painter 、MacPaint、Photoshop 、MacDraw 、およびTeachText は、すべて、ＰＩＣＴファイルをオープンすることができる。好適実施例によれば、イメージおよびテキストなどのあるフレームのタイプは多くの異なるコマンド・パネルを有する。特定のフレームで作業中に全ての可能なコマンド・パネルの中から選ぶためには、フレームの特性シートによって、ユーザがコマンド・パネルを選択し、および特定のフレームのタイプに対するディフォルト・コマンド・パネルをセットすることさえもできる。「Show command panel 」コマンドはディフォルト・コマンド・パネルをオープンする。
【００４３】
フレームおよびウィンドウの活性化
ウィンドウおよびフレームが如何に活性化されるかを理解することは重要である。その理由は、選択矢印以外のツールがアクティブなウィンドウ内でのみアクティブであるからである。活性化を論じる場合には、考慮しなければならない２つの問題点がある。第一に、ウィンドウまたはフレームはいつ活性化されるのか？第二に、非アクティブなフレームまたはウィンドウへの最初のクリックが如何にデータに作用するか？
【００４４】
フレーム
フレームはマウス・ダウンして活性化しなければならない、その理由は、それらの活性化フィードバックはユーザが開始しているアクションにとって重要かもしれないからである。例えば、もしユーザが矩形カーソル・ツールでフレームをクリック・ダウンすると、フレームは、矩形がクリップされる場所をユーザが知ることができるようにその境界を示すように活性化しなければならない。非アクティブなフレーム内での最初のクリックによって活性化させるのみならず、クリック・スルー効果のために、フレームのコンテンツは、フレームがすでにアクティブであったかのようにふるまう。従って、もし消去カーソル・ツールが選択され、そして非アクティブなフレームを横切ってドローするように用いられると、検出された最初のクリックによって幾つかのデータを消去する。
【００４５】
ウィンドウ
マウス・アップ・イベントがウィンドウの境界内で起こる時にウィンドウは活性化される。マウス・アップは、ウィンドウの境界内でのクリックの後またはユーザがオブジェクトをウィンドウ内にドラッグしている時にマウスボタンを離す際に行われ得る。ウィンドウはマウス・アップまで活性化されないので、アクティブなツールはドラッグしている間は常に選択矢印になる。現在のツールが選択矢印以外の何かである場合には、ドラッグが完了してターゲット・ウィンドウが活性化した後においてのみ活性化される。非アクティブなウィンドウ内の最初のクリックは、オブジェクトを選択またはドラッグする以外に、ウィンドウの内容に影響することはできない。最初のクリックは、ダメージを与えることは何もしないので、ユーザがセレクタ／エフェクタ・ツールをスクリーンを横切ってスワィプ(swipe) することによってデータを偶発的に破壊することはできないようにすることが重要である。しかし、最初のクリックでデータを選択し、およびドラッグすることにより、ドラッグ−アンド−ドロップの動作は促進される。ウィンドウはマウス・アップまで活性化されないので、非アクティブなウィンドウをフロント部に移すことなしにオブジェクトは非アクティブなウィンドウから選択され、そしてアクティブなウィンドウにドラッグされることができる。図１７は好適実施例によるウィンドウおよびフレーム処理を要約している。
【００４６】
ツール・アーキテクチャの概説
ツール・システムは、フレームおよびドキュメントを横切って用い得るカーソル・ツールを開発する構造を提供し、および（ツール・パレットのような）ツール選択コントロールからユーザのデータに作用することができるフレームへツールを転送する必要なシステム・サービスを提供する。TTool クラスはツール選択コントロールからツールを転送するシステム・サービスを提供する。TTool はTToolInteractor 、カーソル・グラフィック、パレット・グラフィック、テキスト・ネーム、およびタイプ・ネゴシエーション情報を含む単純なクラスである。TToolInteractor は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を要求する。すなわち、ツールが選択を理解すると、ネゴシエータはToolInteractorをビューに返す。そのビューは適切な値をToolInteractorにセットし、相互作用を開始する。この時点において、インタアクタ(interactor)が引き継いでユーザ相互作用の実行を進める。
【００５３】
フロー・ダイアグラム
図１８は好適実施例によるツール処理の論理を示すフロー・ダイアグラムである。処理は、ツール・パレット１８４０が特定のツールの選択を検出した１８００のところにおいて開始する。１８００において、SetCurrentToolCmdコマンド・オブジェクトのDo()メソッドがコールされ、特定ツールが活性化される。Do()メソッドがコールされたとき、Do()メソッドはツール・サーバ１８１０のSetCurrentTool()メソッドをコールし、カーソル・ツールおよび現在のツールに関連付けられたカーソルをパスする。その後、フレーム１８２０が入力または活性化されたとき、フレーム１８２０を表示するビュー・オブジェクトは、ツール・サーバ１８１０のGetToolNegotiator()メソッドをコールすることにより、ツール・サーバ１８１０からのツール・ネゴシエータ１８３０を要求する。ツール・サーバ１８１０はツール・ネゴシエータ１８３０を返す。次いで、ビュー・オブジェクトは、ツール・ネゴシエータ１８３０のSetCursorShape()メソッドをコールすることにより、メソッド・ツール・ネゴシエータ１８３０がカーソルの形を現在のカーソル・ツールのカーソル・グラフィックに変更するよう要求する。ビュー・オブジェクトはまた、ツール・ネゴシエータ１８３０のGetInteractor()メソッドをコールすることにより、ツール・ネゴシエータ１８３０からのインタラクタを要求する。ツール・ネゴシエータ１８３０は、フレーム・データ・タイプをその内部のデータ・タイプのリストと比較することにより、現在のカーソル・ツールがそのフレーム・データ上で動作できるかどうかを判断する。現在のカーソル・ツールがそのフレーム・データ・タイプで動作できる場合、ツール・ネゴシエータ１８３０はカーソルを現在のカーソル・グラフィックに変更し、ディスプレイを更新する。ツール・ネゴシエータはまたツール・インタラクタを返す。インタラクタは、フレーム・データ上でカーソル・オペレーションを実行するために使用される。
【００５４】
TAbstractTool
図１９は好適実施例によるクラス階層を示すブロック図である。ここで特に関心のあることは、ツールのI.D.を得るTGlobalID GetID() const;およびツールのI.D.をセットするvirtual void SetID(TGlobalID);である。カーソル・ツールのフレームワークはツールのグローバルI.D.を用いてToolServer内でそのグローバルI.D.を一意的に識別し、および適切なツールに変更された旨の通知をツール・セッティング・コマンドに供給する。
【００５５】
TTool
TTool はツールを定義する抽象的なスーパークラスである。TTool また
ToolServerと交信する幾つかの静的メソッドをも有している。TTool のサブクラスは実際にはほとんど作業をしない。それらのサブクラスは、メニューおよびツール・パレットに対するグラフィックスおよびテキスト・ネーム、アクティブな時にツールを表すカーソル・グラフィック、ツールが有効である選択タイプのリストを提供し、そして、それらはユーザが選択されたツールを有する有効なフレームにおいてマウス・ダウンする時に活性化されるインタアクタ(interactor)のサブクラスを作成する。フレームにおいてデータを生成または変更する実際の作業を実行するオブジェクトはインタアクタである。
【００５６】
純粋仮想メソッド(Pure Virtual Methods)
virtual MGraphic* CreatePaletteGraphic() const=0;
サブクラスは、ツール・パレットまたはメニュー上で用いるべき新たな
MGraphicを返さなければならない。
【００５７】
virtual void GetPaletteText(TText&) const=0;
サブクラスは、TText のテキストをツールを表すメニュー・アイテムに適しているストリングにセットしなければならない。
【００５８】
virtual MGraphic* CreateCursorGraphic() const=0;
サブクラスは、ツールがアクティブな時にカーソルとして用いるべき新たな MGraphicを返さなければならない。
【００５９】
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 および
TTextSelection::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 がいかなる TAbstractTool にもセットできるように定義されたオペレータ（演算子）である。
【００７３】
TSelectionArrow
以下の属性を有する単純なTTool サブクラス。
Palette Graphic(パレット・グラフィック）：標準ピンク矢印
Cursor Graphic（カーソル・グラフィック）：標準ピンク矢印
Palette Text（パレット・テキスト）：「矢印」
Type Info:TModelSelection::kType。矢印はいずれのフレームにおいても有効である。
Tool Interactor(ツール・インタアクタ）：なし。選択矢印はそのインタアクタに対してNIL を返す。クリック−インしたフレームはそれ自体の選択インタアクタを提供しなければならない。
【００７４】
TToolNegotiator
TToolNegotiatorsは受取りチームにおける現在のツールを表す軽量の一定の構造形態をもつ(monomorphic) オブジェクトである。例えば、カーソルがアクティブなドキュメントにおけるフレームを通過する時、そのフレームはTToolNegotiator を通過する。フレームがTToolNegotiator とネゴシエートして、カーソルの形を変えるかどうかをネゴシエータに知らせる。１回のマウス・ダウンでフレームもTToolNegotiator を得て、現在のツールがフレーム内で有効であるかどうかを知るためにネゴシエーションする。もしそうならば、フレームはTToolNegotiator から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
ドロー・プログラム・スタイルの十字線(Cross hair)
【００９２】
【００９３】
TExGraphic
デバッグするのに用いられるビッグピンク(big pink) X
【００９４】
【００９５】
TArrowGraphic
矢印
【００９６】
【００９７】
ユーティリティ・クラス
TToolInstanceInterest
このインタレストはTAbstractTool で構成される。それは現在のツールになるTAbstractTool の特別の瞬時でのインタレストを表現する。図２３は好適実施例によるユーティリティ・クラスを示す。
【００９８】
TToolInstanceInterest(const TAbstractTool&, MNotifier*,
const TToken&);
TToolChangedNotification
ToolServerは、現在のツールが変わる度毎にTToolChangedNotificationを伝える、すなわちスロー(throw) する。通知は新たな現在のツールに対するTToolSurrogateおよびそのクラスのネームを保持している。
通知からデータを抽出するメソッド
TToolSurrogate GetToolSurrogate() const;
TToken GetToolType() const;
TCursorToolException
Cursor Tool のフレームワークによりスローされた例外サブクラス。
TCursorToolException により定義されたエラー
kNoBoundCursor = 0x1D02
【００９９】
制限のないカーソルを有するTSetCurrentToolCmd::Do()called。この例外は現在では用いられていない。カーソル・サーバが複数のカーソルを支持する時にスローされる。その時に、プログラマはそれを生じる前にツールとカーソルの双方をコマンドに結合することが必要となる。
【０１００】
kNoBoundToolInCommand = 0x1D02
コマンドが制限ツールを持たない時に、制限ツールを必要とする
TSetCurrentToolCmd上のメソッドをコールしようとする時にスローされる。
kNoBoundToolInServer = 0x1D03
【０１０１】
現在のツールがセットされる前に、カレントツールを必要とするTToolServer 上のメソッドをコールしようとする時にスローされる。
【０１０２】
本発明を特定のシステム環境における好適実施例に基づいて述べてきたが、本発明は、以下の特許請求の範囲精神および範囲内において、他のおよび異なるハードウェアおよびソフトウェア環境の下での変更例を以て実施することができることを当業者は認識するであろう。
【図面の簡単な説明】
【０１０３】
【図１】好適実施例によるパーソナル・コンピュータ・システムを示すブロック図である。
【図２】MacDraw で使用される従来技術のカーソル・ツール・クラスタの例を示す図である。
【図３】好適実施例によるコマンド・パネルを示す図である。
【図４】好適実施例によるコマンド・パネル・バーの例を示す図である。
【図５】好適実施例によるコマンド・パネルの例を示す図である。
【図６】好適実施例によるツール・クラスタの例を示す図である。
【図７】好適実施例による各種の形態のフレームの幾つかの例を示す図である。
【図８】好適実施例による各種のフレームをもつデスクトップを示す図である。
【図９】好適実施例によるレクタングル（矩形）カーソル・ツール、クリエータのユーザ選択を示す図である。
【図１０】好適実施例による選択矢印（アロー）を示す図である。
【図１１】好適実施例によりアクティブなツールになるカーソル・レクタングル・ツールを示す図である。
【図１２】好適実施例により、非アクティブなドキュメントを通り越して、アクティブなツールになる選択矢印を示す図である。
【図１３】好適実施例によるスマッジなツール(smudge tool) 、セレクタ (selector)／エフェクタ(effector)用の選択プロセスを示す図である。
【図１４】好適実施例により、カーソルが特定のフレームを通り越すときのみだけスマッジ・ツールを動作可能（イネーブル）にすることを示す図である。
【図１５】好適実施例により、ツール・カーソルが内容領域を通り過ぎる際のツール・カーソルの動作を示す図である。
【図１６】好適実施例により、ツール・カーソルが内容領域を通り過ぎる際のツール・カーソルの動作を示す図である。
【図１７】好適実施例によるウィンドウおよびフレーム処理をまとめて示す図である。
【図１８】好適実施例によるツール処理の論理を示す流れ図である。
【図１９】好適実施例によるクラス階層(hierarchy）を示す図である。
【図２０】好適実施例によるTToolServer クラスを示す図である。
【図２１】好適実施例によるコマンド・クラスを示す図である。
【図２２】好適実施例による予め組み込まれたジオメトリー（幾何学的配置）の幾つかを示す図である。
【図２３】好適実施例によるユーティリティ・クラスを示す図である。
【技術分野】
【０００１】
本発明は、一般的にはコンピュータ・システムにおける改良に関し、特にオブジェクト指向オペレーティング・システムにおけるツール・オブジェクトおよびツール・オブジェクトのメニューを用いるシステムおよび方法に関する。
【背景技術】
【０００２】
著作権表記
本明細書の一部には、著作権保護の対象となる内容が含まれている。著作権所有者は、米国特許商標庁の特許ファイルまたは記録に記述されている特許文書または特許開示事項を誰かがそのまま複製することに異論を唱えないが、その他の場合には著作権に係わる一切の権利を留保する。
【０００３】
発明の背景
カーソル・ツールは、ユーザ制御される「カーソル」のふるまいを変えることでユーザのドキュメントまたはフレームとの相互作用の特定のモードを特定する。例えば、ユーザは「レクタングル（矩形）」カーソル・ツールを選択して、マウスボタンを押しながらマウスをドラッグすることで、ドキュメント・ドローイング（描画）キャンバス上にレクタングルを生成することをオペレーティング環境に指示することができる。ツールはデータの選択、操作および生成用のモードを指示することができる。カーソル・ツールの従来技術例はMacPaint（登録商標）またはMacDraw(登録商標）のようなアプリケーションにおいて見受けられる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、これらのアプリケーションは一度に２つ以上のカーソルの管理をユーザに提供しなかった。さらに、オペレーティング・システムへの統合を行って、１つのアプリケーションにおいてアクティブなツールを他のアプリケーションでも機能させることができるようにすることはなされていなかった。カーソル・ツールとアプリケーションとの間のネゴシエーションの能力も従来技術では知られてはいなかった。
【課題を解決するための手段】
【０００５】
本発明の革新的システムおよび方法ではオブジェクト指向技術を用いて、複数のカーソル・ツールを一つのオブジェクト指向オペレーティング・システムに統合する。この統合は複数のタスクでの複数のカーソル・ツールを同時に管理することを含んでいる。ネゴシエーション能力を設けて、任意のカーソル・ツールと任意のアプリケーションとを共に機能させることができるようにする。この独自の能力は区画を越えてのメモリ管理を含み、それによりアプリケーションおよび区分を越えてカーソル・ツールを使用することを可能にしている。オブジェクト指向のフレームワークによりカーソル・ツールをアプリケーションを越えて分配するためのアーキテクチャを提供するので、そのためカーソル・ツール機能が必要になるまではアプリケーション要求はツールについて知らない。技術用語では、これは、カーソル・ツールがアプリケーションの情報をうまく変更できることが決定された後までは、どんなアプリケーションでもカーソル・ツールの共有ライブラリにおいてマッピングすることなしにカーソル・ツールを使用することができることを意味する。
【発明を実施するための最良の形態】
【０００６】
本発明はＩＢＭ（登録商標）社のＰＳ／２（登録商標）またはアップル（登録商標）社のマッキントッシュ（登録商標）コンピュータのようなパーソナル・コンピュータに常駐するオペレーティング・システムの下で実行されるのが好ましい。代表的なハードウェア環境は図１に示され、図１は、組み込みの不揮発性記憶装置１１を有する慣例のマイクロプロセッサのような中央処理装置１０およびシステム・バス１２を介して相互接続された多数の他のユニットを有する本発明によるコンピュータの代表的なハードウェア構成を示す。図１に示されるワークステーションは、ランダム・アクセス・メモリ（ＲＡＭ）１４、リード・オンリ・メモリ（ＲＯＭ）１６、ディスク・ユニット２０およびディスケット・ユニット２１のような周辺装置をバスに接続する入出力アダプタ１８、キーボード２４、マウス２６、スピーカ２８、マイクロホン３２、および／またはタッチ・スクリーン装置（図示せず）などのような他のユーザ・インタフェース装置をバスに接続するユーザ・インタフェース・アダプタ２２、このワークステーションをデータ処理ネットワーク２３に接続する通信アダプタ３４、およびバスをディスプレイ装置３８に接続するディスプレイ・アダプタ３６を含んでいる。このコンピュータには、Apple System/7（登録商標）オペレーティング・システムのようなオペレーティング・システムを搭載してある。
【０００７】
オブジェクト指向プログラミング技術
好適実施例では、本発明はオブジェクト指向プログラミング技術を用いてＣ++プログラミング言語で実現されている。当業者によって理解されるように、オブジェクト指向プログラミング（ＯＯＰ）のオブジェクトは、データ構造およびデータに対するオペレーションを含むソフトウェア・エンティティである。これらのエレメントが一緒になって、オブジェクトが、そのデータ・エレメントで表現されたその特性、およびそのデータ操作関数で表現されたそのふるまいないし作用(Behavior)の形態でいかなる実世界のエンティティをも仮想的にモデル化することができる。このようにして、オブジェクトは、人々やコンピュータのような具体物をモデル化することができ、かつ、数や幾何学的概念のような抽象的概念をモデル化することができる。オブジェクト技術の利点は次の３つの基本的原理から得られるものである。それは、カプセル化(encapsulation）、多態(polymorphism)、および継承(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内で選択した最終ツールになるであろう。好適実施例では、ツールはある場所に持続するが、場所を越えて持続することはない。例えば、もしレクタングル（矩形）カーソル・ツールが１つのアプリケーションにおいて選択される場合には、たとえ如何なるフレームまたはドキュメントがアクティブにされたにしても、そのカーソル・ツールは選択されたカーソル・ツールのままである。
【００２２】
カーソル・ツールの例
・ 多角形カーソル・ツール：
【００２３】
【００２４】
・ 矢印選択カーソル・ツール：
【００２５】
【００２６】
・ カラー・グラバー(color-grabber)(「アイ・ドロッパー(eye-dropper)」) カーソル・ツール：
【００２７】
【００２８】
カーソル・ツール・クラスター(Cursor Tool Cluster)
クラスターは関連したカーソル・ツールを論理的および可視的にグループ化する手段である。クラスターは種々のカーソル・ツールを保持するビュー(view)と考えることができる。ツール・クラスターはそれら自体がパネルではなく、開発者はクラスターをパネル上で使用することかできる。図２はMacDraw で用いられる従来技術のカーソル・ツール・クラスターの１例である。
【００２９】
コマンド・パネル(Command Panels)
コマンド・パネルはフレーム・ファニチュア上またはフレームのメニューに直接には現われないフレームのコマンドの全てをグループ化しかつ組織化するものである。コマンド・パネルは、（ひとまとめにされたまたはされていない）カーソル・ツール、ボタン、スライダー、プルダウン・メニュー、スクロール・リスト、テキスト・フィールド、追加パネル、または開発者が生成することができるいかなるカスタム・コントロールを介してこれらのコマンドにインタフェースを提供する。全てのコマンド・パネルはフレーム作成ツール、即ちパネルによって表されるタイプのフレームをドローするのに使用することができるカーソル・ツールを含んでいなければならない。
【００３０】
コマンド・パネルとそのフレームとの間の関係はアプリケーションとそのドキュメントとの間の関係に類似している。コマンド・パネルはそのフレームを生成するのに使用され得、そしてそのフレームおよびそのコンテントを操作 (manipulate)するためのインタフェースの大部分を保持している。しかし、大きな相違がある。従来技術のツール・システムでは、アプリケーションはそのドキュメントを所有していて、それらのドキュメントを文字通り取り囲んでいる (surrounding) 。好適実施例では、ドキュメントは最高位にある。そのドキュメントはフレームを所有し、かつ取り囲み、コマンド・パネルはユーザが用いることができる単なるツールであり、それを使用してドキュメント内にフレームを生成したり、または操作を行う。
【００３１】
このモデルでは、アプリケーションは単にコマンド・パネルおよび静的(stationery)パッドであり、特別なタイプのフレームに対するコマンドへのインタフェースを提供し、かつそのタイプのフレームに対するフレーム生成カーソル・ツールを提供するよう設計されている。コマンド・パネルは、単一フレーム・タイプに作用する制御を一緒にしてグループし、そしてベンダ(vendor)はしばしばそれらのフレーム・タイプの各々に対するコマンド・パネルを生成し、その結果、コマンド・パネルはベンダによる制御をグループ化するようになるかもしれない。例えば、WordPerfect はそれらのWordPerfect フレーム・タイプに対するWordPerfect コマンド・パネルを開発することになるだろう。グラフ・エディット・アプリケーションのような共通フレーム・タイプに対しては、幾つかの異なるコマンド・パネルがあり得る。コマンド・パネルは結局はユーザが構成可能なものであるから、ユーザがどのベンダを選択しようとも、そのベンダからそれらユーザのイメージ操作制御の全てを単一のコマンド・パネル上にグループ化することができた。
【００３２】
コマンドはグローバル・コマンド・パネル・コンテナまたはコマンド・パネル・バーを介してアクセスすることができる。アクティブなフレームに対するコマンド・パネルは制御キー・プレスのような複数キーのシーケンスを有するフロント部に置くことができる。図３は好適実施例によるコマンド・パネルである。
【００３３】
コマンド・パネル・バーは、ユーザがインストールしたかもしれない種々のコマンド・パネルを表わすアイコンを含んでいる。さらに加えて、バーの上部の２つのアイコンは特別である。最も上部のアイコンは常にアクティブなフレームに対するコマンド・パネルを表わし、そして第２のアイコンはいかなるフレーム・タイプにも包括的に適用できるツールの集まりを有するコマンド・パネルを常に含んでいる。それらアイコンは選択矢印、オプションの拡大器(optional magnifier)およびカラー・グラバー(color-grabber) を含んでいる。コマンド・パネル・バーが、ドキュメント内またはデスクトップ上のフレームのコマンド・パネルの全てで占められることを示唆した初期の設計と異なって、この設計では、ユーザはどのパネルが利用できるかを決定する。
【００３４】
ユーザがコマンド・パネルを介して利用できるアクションは、アイコンをクリック−ドラッグして、関連したコマンド・パネルを引き出す（プルアウトする）ことができる能力を含んでいる。コマンド・パネルは、コマンド・パネル・バーから除去し、デスクトップ上に配置することもできる。コマンド・パネル・アイコンを１回クリックすることによって通常はフレーム生成ツールであるデフォルト・ツールを選択する。選択ツール・コマンド・パネルの場合には、デフォルト・ツールは矢印選択ツールである。図４は好適実施例によるコマンド・パネル・バーの１例を示している。
【００３５】
コマンド・パネル・コンテナ(Command Panel Container)
ユーザがコマンド・パネルをインストールする場合、コマンド・パネルはワーク・スペース内のグローバル・コマンド・パネル・コンテナに集められる。ユーザは、このコンテナ内のパネルに常にアクセスでき、すなわち種々のコマンド・パネル・バーにそれらコマンド・パネルを位置させることができる。図５は好適実施例によるコマンド・パネルの１例を示している。
【００３６】
現在のツール対アクティブなツール
ユーザはツール・クラスタ内から現在のカーソル・ツールを選択することで現在のカーソル・ツールをセットする。図６は好適実施例によるツール・クラスタを示す図である。現在のツールは、ツールが機能し得るスクリーン領域上をユーザがカーソルを移動させる時のみ、活性化される。カーソルが現在のツールに対して不適当である領域内にあるときには、いつでも、アクティブなツールは選択ツールに戻り、そしてカーソルの形は矢印に戻る。
【００３７】
アクティブ領域
アクティブ領域はアクティブなドキュメント(Active document) 内にだけある。アクティブなドキュメント・ファニチュア(furniture) を含むアクティブなドキュメントの外側のどこでも、アクティブなツール(active tool) は選択矢印になる。アクティブなドキュメント内では、アクティブ領域は現在のツールおよびカーソルの下でのフレームのタイプに依存する。クリック・スルー(click- through)のために、フレームがアクティブか否かは重要ではない。上述した如く、カーソル・ツールは３つのカテゴリー：クリエータ、セレクタ、およびセレクタ／エフェクタになっている。
・クリエータは新データ、すなわち円形ドローイング・ツールを生成する。
・セレクタは既存のデータ、すなわちPhotoshop のMagic Wandを選択する。
・セレクタ／エフェクタはデータ、すなわちMacPaintの消去ツールを選択し、かつ変える。
【００３８】
クリエータ・カーソル・ツールは組込むことができる全てのフレーム上でアクティブである。もしユーザが円形データ・タイプなしにフレーム上で円形を描く場合には、ツール・フレームワーク(Tool Framework)は、円形を理解する新たなフレームを生成し、その円形をその新たなフレーム内に配置し、そしてその新たなフレームを既存フレームに組込む。この明瞭なフレーム生成は、ユーザが必要とするところで、必要とする時に、まず適切なフレームを生成する必要なしに、ユーザがデータを生成することを可能にする。セレクタおよびセレクタ／エフェクタ・カーソル・ツールは、それらが理解できるタイプのフレーム上でだけアクティブである。例えば、MacPaint消去ツールはMacPaintフレーム上でだけアクティブである。上述の全ての他のフレーム上で、アクティブなツールは選択矢印になる。
【００３９】
図７は好適実施例による種々のタイプのフレームの幾つかの例を示している。アクティブなフレーム(Active frame)７００、アクティブでないフレーム(Inactive frame)７２０、PinkDrawフレーム７１０、テキスト・フレーム(Text Frame)７４０の各々は顕著な特徴を有している。図８は好適実施例による種々のフレームを有するデスクトップを示している。この図では、ユーザは２つのドキュメントをオープンにしていて、その１つがアクティブ８００であり、他方が非アクティブ８１０である。両ドキュメントは２のフレーム、１つのPinkDrawフレームと１つのテキスト・フレームとを有している。ユーザはPinkDrawのコマンド・パネル８３０からツールを選択している。図９は好適実施例によるレクタングル（矩形）・カーソル・ツールおよびクリエータのユーザ選択を示している。アクティブなドキュメントのコンテント領域（ルートフレーム(root-frame)）の外側では、アクティブなツールは選択矢印である。図１０は好適実施例による選択矢印を示している。図１１は好適実施例によるアクティブなツールになるカーソル矩形ツールを示している。図１２は好適実施例により、非アクティブなドキュメントを通過して、アクティブなツールになる選択矢印を示している。
【００４０】
図１３は好適実施例によるスマッジ・ツール(smudge tool) 、セレクタ／エフェクタ用の選択プロセスを示している。図１４は好適実施例により、カーソルが特定のフレームを通過するときのみスマッジ・ツールをイネーブルにすることを示す。図１５および図１６は好適実施例により、ツール・カーソルがコンテント領域を通過する際のツール・カーソルの動きを示す図である。カーソルがアクティブなドキュメントのコンテント領域および他のPinkDrawではないフレームのコンテント領域を通過する際に、アクティブなツールは選択ツールになる。
【００４１】
コマンド・パネルのアクセス(accessing) ／検索
コマンド・パネルをアクセスするのに複数の方法がある。ユーザはアイコンをダブルクリックすることでグローバル・パネル・コンテナまたは任意の他のワーク・スペース・コンテナ内からパネルをオープンすることができる。パネル・バー上に配置されているいかなるパネルに対しても、ユーザは単にパネルのアイコンを選択して検索することができる。ユーザがフレームを選択する場合には、ユーザは「Show command panel」コマンドを発生することができ、そしてワーク・スペースが現在のフレームのタイプに対するディフォルト・コマンド・パネルをオープンする。従って、もしPinkDrawフレームを選択し、「Show command panel 」を選ぶと、ワーク・スペースはPinkDrawコマンド・パネルをオープンする。
【００４２】
フレーム・タイプごとの複数のコマンド・パネル
いくつかのドキュメントのタイプはいくつかのアプリケーションによってオープンすることができる。例えば、Painter 、MacPaint、Photoshop 、MacDraw 、およびTeachText は、すべて、ＰＩＣＴファイルをオープンすることができる。好適実施例によれば、イメージおよびテキストなどのあるフレームのタイプは多くの異なるコマンド・パネルを有する。特定のフレームで作業中に全ての可能なコマンド・パネルの中から選ぶためには、フレームの特性シートによって、ユーザがコマンド・パネルを選択し、および特定のフレームのタイプに対するディフォルト・コマンド・パネルをセットすることさえもできる。「Show command panel 」コマンドはディフォルト・コマンド・パネルをオープンする。
【００４３】
フレームおよびウィンドウの活性化
ウィンドウおよびフレームが如何に活性化されるかを理解することは重要である。その理由は、選択矢印以外のツールがアクティブなウィンドウ内でのみアクティブであるからである。活性化を論じる場合には、考慮しなければならない２つの問題点がある。第一に、ウィンドウまたはフレームはいつ活性化されるのか？第二に、非アクティブなフレームまたはウィンドウへの最初のクリックが如何にデータに作用するか？
【００４４】
フレーム
フレームはマウス・ダウンして活性化しなければならない、その理由は、それらの活性化フィードバックはユーザが開始しているアクションにとって重要かもしれないからである。例えば、もしユーザが矩形カーソル・ツールでフレームをクリック・ダウンすると、フレームは、矩形がクリップされる場所をユーザが知ることができるようにその境界を示すように活性化しなければならない。非アクティブなフレーム内での最初のクリックによって活性化させるのみならず、クリック・スルー効果のために、フレームのコンテンツは、フレームがすでにアクティブであったかのようにふるまう。従って、もし消去カーソル・ツールが選択され、そして非アクティブなフレームを横切ってドローするように用いられると、検出された最初のクリックによって幾つかのデータを消去する。
【００４５】
ウィンドウ
マウス・アップ・イベントがウィンドウの境界内で起こる時にウィンドウは活性化される。マウス・アップは、ウィンドウの境界内でのクリックの後またはユーザがオブジェクトをウィンドウ内にドラッグしている時にマウスボタンを離す際に行われ得る。ウィンドウはマウス・アップまで活性化されないので、アクティブなツールはドラッグしている間は常に選択矢印になる。現在のツールが選択矢印以外の何かである場合には、ドラッグが完了してターゲット・ウィンドウが活性化した後においてのみ活性化される。非アクティブなウィンドウ内の最初のクリックは、オブジェクトを選択またはドラッグする以外に、ウィンドウの内容に影響することはできない。最初のクリックは、ダメージを与えることは何もしないので、ユーザがセレクタ／エフェクタ・ツールをスクリーンを横切ってスワィプ(swipe) することによってデータを偶発的に破壊することはできないようにすることが重要である。しかし、最初のクリックでデータを選択し、およびドラッグすることにより、ドラッグ−アンド−ドロップの動作は促進される。ウィンドウはマウス・アップまで活性化されないので、非アクティブなウィンドウをフロント部に移すことなしにオブジェクトは非アクティブなウィンドウから選択され、そしてアクティブなウィンドウにドラッグされることができる。図１７は好適実施例によるウィンドウおよびフレーム処理を要約している。
【００４６】
ツール・アーキテクチャの概説
ツール・システムは、フレームおよびドキュメントを横切って用い得るカーソル・ツールを開発する構造を提供し、および（ツール・パレットのような）ツール選択コントロールからユーザのデータに作用することができるフレームへツールを転送する必要なシステム・サービスを提供する。TTool クラスはツール選択コントロールからツールを転送するシステム・サービスを提供する。TTool はTToolInteractor 、カーソル・グラフィック、パレット・グラフィック、テキスト・ネーム、およびタイプ・ネゴシエーション情報を含む単純なクラスである。TToolInteractor は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を要求する。すなわち、ツールが選択を理解すると、ネゴシエータはToolInteractorをビューに返す。そのビューは適切な値をToolInteractorにセットし、相互作用を開始する。この時点において、インタアクタ(interactor)が引き継いでユーザ相互作用の実行を進める。
【００５３】
フロー・ダイアグラム
図１８は好適実施例によるツール処理の論理を示すフロー・ダイアグラムである。処理は、ツール・パレット１８４０が特定のツールの選択を検出した１８００のところにおいて開始する。１８００において、SetCurrentToolCmdコマンド・オブジェクトのDo()メソッドがコールされ、特定ツールが活性化される。Do()メソッドがコールされたとき、Do()メソッドはツール・サーバ１８１０のSetCurrentTool()メソッドをコールし、カーソル・ツールおよび現在のツールに関連付けられたカーソルをパスする。その後、フレーム１８２０が入力または活性化されたとき、フレーム１８２０を表示するビュー・オブジェクトは、ツール・サーバ１８１０のGetToolNegotiator()メソッドをコールすることにより、ツール・サーバ１８１０からのツール・ネゴシエータ１８３０を要求する。ツール・サーバ１８１０はツール・ネゴシエータ１８３０を返す。次いで、ビュー・オブジェクトは、ツール・ネゴシエータ１８３０のSetCursorShape()メソッドをコールすることにより、メソッド・ツール・ネゴシエータ１８３０がカーソルの形を現在のカーソル・ツールのカーソル・グラフィックに変更するよう要求する。ビュー・オブジェクトはまた、ツール・ネゴシエータ１８３０のGetInteractor()メソッドをコールすることにより、ツール・ネゴシエータ１８３０からのインタラクタを要求する。ツール・ネゴシエータ１８３０は、フレーム・データ・タイプをその内部のデータ・タイプのリストと比較することにより、現在のカーソル・ツールがそのフレーム・データ上で動作できるかどうかを判断する。現在のカーソル・ツールがそのフレーム・データ・タイプで動作できる場合、ツール・ネゴシエータ１８３０はカーソルを現在のカーソル・グラフィックに変更し、ディスプレイを更新する。ツール・ネゴシエータはまたツール・インタラクタを返す。インタラクタは、フレーム・データ上でカーソル・オペレーションを実行するために使用される。
【００５４】
TAbstractTool
図１９は好適実施例によるクラス階層を示すブロック図である。ここで特に関心のあることは、ツールのI.D.を得るTGlobalID GetID() const;およびツールのI.D.をセットするvirtual void SetID(TGlobalID);である。カーソル・ツールのフレームワークはツールのグローバルI.D.を用いてToolServer内でそのグローバルI.D.を一意的に識別し、および適切なツールに変更された旨の通知をツール・セッティング・コマンドに供給する。
【００５５】
TTool
TTool はツールを定義する抽象的なスーパークラスである。TTool また
ToolServerと交信する幾つかの静的メソッドをも有している。TTool のサブクラスは実際にはほとんど作業をしない。それらのサブクラスは、メニューおよびツール・パレットに対するグラフィックスおよびテキスト・ネーム、アクティブな時にツールを表すカーソル・グラフィック、ツールが有効である選択タイプのリストを提供し、そして、それらはユーザが選択されたツールを有する有効なフレームにおいてマウス・ダウンする時に活性化されるインタアクタ(interactor)のサブクラスを作成する。フレームにおいてデータを生成または変更する実際の作業を実行するオブジェクトはインタアクタである。
【００５６】
純粋仮想メソッド(Pure Virtual Methods)
virtual MGraphic* CreatePaletteGraphic() const=0;
サブクラスは、ツール・パレットまたはメニュー上で用いるべき新たな
MGraphicを返さなければならない。
【００５７】
virtual void GetPaletteText(TText&) const=0;
サブクラスは、TText のテキストをツールを表すメニュー・アイテムに適しているストリングにセットしなければならない。
【００５８】
virtual MGraphic* CreateCursorGraphic() const=0;
サブクラスは、ツールがアクティブな時にカーソルとして用いるべき新たな MGraphicを返さなければならない。
【００５９】
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 および
TTextSelection::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 がいかなる TAbstractTool にもセットできるように定義されたオペレータ（演算子）である。
【００７３】
TSelectionArrow
以下の属性を有する単純なTTool サブクラス。
Palette Graphic(パレット・グラフィック）：標準ピンク矢印
Cursor Graphic（カーソル・グラフィック）：標準ピンク矢印
Palette Text（パレット・テキスト）：「矢印」
Type Info:TModelSelection::kType。矢印はいずれのフレームにおいても有効である。
Tool Interactor(ツール・インタアクタ）：なし。選択矢印はそのインタアクタに対してNIL を返す。クリック−インしたフレームはそれ自体の選択インタアクタを提供しなければならない。
【００７４】
TToolNegotiator
TToolNegotiatorsは受取りチームにおける現在のツールを表す軽量の一定の構造形態をもつ(monomorphic) オブジェクトである。例えば、カーソルがアクティブなドキュメントにおけるフレームを通過する時、そのフレームはTToolNegotiator を通過する。フレームがTToolNegotiator とネゴシエートして、カーソルの形を変えるかどうかをネゴシエータに知らせる。１回のマウス・ダウンでフレームもTToolNegotiator を得て、現在のツールがフレーム内で有効であるかどうかを知るためにネゴシエーションする。もしそうならば、フレームはTToolNegotiator から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
ドロー・プログラム・スタイルの十字線(Cross hair)
【００９２】
【００９３】
TExGraphic
デバッグするのに用いられるビッグピンク(big pink) X
【００９４】
【００９５】
TArrowGraphic
矢印
【００９６】
【００９７】
ユーティリティ・クラス
TToolInstanceInterest
このインタレストはTAbstractTool で構成される。それは現在のツールになるTAbstractTool の特別の瞬時でのインタレストを表現する。図２３は好適実施例によるユーティリティ・クラスを示す。
【００９８】
TToolInstanceInterest(const TAbstractTool&, MNotifier*,
const TToken&);
TToolChangedNotification
ToolServerは、現在のツールが変わる度毎にTToolChangedNotificationを伝える、すなわちスロー(throw) する。通知は新たな現在のツールに対するTToolSurrogateおよびそのクラスのネームを保持している。
通知からデータを抽出するメソッド
TToolSurrogate GetToolSurrogate() const;
TToken GetToolType() const;
TCursorToolException
Cursor Tool のフレームワークによりスローされた例外サブクラス。
TCursorToolException により定義されたエラー
kNoBoundCursor = 0x1D02
【００９９】
制限のないカーソルを有するTSetCurrentToolCmd::Do()called。この例外は現在では用いられていない。カーソル・サーバが複数のカーソルを支持する時にスローされる。その時に、プログラマはそれを生じる前にツールとカーソルの双方をコマンドに結合することが必要となる。
【０１００】
kNoBoundToolInCommand = 0x1D02
コマンドが制限ツールを持たない時に、制限ツールを必要とする
TSetCurrentToolCmd上のメソッドをコールしようとする時にスローされる。
kNoBoundToolInServer = 0x1D03
【０１０１】
現在のツールがセットされる前に、カレントツールを必要とするTToolServer 上のメソッドをコールしようとする時にスローされる。
【０１０２】
本発明を特定のシステム環境における好適実施例に基づいて述べてきたが、本発明は、以下の特許請求の範囲精神および範囲内において、他のおよび異なるハードウェアおよびソフトウェア環境の下での変更例を以て実施することができることを当業者は認識するであろう。
【図面の簡単な説明】
【０１０３】
【図１】好適実施例によるパーソナル・コンピュータ・システムを示すブロック図である。
【図２】MacDraw で使用される従来技術のカーソル・ツール・クラスタの例を示す図である。
【図３】好適実施例によるコマンド・パネルを示す図である。
【図４】好適実施例によるコマンド・パネル・バーの例を示す図である。
【図５】好適実施例によるコマンド・パネルの例を示す図である。
【図６】好適実施例によるツール・クラスタの例を示す図である。
【図７】好適実施例による各種の形態のフレームの幾つかの例を示す図である。
【図８】好適実施例による各種のフレームをもつデスクトップを示す図である。
【図９】好適実施例によるレクタングル（矩形）カーソル・ツール、クリエータのユーザ選択を示す図である。
【図１０】好適実施例による選択矢印（アロー）を示す図である。
【図１１】好適実施例によりアクティブなツールになるカーソル・レクタングル・ツールを示す図である。
【図１２】好適実施例により、非アクティブなドキュメントを通り越して、アクティブなツールになる選択矢印を示す図である。
【図１３】好適実施例によるスマッジなツール(smudge tool) 、セレクタ (selector)／エフェクタ(effector)用の選択プロセスを示す図である。
【図１４】好適実施例により、カーソルが特定のフレームを通り越すときのみだけスマッジ・ツールを動作可能（イネーブル）にすることを示す図である。
【図１５】好適実施例により、ツール・カーソルが内容領域を通り過ぎる際のツール・カーソルの動作を示す図である。
【図１６】好適実施例により、ツール・カーソルが内容領域を通り過ぎる際のツール・カーソルの動作を示す図である。
【図１７】好適実施例によるウィンドウおよびフレーム処理をまとめて示す図である。
【図１８】好適実施例によるツール処理の論理を示す流れ図である。
【図１９】好適実施例によるクラス階層(hierarchy）を示す図である。
【図２０】好適実施例によるTToolServer クラスを示す図である。
【図２１】好適実施例によるコマンド・クラスを示す図である。
【図２２】好適実施例による予め組み込まれたジオメトリー（幾何学的配置）の幾つかを示す図である。
【図２３】好適実施例によるユーティリティ・クラスを示す図である。
【特許請求の範囲】
【請求項１】
ディスプレイを有するコンピュータ上でカーソル・ツール・オペレーションを実行する方法であって、１つのアプリケーション・プログラムは前記ディスプレイ上にデータ・タイプを有するデータを表示するフレームを生成し、別の異なるアプリケーション・プログラムは前記ディスプレイ上にデータ・タイプを有するデータを表示する別のフレームを生成し、マウスの動作に応答してカーソルが前記ディスプレイ上に生成され、前記方法は、
(a) １つのアプリケーション・プログラムにより、カーソル・ツール・オペレーションを実行するインタラクタ・オブジェクト (TToolInteractor) と、前記インタラクタ・オブジェクトが操作できる少なくとも１つのデータ・タイプを識別するデータ・タイプ・リスト (TSequence) とを含む現在のツール・オブジェクト(TTool)を選択するステップと、
(b) 前記現在のツール・オブジェクトを、前記１つのアプリケーション・プログラムおよび他のアプリケーション・プログラムの両方がアクセス可能なメモリ領域で動作するツール・サーバ・オブジェクト (TToolServer) に送信する (SetCurrentToolCmd(TTool)) ステップと、
(c) 前記カーソルが前記他のアプリケーション・プログラムにより生成された他のフレーム内に位置するとき、前記ツール・サーバに対し、前記現在のツール・オブジェクトに対応するツール・ネゴシエータ・オブジェクトを構成するように (TToolNegotiator) 、かつ、前記インタラクタ・オブジェクトおよび前記データ・タイプ・リストを含む前記構成されたツール・ネゴシエータ・オブジェクトを、前記他のアプリケーション・プログラムへ送信するように要求するステップと、
(d) 前記他のアプリケーション・プログラムにおいて、前記ツール・ネゴシエータ・オブジェクトを使用して、前記ツール・ネゴシエータ・オブジェクトのデータ・タイプ・リストを前記他のフレーム内のカーソルの下で表示されたデータのデータ・タイプと比較することにより、前記インタラクタ・オブジェクトが前記他のフレーム上に表示されたデータ・タイプを操作できるかどうかを判断する (Accepts) ステップと、
(e) 前記インタラクタ・オブジェクトが前記他のフレーム内のカーソルの下で表示されたデータ・タイプを操作できると前記ツール・ネゴシエータ・オブジェクトが判断したとき、前記ツール・ネゴシエータ・オブジェクトにおいて前記インタラクタ・オブジェクトを使用して、前記カーソルの下で表示されたデータを修正する (CreateInteractor) ステップと、
(f) 前記インタラクタ・オブジェクトが前記他のフレーム内のカーソルの下で表示されたデータ・タイプを操作できないと前記ツール・ネゴシエータ・オブジェクトが判断したとき、前記他のフレームに所定のデフォルト・カーソルを表示させるステップと
を備えたことを特徴とする方法。
【請求項２】
請求項１に記載の方法において、前記ツール・ネゴシエータ・オブジェクトは前記インタラクタ・オブジェクトに固有のツール・カーソルを含み、ステップ (e) は、前記ツール・ネゴシエータ・オブジェクトを使用して、前記カーソルを前記ツール・カーソルに変更する (AdjustCursorShapeFor()) ステップを有することを特徴とする方法。
【請求項３】
請求項１に記載の方法において、ステップ (f) は、
(f1) 前記インタラクタ・オブジェクトが前記他のフレームに表示されたデータ・タイプを操作できないときに新たなフレームを作成するステップと、
(f2) 前記インタラクタ・オブジェクトを使用して、前記新たなフレームに表示されたデータ・タイプのデータを作成するステップであって、前記新たなフレームは前記インタラクタ・オブジェクトが操作できるデータ・タイプを表示するステップと、
(f3) 前記他のフレームに前記新たなフレームを組み込むステップと
を有することを特徴とする方法。
【請求項４】
請求項１に記載の方法において、ステップ (a) は、
(a1) １つのアプリケーション・プログラムにより、複数のコントロールを含むツール・クラスタを前記ディスプレイ上に表示するステップであって、各コントロールはカーソル・ツールを表すステップと、
(a2) 前記ツール・クラスタ内のコントロールが前記マウスにより選択されたとき、前記ツール・クラスタからツール・オブジェクトおよび該ツール・オブジェクトに関連付けられるべきツール・カーソルを前記現在のツール・オブジェクトとして選択するステップと
をさらに備えたことを特徴とする方法。
【請求項５】
請求項４に記載の方法において、前記フレームの各々はビュー・オブジェクトにより表示され、ステップ (c) は、
(c1)前記構成されたツール・ネゴシエータ・オブジェクトを前記ビュー・オブジェクトに送信するステップ
を有することを特徴とする方法。
【請求項６】
請求項５に記載の方法において、プロセス境界が前記ツール・サーバ・オブジェクトおよび前記ビュー・オブジェクトの間で発生することを特徴とする方法。
【請求項７】
請求項４に記載の方法において、前記フレームの各々はビュー・オブジェクトにより表示され、かつ前記マウスを使用して選択することができ、ステップ (c)は、
(c1) 前記構成されたツール・ネゴシエータ・オブジェクトを前記マウスにより選択されたビュー・オブジェクトへ送るステップ
を有することを特徴とする方法。
【請求項８】
請求項７に記載の方法において、ステップ (e) は、前記インタラクタを前記ビュー・オブジェクトに提供し、前記インタラクタ・オブジェクトが前記選択されたフレーム内のデータを変更できるようにする (CreateInteractor()) ステップを有することを特徴とする方法。
【請求項９】
請求項４に記載の方法において、前記複数のフレームは前記ディスプレイ上に表示されたウィンドウに含まれており、前記方法は、
(g) 複数のコントロールを含むコマンド・パネルを前記ディスプレイ上に表示するステップであって、各コントロールは前記ウィンドウに作用するコマンドを表し、少なくとも１つのツール・クラスタを含むステップをさらに備えたことを特徴とする方法。
【請求項１０】
ディスプレイを有するコンピュータ上でカーソル・ツール・オペレーションを実行する装置であって、１つのアプリケーション・プログラムは前記ディスプレイ上にデータ・タイプを有するデータを表示するフレームを生成し、別の異なるアプリケーション・プログラムは前記ディスプレイ上にデータ・タイプを有するデータを表示する別のフレームを生成し、マウスの動作に応答してカーソルが前記ディスプレイ上に生成され、前記装置は、
１つのアプリケーション・プログラムにより、カーソル・ツール・オペレーションを実行するインタラクタ・オブジェクトと、前記インタラクタ・オブジェクトが操作できる少なくとも１つのデータ・タイプを識別するデータ・タイプ・リストとを含む現在のツール・オブジェクトを選択する手段と、
前記現在のツール・オブジェクトを、前記１つのアプリケーション・プログラムおよび他のアプリケーション・プログラムの両方がアクセス可能なメモリ領域で動作するツール・サーバ・オブジェクトに送信する手段と、
前記カーソルが前記他のアプリケーション・プログラムにより生成された他のフレーム内に位置するときに動作可能であり、前記ツール・サーバに対し、前記現在のツール・オブジェクトに対応するツール・ネゴシエータ・オブジェクトを構成するように、かつ、前記構成されたツール・ネゴシエータ・オブジェクトを前記他のアプリケーション・プログラムへ送信するように要求する手段であって、前記構成されたツール・ネゴシエータ・オブジェクトは前記インタラクタ・オブジェクトおよび前記データ・タイプ・リストを含む手段と、
前記他のアプリケーション・プログラムにおいて、前記ツール・ネゴシエータ・オブジェクトを使用して、前記ツール・ネゴシエータ・オブジェクトのデータ・タイプ・リストを前記他のフレーム内のカーソルの下で表示されたデータのデータ・タイプと比較することにより、前記インタラクタ・オブジェクトが前記他のフレーム上に表示されたデータ・タイプを操作できるかどうかを判断する手段と、
前記インタラクタ・オブジェクトが前記他のフレーム内のカーソルの下で表示されたデータ・タイプを操作できると前記ツール・ネゴシエータ・オブジェクトが判断したとき、前記ツール・ネゴシエータ・オブジェクトにおいて前記インタラクタ・オブジェクトを使用して、前記カーソルの下で表示されたデータを修正する手段と、
前記インタラクタ・オブジェクトが前記他のフレーム内のカーソルの下で表示されたデータ・タイプを操作できないと前記ツール・ネゴシエータ・オブジェクトが判断したとき、前記他のフレームに所定のデフォルト・カーソルを表示させる手段と
を備えたことを特徴とする装置。
【請求項１１】
請求項１０に記載の装置において、前記ツール・ネゴシエータ・オブジェクトは前記インタラクタ・オブジェクトに固有のツール・カーソルを含み、前記ツール・ネゴシエータ・オブジェクトにおいて前記インタラクタ・オブジェクトを使用して、前記カーソルの下で表示されたデータを修正する手段は、前記ツール・ネゴシエータ・オブジェクトを使用して、前記カーソルを前記ツール・カーソルに変更する手段を有することを特徴とする装置。
【請求項１２】
請求項１０に記載の装置において、前記他のフレームに所定のデフォルト・カーソルを表示させる手段は、
前記インタラクタ・オブジェクトが前記他のフレームに表示されたデータ・タイプを操作できないときに新たなフレームを作成する手段であって、前記新たなフレームは前記インタラクタ・オブジェクトが操作できるデータ・タイプを表示する手段と、
前記インタラクタ・オブジェクトを使用して、前記新たなフレームに表示されたデータ・タイプのデータを作成する手段と、
前記他のフレームに前記新たなフレームを組み込む手段と
を有することを特徴とする装置。
【請求項１３】
請求項１０に記載の装置において、前記１つのアプリケーション・プログラムにより現在のツール・オブジェクトを選択する手段は、
複数のコントロールを含むツール・クラスタを前記ディスプレイ上に表示する手段であって、各コントロールはカーソル・ツールを表す手段と、
前記ツール・クラスタ内のコントロールが前記マウスにより選択されたとき、前記ツール・クラスタからツール・オブジェクトおよび該ツール・オブジェクトに関連付けられるべきツール・カーソルを前記現在のツール・オブジェクトとして選択する手段と
をさらに備えたことを特徴とする装置。
【請求項１４】
請求項１３に記載の装置において、前記フレームの各々はビュー・オブジェクトにより表示され、前記構成されたツール・ネゴシエータ・オブジェクトを前記他のアプリケーション・プログラムに送信する手段は、
前記構成されたツール・ネゴシエータ・オブジェクトを前記ビュー・オブジェクトに送信する手段
を有することを特徴とする装置。
【請求項１５】
請求項１４に記載の装置において、プロセス境界が前記ツール・サーバ・オブジェクトおよび前記ビュー・オブジェクトの間で発生することを特徴とする装置。
【請求項１６】
請求項１３に記載の装置において、前記フレームの各々はビュー・オブジェクトにより表示され、かつ前記マウスを使用して選択することができ、前記構成されたツール・ネゴシエータ・オブジェクトを前記他のアプリケーション・プログラムに送信する手段は、
前記構成されたツール・ネゴシエータ・オブジェクトを前記ビュー・オブジェクトへ送る手段
を有することを特徴とする装置。
【請求項１７】
請求項１６に記載の装置において、前記ツール・ネゴシエータ・オブジェクトにおいて前記インタラクタ・オブジェクトを使用して前記カーソルの下で表示されたデータを修正する手段は、前記インタラクタを前記ビュー・オブジェクトに提供し、前記インタラクタ・オブジェクトが前記選択されたフレーム内のデータを変更できるようにする手段を有することを特徴とする装置。
【請求項１８】
請求項１３に記載の装置において、前記複数のフレームは前記ディスプレイ上に表示されたウィンドウに含まれており、前記装置は、
複数のコントロールを含むコマンド・パネルを前記ディスプレイ上に表示する手段であって、各コントロールは前記ウィンドウに作用するコマンドを表し、少なくとも１つのツール・クラスタを含む手段をさらに備えたことを特徴とする装置。
【請求項１】
ディスプレイを有するコンピュータ上でカーソル・ツール・オペレーションを実行する方法であって、１つのアプリケーション・プログラムは前記ディスプレイ上にデータ・タイプを有するデータを表示するフレームを生成し、別の異なるアプリケーション・プログラムは前記ディスプレイ上にデータ・タイプを有するデータを表示する別のフレームを生成し、マウスの動作に応答してカーソルが前記ディスプレイ上に生成され、前記方法は、
(a) １つのアプリケーション・プログラムにより、カーソル・ツール・オペレーションを実行するインタラクタ・オブジェクト (TToolInteractor) と、前記インタラクタ・オブジェクトが操作できる少なくとも１つのデータ・タイプを識別するデータ・タイプ・リスト (TSequence) とを含む現在のツール・オブジェクト(TTool)を選択するステップと、
(b) 前記現在のツール・オブジェクトを、前記１つのアプリケーション・プログラムおよび他のアプリケーション・プログラムの両方がアクセス可能なメモリ領域で動作するツール・サーバ・オブジェクト (TToolServer) に送信する (SetCurrentToolCmd(TTool)) ステップと、
(c) 前記カーソルが前記他のアプリケーション・プログラムにより生成された他のフレーム内に位置するとき、前記ツール・サーバに対し、前記現在のツール・オブジェクトに対応するツール・ネゴシエータ・オブジェクトを構成するように (TToolNegotiator) 、かつ、前記インタラクタ・オブジェクトおよび前記データ・タイプ・リストを含む前記構成されたツール・ネゴシエータ・オブジェクトを、前記他のアプリケーション・プログラムへ送信するように要求するステップと、
(d) 前記他のアプリケーション・プログラムにおいて、前記ツール・ネゴシエータ・オブジェクトを使用して、前記ツール・ネゴシエータ・オブジェクトのデータ・タイプ・リストを前記他のフレーム内のカーソルの下で表示されたデータのデータ・タイプと比較することにより、前記インタラクタ・オブジェクトが前記他のフレーム上に表示されたデータ・タイプを操作できるかどうかを判断する (Accepts) ステップと、
(e) 前記インタラクタ・オブジェクトが前記他のフレーム内のカーソルの下で表示されたデータ・タイプを操作できると前記ツール・ネゴシエータ・オブジェクトが判断したとき、前記ツール・ネゴシエータ・オブジェクトにおいて前記インタラクタ・オブジェクトを使用して、前記カーソルの下で表示されたデータを修正する (CreateInteractor) ステップと、
(f) 前記インタラクタ・オブジェクトが前記他のフレーム内のカーソルの下で表示されたデータ・タイプを操作できないと前記ツール・ネゴシエータ・オブジェクトが判断したとき、前記他のフレームに所定のデフォルト・カーソルを表示させるステップと
を備えたことを特徴とする方法。
【請求項２】
請求項１に記載の方法において、前記ツール・ネゴシエータ・オブジェクトは前記インタラクタ・オブジェクトに固有のツール・カーソルを含み、ステップ (e) は、前記ツール・ネゴシエータ・オブジェクトを使用して、前記カーソルを前記ツール・カーソルに変更する (AdjustCursorShapeFor()) ステップを有することを特徴とする方法。
【請求項３】
請求項１に記載の方法において、ステップ (f) は、
(f1) 前記インタラクタ・オブジェクトが前記他のフレームに表示されたデータ・タイプを操作できないときに新たなフレームを作成するステップと、
(f2) 前記インタラクタ・オブジェクトを使用して、前記新たなフレームに表示されたデータ・タイプのデータを作成するステップであって、前記新たなフレームは前記インタラクタ・オブジェクトが操作できるデータ・タイプを表示するステップと、
(f3) 前記他のフレームに前記新たなフレームを組み込むステップと
を有することを特徴とする方法。
【請求項４】
請求項１に記載の方法において、ステップ (a) は、
(a1) １つのアプリケーション・プログラムにより、複数のコントロールを含むツール・クラスタを前記ディスプレイ上に表示するステップであって、各コントロールはカーソル・ツールを表すステップと、
(a2) 前記ツール・クラスタ内のコントロールが前記マウスにより選択されたとき、前記ツール・クラスタからツール・オブジェクトおよび該ツール・オブジェクトに関連付けられるべきツール・カーソルを前記現在のツール・オブジェクトとして選択するステップと
をさらに備えたことを特徴とする方法。
【請求項５】
請求項４に記載の方法において、前記フレームの各々はビュー・オブジェクトにより表示され、ステップ (c) は、
(c1)前記構成されたツール・ネゴシエータ・オブジェクトを前記ビュー・オブジェクトに送信するステップ
を有することを特徴とする方法。
【請求項６】
請求項５に記載の方法において、プロセス境界が前記ツール・サーバ・オブジェクトおよび前記ビュー・オブジェクトの間で発生することを特徴とする方法。
【請求項７】
請求項４に記載の方法において、前記フレームの各々はビュー・オブジェクトにより表示され、かつ前記マウスを使用して選択することができ、ステップ (c)は、
(c1) 前記構成されたツール・ネゴシエータ・オブジェクトを前記マウスにより選択されたビュー・オブジェクトへ送るステップ
を有することを特徴とする方法。
【請求項８】
請求項７に記載の方法において、ステップ (e) は、前記インタラクタを前記ビュー・オブジェクトに提供し、前記インタラクタ・オブジェクトが前記選択されたフレーム内のデータを変更できるようにする (CreateInteractor()) ステップを有することを特徴とする方法。
【請求項９】
請求項４に記載の方法において、前記複数のフレームは前記ディスプレイ上に表示されたウィンドウに含まれており、前記方法は、
(g) 複数のコントロールを含むコマンド・パネルを前記ディスプレイ上に表示するステップであって、各コントロールは前記ウィンドウに作用するコマンドを表し、少なくとも１つのツール・クラスタを含むステップをさらに備えたことを特徴とする方法。
【請求項１０】
ディスプレイを有するコンピュータ上でカーソル・ツール・オペレーションを実行する装置であって、１つのアプリケーション・プログラムは前記ディスプレイ上にデータ・タイプを有するデータを表示するフレームを生成し、別の異なるアプリケーション・プログラムは前記ディスプレイ上にデータ・タイプを有するデータを表示する別のフレームを生成し、マウスの動作に応答してカーソルが前記ディスプレイ上に生成され、前記装置は、
１つのアプリケーション・プログラムにより、カーソル・ツール・オペレーションを実行するインタラクタ・オブジェクトと、前記インタラクタ・オブジェクトが操作できる少なくとも１つのデータ・タイプを識別するデータ・タイプ・リストとを含む現在のツール・オブジェクトを選択する手段と、
前記現在のツール・オブジェクトを、前記１つのアプリケーション・プログラムおよび他のアプリケーション・プログラムの両方がアクセス可能なメモリ領域で動作するツール・サーバ・オブジェクトに送信する手段と、
前記カーソルが前記他のアプリケーション・プログラムにより生成された他のフレーム内に位置するときに動作可能であり、前記ツール・サーバに対し、前記現在のツール・オブジェクトに対応するツール・ネゴシエータ・オブジェクトを構成するように、かつ、前記構成されたツール・ネゴシエータ・オブジェクトを前記他のアプリケーション・プログラムへ送信するように要求する手段であって、前記構成されたツール・ネゴシエータ・オブジェクトは前記インタラクタ・オブジェクトおよび前記データ・タイプ・リストを含む手段と、
前記他のアプリケーション・プログラムにおいて、前記ツール・ネゴシエータ・オブジェクトを使用して、前記ツール・ネゴシエータ・オブジェクトのデータ・タイプ・リストを前記他のフレーム内のカーソルの下で表示されたデータのデータ・タイプと比較することにより、前記インタラクタ・オブジェクトが前記他のフレーム上に表示されたデータ・タイプを操作できるかどうかを判断する手段と、
前記インタラクタ・オブジェクトが前記他のフレーム内のカーソルの下で表示されたデータ・タイプを操作できると前記ツール・ネゴシエータ・オブジェクトが判断したとき、前記ツール・ネゴシエータ・オブジェクトにおいて前記インタラクタ・オブジェクトを使用して、前記カーソルの下で表示されたデータを修正する手段と、
前記インタラクタ・オブジェクトが前記他のフレーム内のカーソルの下で表示されたデータ・タイプを操作できないと前記ツール・ネゴシエータ・オブジェクトが判断したとき、前記他のフレームに所定のデフォルト・カーソルを表示させる手段と
を備えたことを特徴とする装置。
【請求項１１】
請求項１０に記載の装置において、前記ツール・ネゴシエータ・オブジェクトは前記インタラクタ・オブジェクトに固有のツール・カーソルを含み、前記ツール・ネゴシエータ・オブジェクトにおいて前記インタラクタ・オブジェクトを使用して、前記カーソルの下で表示されたデータを修正する手段は、前記ツール・ネゴシエータ・オブジェクトを使用して、前記カーソルを前記ツール・カーソルに変更する手段を有することを特徴とする装置。
【請求項１２】
請求項１０に記載の装置において、前記他のフレームに所定のデフォルト・カーソルを表示させる手段は、
前記インタラクタ・オブジェクトが前記他のフレームに表示されたデータ・タイプを操作できないときに新たなフレームを作成する手段であって、前記新たなフレームは前記インタラクタ・オブジェクトが操作できるデータ・タイプを表示する手段と、
前記インタラクタ・オブジェクトを使用して、前記新たなフレームに表示されたデータ・タイプのデータを作成する手段と、
前記他のフレームに前記新たなフレームを組み込む手段と
を有することを特徴とする装置。
【請求項１３】
請求項１０に記載の装置において、前記１つのアプリケーション・プログラムにより現在のツール・オブジェクトを選択する手段は、
複数のコントロールを含むツール・クラスタを前記ディスプレイ上に表示する手段であって、各コントロールはカーソル・ツールを表す手段と、
前記ツール・クラスタ内のコントロールが前記マウスにより選択されたとき、前記ツール・クラスタからツール・オブジェクトおよび該ツール・オブジェクトに関連付けられるべきツール・カーソルを前記現在のツール・オブジェクトとして選択する手段と
をさらに備えたことを特徴とする装置。
【請求項１４】
請求項１３に記載の装置において、前記フレームの各々はビュー・オブジェクトにより表示され、前記構成されたツール・ネゴシエータ・オブジェクトを前記他のアプリケーション・プログラムに送信する手段は、
前記構成されたツール・ネゴシエータ・オブジェクトを前記ビュー・オブジェクトに送信する手段
を有することを特徴とする装置。
【請求項１５】
請求項１４に記載の装置において、プロセス境界が前記ツール・サーバ・オブジェクトおよび前記ビュー・オブジェクトの間で発生することを特徴とする装置。
【請求項１６】
請求項１３に記載の装置において、前記フレームの各々はビュー・オブジェクトにより表示され、かつ前記マウスを使用して選択することができ、前記構成されたツール・ネゴシエータ・オブジェクトを前記他のアプリケーション・プログラムに送信する手段は、
前記構成されたツール・ネゴシエータ・オブジェクトを前記ビュー・オブジェクトへ送る手段
を有することを特徴とする装置。
【請求項１７】
請求項１６に記載の装置において、前記ツール・ネゴシエータ・オブジェクトにおいて前記インタラクタ・オブジェクトを使用して前記カーソルの下で表示されたデータを修正する手段は、前記インタラクタを前記ビュー・オブジェクトに提供し、前記インタラクタ・オブジェクトが前記選択されたフレーム内のデータを変更できるようにする手段を有することを特徴とする装置。
【請求項１８】
請求項１３に記載の装置において、前記複数のフレームは前記ディスプレイ上に表示されたウィンドウに含まれており、前記装置は、
複数のコントロールを含むコマンド・パネルを前記ディスプレイ上に表示する手段であって、各コントロールは前記ウィンドウに作用するコマンドを表し、少なくとも１つのツール・クラスタを含む手段をさらに備えたことを特徴とする装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公開番号】特開２００７−２９３９０４（Ｐ２００７−２９３９０４Ａ）
【公開日】平成１９年１１月８日（２００７．１１．８）
【国際特許分類】
【出願番号】特願２００７−１６６９９５（Ｐ２００７−１６６９９５）
【出願日】平成１９年６月２５日（２００７．６．２５）
【分割の表示】特願平７−５１３７８０の分割
【原出願日】平成６年１月３日（１９９４．１．３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＵＮＩＸ
【出願人】（５００２６９９５６）オブジェクト テクノロジー ライセンシング コーポレイション (12)
【Ｆターム（参考）】
【公開日】平成１９年１１月８日（２００７．１１．８）
【国際特許分類】
【出願日】平成１９年６月２５日（２００７．６．２５）
【分割の表示】特願平７−５１３７８０の分割
【原出願日】平成６年１月３日（１９９４．１．３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＵＮＩＸ
【出願人】（５００２６９９５６）オブジェクト テクノロジー ライセンシング コーポレイション (12)
【Ｆターム（参考）】
[ Back to top ]