JP4043509B2 - オブジェクト指向カーソル・ツール - Google Patents
オブジェクト指向カーソル・ツール Download PDFInfo
- Publication number
- JP4043509B2 JP4043509B2 JP51378095A JP51378095A JP4043509B2 JP 4043509 B2 JP4043509 B2 JP 4043509B2 JP 51378095 A JP51378095 A JP 51378095A JP 51378095 A JP51378095 A JP 51378095A JP 4043509 B2 JP4043509 B2 JP 4043509B2
- Authority
- JP
- Japan
- Prior art keywords
- tool
- cursor
- frame
- data type
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
- G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
- G06F3/0481—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
- G06F3/04812—Interaction techniques based on cursor appearance or behaviour, e.g. being affected by the presence of displayed objects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
- G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
- G06F3/0481—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Health & Medical Sciences (AREA)
- Artificial Intelligence (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Computational Linguistics (AREA)
- General Health & Medical Sciences (AREA)
- User Interface Of Digital Computer (AREA)
- Digital Computer Display Output (AREA)
Description
著作権表記
本明細書の一部には、著作権保護の対象となる内容が含まれている。著作権所有者は、米国特許商標庁の特許ファイルまたは記録に記述されている特許文書または特許開示事項を誰かがそのまま複製することに異論を唱えないが、その他の場合には著作権に係わる一切の権利を留保する。
発明の分野
本発明は、一般的にはコンピュータ・システムにおける改良に関し、特にオブジェクト指向オペレーティング・システムにおけるツール・オブジェクトおよびツール・オブジェクトのメニューを用いるシステムおよび方法に関する。
発明の背景
カーソル・ツールは、ユーザ制御される「カーソル」のふるまいを変えることでユーザのドキュメントまたはフレームとの相互作用の特定のモードを特定する。例えば、ユーザは「レクタングル（矩形）」カーソル・ツールを選択して、マウスボタンを押しながらマウスをドラッグすることで、ドキュメント・ドローイング（描画）キャンバス上にレクタングルを生成することをオペレーティング環境に指示することができる。ツールはデータの選択、操作および生成用のモードを指示することができる。カーソル・ツールの従来技術例はMacPaint（登録商標）またはMacDraw（登録商標）のようなアプリケーションにおいて見受けられる。しかし、これらのアプリケーションは一度に２つ以上のカーソルの管理をユーザに提供しなかった。さらに、オペレーティング・システムへの統合を行って、１つのアプリケーションにおいてアクティブなツールを他のアプリケーションでも機能させることができるようにすることはなされていなかった。カーソル・ツールとアプリケーションとの間のネゴシエーションの能力も従来技術では知られてはいなかった。
発明の概要
本発明の革新的システムおよび方法ではオブジェクト指向技術を用いて、複数のカーソル・ツールを一つのオブジェクト指向オペレーティング・システムに統合する。この統合は複数のタスクでの複数のカーソル・ツールを同時に管理することを含んでいる。ネゴシエーション能力を設けて、任意のカーソル・ツールと任意のアプリケーションとを共に機能させることができるようにする。この独自の能力は区画を越えてのメモリ管理を含み、それによりアプリケーションおよび区分を越えてカーソル・ツールを使用することを可能にしている。オブジェクト指向のフレームワークによりカーソル・ツールをアプリケーションを越えて分配するためのアーキテクチャを提供するので、そのためカーソル・ツール機能が必要になるまではアプリケーション要求はツールについて知らない。技術用語では、これは、カーソル・ツールがアプリケーションの情報をうまく変更できることが決定された後までは、どんなアプリケーションでもカーソル・ツールの共有ライブラリにおいてマッピングすることなしにカーソル・ツールを使用することができることを意味する。
【図面の簡単な説明】
図１は、好適実施例によるパーソナル・コンピュータ・システムを示すブロック図である。
図２は、MacDrawで使用される従来技術のカーソル・ツール・クラスタの例を示す図である。
図３は、好適実施例によるコマンド・パネルを示す図である。
図４は、好適実施例によるコマンド・パネル・バーの例を示す図である。
図５は、好適実施例によるコマンド・パネルの例を示す図である。
図６は、好適実施例によるツール・クラスタの例を示す図である。
図７は、好適実施例による各種の形態のフレームの幾つかの例を示す図である。
図８は、好適実施例による各種のフレームをもつデスクトップを示す図である。
図９は、好適実施例によるレクタングル（矩形）カーソル・ツール、クリエータのユーザ選択を示す図である。
図１０は、好適実施例による選択矢印（アロー）を示す図である。
図１１は、好適実施例によりアクティブなツールになるカーソル・レクタングル・ツールを示す図である。
図１２は、好適実施例により、非アクティブなドキュメントを通り越して、アクティブなツールになる選択矢印を示す図である。
図１３は、好適実施例によるスマッジなツール（smudge tool）、セレクタ（selector）／エフェクタ（effector）用の選択プロセスを示す図である。
図１４は、好適実施例により、カーソルが特定のフレームを通り越すときのみだけスマッジ・ツールを動作可能（イネーブル）にすることを示す図である。
図１５および図１６は、好適実施例により、ツール・カーソルが内容領域を通り過ぎる際のツール・カーソルの動作を示す図である。
図１７は、好適実施例によるウィンドウおよびフレーム処理をまとめて示す図である。
図１８は、好適実施例によるツール処理の論理を示す流れ図である。
図１９は、好適実施例によるクラス階層（hierarchy）を示す図である。
図２０は、好適実施例によるTToolServerクラスを示す図である。
図２１は、好適実施例によるコマンド・クラスを示す図である。
図２２は、好適実施例による予め組み込まれたジオメトリー（幾何学的配置）の幾つかを示す図である。
図２３は、好適実施例によるユーティリティ・クラスを示す図である。
発明の詳細な説明
本発明はＩＢＭ（登録商標）社のＰＳ／２（登録商標）またはアップル（登録商標）社のマッキントッシュ（登録商標）コンピュータのようなパーソナル・コンピュータに常駐するオペレーティング・システムの下で実行されるのが好ましい。代表的なハードウェア環境は図１に示され、図１は、組み込みの不揮発性記憶装置１１を有する慣例のマイクロプロセッサのような中央処理装置１０およびシステム・バス１２を介して相互接続された多数の他のユニットを有する本発明によるコンピュータの代表的なハードウェア構成を示す。図１に示されるワークステーションは、ランダム・アクセス・メモリ（ＲＡＭ）１４、リード・オンリ・メモリ（ＲＯＭ）１６、ディスク・ユニット２０およびディスケット・ユニット２１のような周辺装置をバスに接続する入出力アダプタ１８、キーボード２４、マウス２６、スピーカ２８、マイクロホン３２、および／またはタッチ・スクリーン装置（図示せず）などのような他のユーザ・インタフェース装置をバスに接続するユーザ・インタフェース・アダプタ２２、このワークステーションをデータ処理ネットワーク２３に接続する通信アダプタ３４、およびバスをディスプレイ装置３８に接続するディスプレイ・アダプタ３６を含んでいる。このコンピュータには、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内で選択した最終ツールになるであろう。好適実施例では、ツールはある場所に持続するが、場所を越えて持続することはない。例えば、もしレクタングル（矩形）カーソル・ツールが１つのアプリケーションにおいて選択される場合には、たとえ如何なるフレームまたはドキュメントがアクティブにされたにしても、そのカーソル・ツールは選択されたカーソル・ツールのままである。
カーソル・ツールの例
カーソル・ツール・クラスター（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
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サブクラス。図２２は予め組込まれた幾何の幾つかを示す。
ユーティリティ・クラス
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 = 0xlD02
制限のないカーソルを有するTSetCurrentToolCmd::Do()called。この例外は現在では用いられていない。カーソル・サーバが複数のカーソルを支持する時にスローされる。その時に、プログラマはそれを生じる前にツールとカーソルの双方をコマンドに結合することが必要となる。
kNoBoundToolInCommand = 0xlD02
コマンドが制限ツールを持たない時に、制限ツールを必要とするTSetCurrentToolCmd上のメソッドをコールしょうとする時にスローされる。
kNoBoundToolInServer = 0xlD03
現在のツールがセットされる前に、カレントツールを必要とするTToolServer上のメソッドをコールしょうとする時にスローされる。
本発明を特定のシステム環境における好適実施例に基づいて述べてきたが、本発明は、以下の特許請求の範囲精神および範囲内において、他のおよび異なるハードウェアおよびソフトウェア環境の下での変更例を以て実施することができることを当業者は認識するであろう。
本明細書の一部には、著作権保護の対象となる内容が含まれている。著作権所有者は、米国特許商標庁の特許ファイルまたは記録に記述されている特許文書または特許開示事項を誰かがそのまま複製することに異論を唱えないが、その他の場合には著作権に係わる一切の権利を留保する。
発明の分野
本発明は、一般的にはコンピュータ・システムにおける改良に関し、特にオブジェクト指向オペレーティング・システムにおけるツール・オブジェクトおよびツール・オブジェクトのメニューを用いるシステムおよび方法に関する。
発明の背景
カーソル・ツールは、ユーザ制御される「カーソル」のふるまいを変えることでユーザのドキュメントまたはフレームとの相互作用の特定のモードを特定する。例えば、ユーザは「レクタングル（矩形）」カーソル・ツールを選択して、マウスボタンを押しながらマウスをドラッグすることで、ドキュメント・ドローイング（描画）キャンバス上にレクタングルを生成することをオペレーティング環境に指示することができる。ツールはデータの選択、操作および生成用のモードを指示することができる。カーソル・ツールの従来技術例はMacPaint（登録商標）またはMacDraw（登録商標）のようなアプリケーションにおいて見受けられる。しかし、これらのアプリケーションは一度に２つ以上のカーソルの管理をユーザに提供しなかった。さらに、オペレーティング・システムへの統合を行って、１つのアプリケーションにおいてアクティブなツールを他のアプリケーションでも機能させることができるようにすることはなされていなかった。カーソル・ツールとアプリケーションとの間のネゴシエーションの能力も従来技術では知られてはいなかった。
発明の概要
本発明の革新的システムおよび方法ではオブジェクト指向技術を用いて、複数のカーソル・ツールを一つのオブジェクト指向オペレーティング・システムに統合する。この統合は複数のタスクでの複数のカーソル・ツールを同時に管理することを含んでいる。ネゴシエーション能力を設けて、任意のカーソル・ツールと任意のアプリケーションとを共に機能させることができるようにする。この独自の能力は区画を越えてのメモリ管理を含み、それによりアプリケーションおよび区分を越えてカーソル・ツールを使用することを可能にしている。オブジェクト指向のフレームワークによりカーソル・ツールをアプリケーションを越えて分配するためのアーキテクチャを提供するので、そのためカーソル・ツール機能が必要になるまではアプリケーション要求はツールについて知らない。技術用語では、これは、カーソル・ツールがアプリケーションの情報をうまく変更できることが決定された後までは、どんなアプリケーションでもカーソル・ツールの共有ライブラリにおいてマッピングすることなしにカーソル・ツールを使用することができることを意味する。
【図面の簡単な説明】
図１は、好適実施例によるパーソナル・コンピュータ・システムを示すブロック図である。
図２は、MacDrawで使用される従来技術のカーソル・ツール・クラスタの例を示す図である。
図３は、好適実施例によるコマンド・パネルを示す図である。
図４は、好適実施例によるコマンド・パネル・バーの例を示す図である。
図５は、好適実施例によるコマンド・パネルの例を示す図である。
図６は、好適実施例によるツール・クラスタの例を示す図である。
図７は、好適実施例による各種の形態のフレームの幾つかの例を示す図である。
図８は、好適実施例による各種のフレームをもつデスクトップを示す図である。
図９は、好適実施例によるレクタングル（矩形）カーソル・ツール、クリエータのユーザ選択を示す図である。
図１０は、好適実施例による選択矢印（アロー）を示す図である。
図１１は、好適実施例によりアクティブなツールになるカーソル・レクタングル・ツールを示す図である。
図１２は、好適実施例により、非アクティブなドキュメントを通り越して、アクティブなツールになる選択矢印を示す図である。
図１３は、好適実施例によるスマッジなツール（smudge tool）、セレクタ（selector）／エフェクタ（effector）用の選択プロセスを示す図である。
図１４は、好適実施例により、カーソルが特定のフレームを通り越すときのみだけスマッジ・ツールを動作可能（イネーブル）にすることを示す図である。
図１５および図１６は、好適実施例により、ツール・カーソルが内容領域を通り過ぎる際のツール・カーソルの動作を示す図である。
図１７は、好適実施例によるウィンドウおよびフレーム処理をまとめて示す図である。
図１８は、好適実施例によるツール処理の論理を示す流れ図である。
図１９は、好適実施例によるクラス階層（hierarchy）を示す図である。
図２０は、好適実施例によるTToolServerクラスを示す図である。
図２１は、好適実施例によるコマンド・クラスを示す図である。
図２２は、好適実施例による予め組み込まれたジオメトリー（幾何学的配置）の幾つかを示す図である。
図２３は、好適実施例によるユーティリティ・クラスを示す図である。
発明の詳細な説明
本発明はＩＢＭ（登録商標）社のＰＳ／２（登録商標）またはアップル（登録商標）社のマッキントッシュ（登録商標）コンピュータのようなパーソナル・コンピュータに常駐するオペレーティング・システムの下で実行されるのが好ましい。代表的なハードウェア環境は図１に示され、図１は、組み込みの不揮発性記憶装置１１を有する慣例のマイクロプロセッサのような中央処理装置１０およびシステム・バス１２を介して相互接続された多数の他のユニットを有する本発明によるコンピュータの代表的なハードウェア構成を示す。図１に示されるワークステーションは、ランダム・アクセス・メモリ（ＲＡＭ）１４、リード・オンリ・メモリ（ＲＯＭ）１６、ディスク・ユニット２０およびディスケット・ユニット２１のような周辺装置をバスに接続する入出力アダプタ１８、キーボード２４、マウス２６、スピーカ２８、マイクロホン３２、および／またはタッチ・スクリーン装置（図示せず）などのような他のユーザ・インタフェース装置をバスに接続するユーザ・インタフェース・アダプタ２２、このワークステーションをデータ処理ネットワーク２３に接続する通信アダプタ３４、およびバスをディスプレイ装置３８に接続するディスプレイ・アダプタ３６を含んでいる。このコンピュータには、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内で選択した最終ツールになるであろう。好適実施例では、ツールはある場所に持続するが、場所を越えて持続することはない。例えば、もしレクタングル（矩形）カーソル・ツールが１つのアプリケーションにおいて選択される場合には、たとえ如何なるフレームまたはドキュメントがアクティブにされたにしても、そのカーソル・ツールは選択されたカーソル・ツールのままである。
カーソル・ツールの例
クラスターは関連したカーソル・ツールを論理的および可視的にグループ化する手段である。クラスターは種々のカーソル・ツールを保持するビュー（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
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サブクラス。図２２は予め組込まれた幾何の幾つかを示す。
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 = 0xlD02
制限のないカーソルを有するTSetCurrentToolCmd::Do()called。この例外は現在では用いられていない。カーソル・サーバが複数のカーソルを支持する時にスローされる。その時に、プログラマはそれを生じる前にツールとカーソルの双方をコマンドに結合することが必要となる。
kNoBoundToolInCommand = 0xlD02
コマンドが制限ツールを持たない時に、制限ツールを必要とするTSetCurrentToolCmd上のメソッドをコールしょうとする時にスローされる。
kNoBoundToolInServer = 0xlD03
現在のツールがセットされる前に、カレントツールを必要とするTToolServer上のメソッドをコールしょうとする時にスローされる。
本発明を特定のシステム環境における好適実施例に基づいて述べてきたが、本発明は、以下の特許請求の範囲精神および範囲内において、他のおよび異なるハードウェアおよびソフトウェア環境の下での変更例を以て実施することができることを当業者は認識するであろう。
Claims (8)
- ディスプレイ、該ディスプレイ上に複数のフレームを生成し、各フレーム表示データはデータ・タイプを有する手段およびマウスの動作に応答して前記ディスプレイ上にカーソルを生成する手段においてカーソル・ツール・オペレーションを実行する方法であって、
（a）カーソル・ツール・オペレーションを実行する手段と、カーソル・ツール・オペレーションを実行する前記手段が動作できる少なくとも１つのデータ・タイプを識別するデータ・タイプ情報とを含むツール・オブジェクトを作成するステップと、
（b）前記カーソルが前記フレームの１つに位置するとき、前記ツール・オブジェクトを使用して、前記ツール・オブジェクトのデータ・タイプ情報を前記１つのフレームに表示されたデータのデータ・タイプと比較することにより、カーソル・ツール・オペレーションを実行する前記手段が前記１つのフレーム上に表示されたデータ・タイプ上で動作できるかどうかを判断するステップと、
（c）カーソル・ツール・オペレーションを実行する前記手段が前記１つのフレームに表示されたデータ・タイプにより動作できるとき、前記カーソルの下で表示されたデータを修正するステップと、
（d）カーソル・ツール・オペレーションを実行する前記手段が前記１つのフレーム上に表示されたデータ・タイプにより動作できないとき、所定のデフォルト・カーソルを表示するステップと、
（e）現在のカーソル・ツールを識別する情報を格納するツール・サーバ・オブジェクトを作成するステップであって、該情報はツール・オブジェクトと該ツール・オブジェクトに関連付けられるべきツール・カーソル・グラフィックとを含むステップと、
（f）複数のコントロールを含むツール・パレットを前記ディスプレイ上に表示するステップであって、各コントロールはカーソル・ツールを表すステップと、
（g）前記現在のカーソル・ツールを設定するために前記ツール・パレット内のコントロールが前記マウスにより選択されたとき、ツール・オブジェクトおよび該ツール・オブジェクトに関連付けられるべきツール・カーソルを前記ツール・パレットから前記ツール・サーバ・オブジェクトへ送るステップと
を備え、前記フレームの各々はビュー・オブジェクトにより表示され、ステップ（b）は、
（b1）前記カーソルが前記フレームの１つに位置するとき、前記ツール・サーバのツール・ネゴシエータ・オブジェクトを作成するステップであって、前記ツール・ネゴシエータ・オブジェクトはカーソル・ツール・オペレーションを実行する前記手段が動作できるデータ・タイプのリストを含むステップと、
（b2）前記ツール・ネゴシエータ・オブジェクトを前記ビュー・オブジェクトに送信するステップと、
（b3）前記ツール・ネゴシエータ・オブジェクトを使用して、カーソル・ツール・オペレーションを実行する前記手段が前記１つのフレームに表示されたデータ・タイプ上で動作できるかどうかを判断するために、前記リスト内のデータ・タイプ情報を前記１つのフレームに表示されたデータのデータ・タイプと比較するステップと
を有することを特徴とする方法。 - 請求項１に記載の方法において、プロセス境界が前記ツール・サーバ・オブジェクトおよび前記ビュー・オブジェクトの間で発生することを特徴とする方法。
- ディスプレイ、該ディスプレイ上に複数のフレームを生成し、各フレーム表示データはデータ・タイプを有する手段およびマウスの動作に応答して前記ディスプレイ上にカーソルを生成する手段においてカーソル・ツール・オペレーションを実行する方法であって、
（a）カーソル・ツール・オペレーションを実行する手段と、カーソル・ツール・オペレーションを実行する前記手段が動作できる少なくとも１つのデータ・タイプを識別するデータ・タイプ情報とを含むツール・オブジェクトを作成するステップと、
（b）前記カーソルが前記フレームの１つに位置するとき、前記ツール・オブジェクトを使用して、前記ツール・オブジェクトのデータ・タイプ情報を前記１つのフレームに表示されたデータのデータ・タイプと比較することにより、カーソル・ツール・オペレーションを実行する前記手段が前記１つのフレーム上に表示されたデータ・タイプ上で動作できるかどうかを判断するステップと、
（c）カーソル・ツール・オペレーションを実行する前記手段が前記１つのフレームに表示されたデータ・タイプにより動作できるとき、前記カーソルの下で表示されたデータを修正するステップと、
（d）カーソル・ツール・オペレーションを実行する前記手段が前記１つのフレーム上に表示されたデータ・タイプにより動作できないとき、所定のデフォルト・カーソルを表示するステップと、
（e）現在のカーソル・ツールを識別する情報を格納するツール・サーバ・オブジェクトを作成するステップであって、該情報はツール・オブジェクトと該ツール・オブジェクトに関連付けられるべきツール・カーソル・グラフィックとを含むステップと、
（f）複数のコントロールを含むツール・パレットを前記ディスプレイ上に表示するステップであって、各コントロールはカーソル・ツールを表すステップと、
（g）前記現在のカーソル・ツールを設定するために前記ツール・パレット内のコントロールが前記マウスにより選択されたとき、ツール・オブジェクトおよび該ツール・オブジェクトに関連付けられるべきツール・カーソルを前記ツール・パレットから前記ツール・サーバ・オブジェクトへ送るステップと
を備え、前記フレームの各々はビュー・オブジェクトにより表示され、かつ前記マウスを使用して選択することができ、ステップ（b）は、
（b1）前記フレームの１つが選択されたときに前記ツール・サーバのツール・ネゴシエータ・オブジェクトを作成するステップであって、前記ツール・ネゴシエータ・オブジェクトは、前記カーソル・ツール・オペレーションを実行するインタラクタ・オブジェクトと、前記インタラクタ・オブジェクトが動作できるデータ・タイプのリストとを含むステップと、
（b2）前記ツール・ネゴシエータ・オブジェクトを前記ビュー・オブジェクトへ送るステップと、
（b3）前記インタラクタ・オブジェクトが前記１つのフレームに表示されたデータ・タイプ上で動作できるかどうかを判断するために、前記ツール・ネゴシエータ・オブジェクトを使用して、前記リスト内のデータ・タイプ情報を前記１つのフレームに表示されたデータのデータ・タイプと比較するステップと、
（b4）前記インタラクタが動作できるデータ・タイプを前記１つのフレームが含むとき、前記インタラクタ・オブジェクトを使用して、前記１つのフレーム内のデータを変更するステップと
を有することを特徴とする方法。 - 請求項３に記載の方法において、ステップ（b4）は、前記インタラクタを前記ビュー・オブジェクトに提供し、前記インタラクタ・オブジェクトが前記１つのフレーム内のデータを変更できるようにするステップを有することを特徴とする方法。
- ディスプレイ、該ディスプレイ上に複数のフレームを生成し、各フレーム表示データはデータ・タイプを有する手段およびマウスの動作に応答して前記ディスプレイ上にカーソルを生成する手段においてカーソル・ツール・オペレーションを実行する装置であって、
カーソル・ツール・オペレーションを実行するインタラクタ・オブジェクトと、前記インタラクタ・オブジェクトが動作できる少なくとも１つのデータ・タイプを識別するデータ・タイプ情報とを含むツール・オブジェクトと、
前記カーソルが前記フレームの１つに位置するとき、前記ツール・オブジェクトを使用して、前記ツール・オブジェクトのデータ・タイプ情報を前記１つのフレームに表示されたデータのデータ・タイプと比較することにより、前記インタラクタ・オブジェクトが前記１つのフレーム上に表示されたデータ・タイプ上で動作できるかどうかを判断する手段と、
前記インタラクタ・オブジェクトが前記１つのフレームに表示されたデータ・タイプにより動作できるとき、前記カーソルの下で表示されたデータを修正する手段と、
前記インタラクタ・オブジェクトが前記１つのフレーム上に表示されたデータ・タイプにより動作できないとき、所定のデフォルト・カーソルを表示する手段と、
現在のカーソル・ツールを識別する情報を格納するツール・サーバ・オブジェクトであって、該情報はツール・オブジェクトと該ツール・オブジェクトに関連付けられるべきツール・カーソルとを含むサーバ・オブジェクトと、
複数のコントロールを含むツール・パレットを前記ディスプレイ上に表示する手段であって、各コントロールはカーソル・ツールを表す手段と、
前記現在のカーソル・ツールを設定するために前記ツール・パレット内のコントロールが前記マウスにより選択されたとき、ツール・オブジェクトおよび該ツール・オブジェクトに関連付けられるべきツール・カーソルを前記ツール・パレットから前記ツール・サーバ・オブジェクトへ送る手段と
を備え、前記フレームの各々はビュー・オブジェクトにより表示され、前記ツール・オブジェクトを使用して、前記インタラクタ・オブジェクトが前記１つのフレームに表示されたデータ・タイプで動作できるかどうか判断する前記手段は、
前記カーソルが前記フレームの１つに位置するとき、前記ツール・サーバのツール・ネゴシエータ・オブジェクトを作成する手段であって、前記ツール・ネゴシエータ・オブジェクトは実行インタラクタ・オブジェクトが動作できるデータ・タイプのリストを含む手段と、
前記ツール・ネゴシエータ・オブジェクトを前記ビュー・オブジェクトに送信する手段と、
前記ツール・ネゴシエータ・オブジェクトを使用して、前記インタラクタ・オブジェクトが前記１つのフレームに表示されたデータ・タイプ上で動作できるかどうかを判断するために、前記リスト内のデータ・タイプ情報を前記１つのフレームに表示されたデータのデータ・タイプと比較する手段と
を有することを特徴とする装置。 - 請求項５に記載の装置において、プロセス境界が前記ツール・サーバ・オブジェクトおよび前記ビュー・オブジェクトの間で発生することを特徴とする装置。
- ディスプレイ、該ディスプレイ上に複数のフレームを生成し、各フレーム表示データはデータ・タイプを有する手段およびマウスの動作に応答して前記ディスプレイ上にカーソルを生成する手段においてカーソル・ツール・オペレーションを実行する装置であって、
カーソル・ツール・オペレーションを実行するインタラクタ・オブジェクトと、前記インタラクタ・オブジェクトが動作できる少なくとも１つのデータ・タイプを識別するデータ・タイプ情報とを含むツール・オブジェクトと、
前記カーソルが前記フレームの１つに位置するとき、前記ツール・オブジェクトを使用して、前記ツール・オブジェクトのデータ・タイプ情報を前記１つのフレームに表示されたデータのデータ・タイプと比較することにより、前記インタラクタ・オブジェクトが前記１つのフレーム上に表示されたデータ・タイプ上で動作できるかどうかを判断する手段と、
前記インタラクタ・オブジェクトが前記１つのフレームに表示されたデータ・タイプにより動作できるとき、前記カーソルの下で表示されたデータを修正する手段と、
前記インタラクタ・オブジェクトが前記１つのフレーム上に表示されたデータ・タイプにより動作できないとき、所定のデフォルト・カーソルを表示する手段と、
現在のカーソル・ツールを識別する情報を格納するツール・サーバ・オブジェクトであって、該情報はツール・オブジェクトと該ツール・オブジェクトに関連付けられるべきツール・カーソルとを含むサーバ・オブジェクトと、
複数のコントロールを含むツール・パレットを前記ディスプレイ上に表示する手段であって、各コントロールはカーソル・ツールを表す手段と、
前記現在のカーソル・ツールを設定するために前記ツール・パレット内のコントロールが前記マウスにより選択されたとき、ツール・オブジェクトおよび該ツール・オブジェクトに関連付けられるべきツール・カーソルを前記ツール・パレットから前記ツール・サーバ・オブジェクトへ送る手段と
を備え、前記フレームの各々はビュー・オブジェクトにより表示され、かつ前記マウスを使用して選択することができ、前記ツール・オブジェクトを使用して、前記インタラクタ・オブジェクトが前記１つのフレームに表示されたデータ・タイプで動作できるかどうか判断する前記手段は、
前記フレームの１つが選択されたときに前記ツール・サーバのツール・オブジェクトからツール・ネゴシエータ・オブジェクトを作成する手段であって、前記ツール・ネゴシエータ・オブジェクトは、前記カーソル・ツール・オペレーションを実行するインタラクタ・オブジェクトと、前記インタラクタ・オブジェクトが動作できるデータ・タイプのリストとを含む手段と、
前記ツール・ネゴシエータ・オブジェクトを前記ビュー・オブジェクトへ送る手段と、
前記インタラクタ・オブジェクトが前記１つのフレームに表示されたデータ・タイプ上で動作できるかどうかを判断するために、前記ツール・ネゴシエータ・オブジェクトを使用して、前記リスト内のデータ・タイプ情報を前記１つのフレームに表示されたデータのデータ・タイプと比較する手段と、
前記インタラクタが動作できるデータ・タイプを前記１つのフレームが含むとき、前記インタラクタ・オブジェクトを使用して前記１つのフレーム内のデータを変更する手段とを有することを特徴とする装置。 - 請求項７に記載の装置において、前記インタラクタ・オブジェクトを使用して前記１つのフレーム内のデータを変更する前記手段は、前記インタラクタを前記ビュー・オブジェクトを提供し、前記インタラクタ・オブジェクトが前記１つのフレーム内のデータを変更できるようにする手段を有することを特徴とする装置。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US15062793A | 1993-11-09 | 1993-11-09 | |
| US08/150,627 | 1993-11-09 | ||
| PCT/US1994/000011 WO1995013578A1 (en) | 1993-11-09 | 1994-01-03 | Object-oriented cursor tool |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007166995A Division JP4339376B2 (ja) | 1993-11-09 | 2007-06-25 | オブジェクト指向カーソル・ツール |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH09504897A JPH09504897A (ja) | 1997-05-13 |
| JP4043509B2 true JP4043509B2 (ja) | 2008-02-06 |
Family
ID=22535359
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP51378095A Expired - Lifetime JP4043509B2 (ja) | 1993-11-09 | 1994-01-03 | オブジェクト指向カーソル・ツール |
| JP2007166995A Expired - Lifetime JP4339376B2 (ja) | 1993-11-09 | 2007-06-25 | オブジェクト指向カーソル・ツール |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007166995A Expired - Lifetime JP4339376B2 (ja) | 1993-11-09 | 2007-06-25 | オブジェクト指向カーソル・ツール |
Country Status (7)
| Country | Link |
|---|---|
| EP (1) | EP0693192B1 (ja) |
| JP (2) | JP4043509B2 (ja) |
| CN (1) | CN1130431A (ja) |
| AU (1) | AU6081594A (ja) |
| CA (1) | CA2154451C (ja) |
| DE (1) | DE69406120T2 (ja) |
| WO (1) | WO1995013578A1 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150025548A1 (en) | 2012-03-08 | 2015-01-22 | Neutar, Llc | Patient and Procedure Customized Fixation and Targeting Devices for Stereotactic Frames |
| JP6112968B2 (ja) | 2013-05-23 | 2017-04-12 | インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ | コマンド生成方法、装置及びプログラム |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS5150353A (ja) * | 1974-10-28 | 1976-05-01 | Shinetsu Chemical Co | |
| DE2830377A1 (de) * | 1978-07-11 | 1980-01-31 | Wacker Chemie Gmbh | Zu elastomeren vernetzbare massen, verfahren zu ihrer herstellung und eine verwendung der massen |
| US5142618A (en) * | 1986-11-21 | 1992-08-25 | Hitachi, Ltd. | Window management apparatus for a document creating apparatus |
| US5664210A (en) * | 1991-08-19 | 1997-09-02 | International Business Machines Corporation | Method and system of providing multiple selections in text on a computer display |
-
1994
- 1994-01-03 JP JP51378095A patent/JP4043509B2/ja not_active Expired - Lifetime
- 1994-01-03 WO PCT/US1994/000011 patent/WO1995013578A1/en active IP Right Grant
- 1994-01-03 EP EP94907130A patent/EP0693192B1/en not_active Expired - Lifetime
- 1994-01-03 CN CN94193272A patent/CN1130431A/zh active Pending
- 1994-01-03 AU AU60815/94A patent/AU6081594A/en not_active Abandoned
- 1994-01-03 CA CA002154451A patent/CA2154451C/en not_active Expired - Lifetime
- 1994-01-03 DE DE69406120T patent/DE69406120T2/de not_active Expired - Lifetime
-
2007
- 2007-06-25 JP JP2007166995A patent/JP4339376B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| EP0693192A1 (en) | 1996-01-24 |
| JP4339376B2 (ja) | 2009-10-07 |
| WO1995013578A1 (en) | 1995-05-18 |
| CA2154451C (en) | 2001-03-13 |
| DE69406120T2 (de) | 1998-04-02 |
| JPH09504897A (ja) | 1997-05-13 |
| DE69406120D1 (de) | 1997-11-13 |
| EP0693192B1 (en) | 1997-10-08 |
| AU6081594A (en) | 1995-05-29 |
| CN1130431A (zh) | 1996-09-04 |
| CA2154451A1 (en) | 1995-05-18 |
| JP2007293904A (ja) | 2007-11-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5912666A (en) | Object-oriented global cursor tool | |
| US6281896B1 (en) | Data processor controlled interface with multiple tree of elements views expandable into individual detail views | |
| US6097391A (en) | Method and apparatus for graphically manipulating objects | |
| US5459832A (en) | Method and apparatus for editing groups of graphic images | |
| EP0712513B1 (en) | Graphic editor framework system | |
| CA2118201C (en) | Photon windowing kernel | |
| JP3798015B2 (ja) | プレース・オブジェクト・システム | |
| US5621434A (en) | Cursor manipulation system and method | |
| US6397262B1 (en) | Window kernel | |
| US5850548A (en) | System and methods for visual programming based on a high-level hierarchical data flow model | |
| US5335320A (en) | Graphical user interface editing system | |
| US6836878B1 (en) | Visual programming from a tree structure | |
| US5764226A (en) | Reusable and modifiable data entry interface part | |
| EP0664028B1 (en) | Object-oriented system locator system | |
| US6151024A (en) | Data processor controlled display interface with tree hierarchy of elements view expandable into multiple detailed views | |
| US5848429A (en) | Object-oriented global cursor tool which operates in an incompatible document by embedding a compatible frame in the document | |
| US6111579A (en) | Data processor controlled display system with a tree hierarchy of elements view having virtual nodes | |
| US5479589A (en) | Object-oriented system for selecting a graphic image on a display | |
| US5790132A (en) | Image rendering system with extensible mechanism for providing visual user feedback when an image graphic is selected | |
| US5570281A (en) | Method and system for facilitating visual connections between objects using handles | |
| JP4339376B2 (ja) | オブジェクト指向カーソル・ツール | |
| US7712109B2 (en) | Dialog item interface definition object | |
| Muller et al. | The use of multimethods and method combination in a CLOS based window interface | |
| Berlage | OSF/Motif as a user interface standard | |
| GB2354415A (en) | Active graphics toolkit |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040517 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060606 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20060906 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20061023 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061206 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070327 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070625 |
|
| RD13 | Notification of appointment of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7433 Effective date: 20070625 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20070626 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070809 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20071026 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20071114 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101122 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101122 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101122 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111122 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111122 Year of fee payment: 4 |
|
| RD15 | Notification of revocation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: R3D15 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111122 Year of fee payment: 4 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: R3D02 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: R3D04 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111122 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121122 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121122 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131122 Year of fee payment: 6 |
|
| EXPY | Cancellation because of completion of term |