JPH08505968A - コンピュータ・システムでダイアログ・ボックスを実行する方法 - Google Patents

Abstract

(57)【要約】 ダイアログ・システムに関するもので、ダイアログ処理システムの方法と装置が開示されている。ダイアログは、システムの現在の状態を反映する変数を含んでいる。この中には、コマンドの状態（イネーブル／ディスエーブル）、その名称、その関連するグラフィック、およびその出現が現在妥当であるか否かを決定するステータス情報が含まれている。本発明によれば、コマンド・シーケンスを含むオブジェクトのデータ構造を含むダイアログが作成される。コマンドはコマンドのリストに追加され、ダイアログ・ボックスがユーザに表示される。あとで、ダイアログが処理されるとき、出現状態はシステム状態に基づいて再計算される。

Description

【発明の詳細な説明】 ダイアログ・システム 発明の分野 本発明は、一般的には、表示システムにおける改良に関し、さらに具体的には 、ダイアログ・ボックスを使用してユーザとやりとり（対話）することによって コマンドを処理することに関する。 背景技術 ワークステーション・ソフトウェアの開発者の間で、ユーザ・インターフェイ ス内の一貫性を維持しながらフレキシブルなソフトウェア環境を提供することの 重要性が増してきている。この種の動作環境を提供する初期の試みがヘルナンデ スらの米国特許第4,686,522号に開示されている。この特許はカーソルの位置に ある動的オブジェクトをユーザが引き出して、そのオブジェクトから種々の関数 を引き出すことができるグラフィックとテキストの結合処理システムについて議 論している。この種のユーザとの自然な相互作用あるいは対話はユーザ・インタ ーフェイスを改善し、アプリケーションをより直感的にする。 コマンドはまた、どのアプリケーションが現在アクティブであるかに拘わらず 、ユーザとの一貫したインターフェースを反映する必要がある。全てのコマンド が一貫した方法で機能することを可能にする革新的なハードウエア及びソフトウ エアシステムを提供することは、従来のどの公報の出願人も意図していない。 発明の概要 従って、本発明の主要目的は、コマンド・オブジェクトを使用してコントロー ル群の２つの独立した作用を制御することである。第１は、コントロールがデー タに即時に影響を与えるか、ユーザがOKを押さないとき、設定値が効力をもたな いようにするかである。第２は、コントロールが相互に独立しているか、あるい はコントロール設定値が結合されて、アトミック・オペレーション（atomic ope ration）を表しているかを区別するものである。 ダイアログ（dialog）は、コマンドの中でパラメータを設定するコマンドから 構成され、特定のパラメータを使用してコマンドが実行されるようにするもので ある。コマンドは、選択（selection）によって指定されたモデル・データに作 用する。 データに即時に影響を与えるコントロールは、リアル・モデル・データ（real model data）を指定する選 択を含むコマンドを含んでいる。ユーザがダイアログを操作すると、コマンドに よってそのデータが変更される。データが変更されると、ビュー（view）とコン トロールが、データの状態に応じて、データの現在状態を正確に反映するように 変更通知が送られる。 リアル・データが一時データに作用するまで一定に保たれるように設計された ダイアログは異なるアプローチを使用している。リアル・モデル・データは、ユ ーザがボタンを押すといった、別のアクションを行うまで変更されない。このア プローチを容易にするために、次のようなロジック（論理）が採用されている。 第１は、コントロールがそのコントロール自体を指定している選択を含んでいる 場合である。例えば、ユーザがコントロールを操作し、コマンドによってコント ロールの値が変更されたが、他のモデル・データが変更されなければ、ユーザが OKボタンを押すと、OKボタンのコマンドは、ユーザが変更した可能性のある各コ ントロールの値と一致するようにリアル・モデル・データを変更する。もう１つ は、OKボタンに含まれるコマンドのパラメータを指定している選択を含んでいる 場合である。ユーザがコントロールを操作すると、コマンドによってボタンのコ マンドが変更される。ユーザがボタンを押したとき、ボタンのコマンドは変更さ れ、リアル・モデル・データはそこに含まれる値と一致するように変更される。 相互に独立して作用するダイアログは、コントロール・パネル（control pane l）またはダイアログ・セッションが完了したあと、個別にバックアウトするこ とができるアクションを表している。これは、コマンドがコントロールによって 実行されたとき、コマンドが通常に示す挙動である。別のセットのダイアログは 一緒に働くように設計されており、アトミック・オペレーションとしてアンドゥ （undo -取消し）され、リドゥ（redo -再実行）される。この処理は、ダイアロ グ・ボックスの開始時に、アンドゥ・スタック上にマークを置くことによって行 われる。コントロール・パネルから出ることにより、あるいはユーザがOKボタン を押して処理が完了すると、アンドゥ・スタック上の、マークが置かれた以降に 実行されたコマンドは、すべて単一のコマンド・グループに集約される。このグ ループは、単一のグループとしてアンドゥまたはリドゥすることができる。 図面の簡単な説明 第1A図は、本発明のパーソナル・コンピュータ・システムのブロック図である 。 第1B図は、本発明による表示である。 第２図は、本発明によりアプリケーションを生成するために使用されるツール を示す。 第３図は、本発明によるコマンド・プロセスのフロー図である。 第４図は、本発明によるチェックボックス・コントロールである。 第５図は、本発明によるチェックボックス・コントロールの活性化を示す。 第６図は、本発明によるチェックボックスの更新を示す。 第７図は、本発明によるチェックボックス・コントロール処理の要約を示す。 第８図は、本発明によるコントロール・パネルを示す。 第９図は、本発明によるダイアログ・ボックスを示す。 第10図は、本発明によるダイアログ・ボックス・カラー・コントローラを示す 。 第11図は、本発明によるラジオ・ボタンを示す。 第12図は、本発明によるメニュー状態処理の詳細なフローチャートを示す。 第13図は、本発明による表示の絵を示す。 第14図は、本発明による原子実行の詳細論理を示す。 第15図は、本発明によるスマート・ラベル処理と関連する詳細論理を示す。 第16図は、本発明によるスマート・ウインドゥ・ラ ベル処理の詳細論理を示す。 第17図は、本発明により動かされ選択されることができるオブジェクトとの一 般的対話の間にどのようにしてオブジェクトが生成されるかとどのようにしてオ ブジェクトが相互に通信するかを示す。 第18図は、本発明による通知ソース・オブジェクトのためのオブジェクト生成 通知フローチャートである。 第19図は、本発明による適当なユーザ・インターフェイス要素を選択すること と関連する詳細論理を示すフローチャートである。 第20図は、本発明によるスクロールと関連する詳細論理を示すフローチャート である。 第21A図，第21B図，第21C図は、本発明によるウインドゥ・スクロールを示す 。 発明の詳細な説明 本発明は、IBM（登録商標）社のPS/2（登録商標）あるいはアップル（登録商 標）社のマッキントッシュ（登録商標）コンピュータのようなパーソナル・コン ピュータ上に駐在するオペレーティング・システムで実現されることが望ましい 。代表的なハードウェア環境を第1A図に示す。この図は、従来のマイクロ・プロ セッサのような中央演算装置10と、システム・バス12 に内部接続された多数の他のユニットを有する本発明のワークステーションの典 型的なハードウェア構成を示している。第1A図に示されるワークステーションは 、ランダム・アクセス・メモリ（RAM）14と、リード・オンリ・メモリ（ROM）16 と、ディスク・ユニット20のような周辺装置をバスに接続するためのI/Oアダプ タ18と、キーボード24、マウス26、スピーカー28、マイクロフォン32、および／ あるいはタッチ画面装置（図示せず）のような他のユーザ・インターフェイス装 置をバスに接続するためのユーザ・インターフェイス・アダプタ22と、ワークス テーションをデータ処理ネットワークに接続するための通信アダプタ34と、バス を表示装置38に接続するための表示アダプタ36とを具備している。ワークステー ションは、その上に駐在するIBM社のOS/2（登録商標）オペレーティング・シス テムあるいはアップルのシステム／７（登録商標）オペレーティング・システム のようなオペレーティング・システムを有する。 本発明は、オペレーティング・システムとエンド・ユーザ、開発者、およびシ ステム・ベンダのためのパーソナル・コンピュータの使用に革命をもたらすよう に意図された開発環境からなる新規なオブジェクト指向システム・ソフトウェア ・プラットフォームである。このシステムは、完全なスタンド・アローン・タイ プのネイティブ・オペレーティング・システムであ り、また高性能パーソナル・コンピュータのためのバックグラウンドから達成さ れた開発環境である。本発明は、フレームワークの価値、クラス・ライブラリお よび新世代オブジェクト指向プログラミング環境を含む完全なオブジェクト指向 システムであり、サードパーティのアプリケーション・ソフトウェアの開発の経 済性を基本的に改善するよう意図されている。本発明は完全にポータブルなオペ レーティング・システムである。 従来のオペレーティング・システムは、ソフトウェア開発者がソフトウェアを 創作するために使用できる１組のサービスを提供する。それらのプログラムはオ ペレーティング・システム環境全体の中に非常に緩く統合されている。例えば、 DOSアプリケーションはマシン全体を支配する。これは、ユーザに関する限り、 アプリケーションはオペレーティング・システムであることを意味する。マッキ ントッシュ（登録商標）およびウィンドウズ・オペレーティング・システムでは 、アプリケーションは同じように見え、それらはアプリケーション間での切り出 し（カット）と貼り付け（ペースト）をサポートしている。この共通化によりユ ーザが単一環境で多数のアプリケーションを使用することが容易となった。しか しながら、その共通化はサービスとフレームワークに組み入れられていないので 、ソフトウェアを開発することはまだ非常に困難で ある。 本発明では、“アプリケーション”を書くことは、オペレーティング・システ ム環境に統合されるオブジェクトの組を創造することを意味する。ソフトウェア 開発者は、ソフトウェアを開発するための複雑なサービスの組とフレームワーク の両方のためのオペレーティング・システムにたよることができる。本発明のフ レームワークは、ソフトウェア開発者が基盤を構築するよりはむしろ問題に集中 することを可能とする強力な抽象化を提供する。さらに、ソフトウェア開発者の ための基本的抽象化は、ユーザがソフトウェアを操作するために理解しなければ ならない基本的な概念に非常に近い。このアーキテクチャにより、複雑なアプリ ケーションの開発が容易となる。 このセクションでは、本発明を採用するソフトウェアを書くため４つのステッ プを述べる。アプリケーションの開発を意図するユーザは一般に以下の質問に関 心がある。 ・何をモデル化するか ワードプロセッサではこれは入力しようとするテキストであり、スプレッドシ ートではそれはセル内の値と公式である。 ・データをどのように表現し提供するか 再び、ワードプロセッサでは文字が適当な改行および改ページを用いて画面上 に“見るものが得るもの” （wysiwyg）形式で表示され、スプレッドシートでは表またはグラフとして表示 され、構造化グラフィック・プログラム（例えばマックドロー（MacDraw））で は、グラフィック・オブジェクトの組として表示される。 ・何が選択可能か ワードプロセッサアプリケーションでは、選択されるのは文字の範囲であり、 構造化グラフィック・プログラムではグラフィック・オブジェクトの組である。 ・この選択の上で動作するコマンドは何か ワードプロセッサではコマンドは文字のスタイルをボールドに変更することか もしれない。構造化グラフィック・プログラムにおけるコマンドはグラフィック ・オブジェクトを回転させることかもしれない。第1B図は本発明による表示を示 す。表示の前面にピクチャーをもってくるためのコマンドは41に描かれている。 グラフィック情報のプレゼンテーションは40に描かれている。最後に、特定のグ ラフィック・オブジェクト、円の選択が42に示されている。 開発者は、ユーザからたずねられる同じ４つの質問に答えなければならない。 幸運にも、本発明はこれら４つの質問の各々を志向するサービスとフレームワー クを提供する。答えられなければならない最初の質問は、何をモデル化するかで ある。ワードプロセッサ・プログラムではデータは文書を構成する文字を含む。 スプレッドシートでのデータはセル内の値と公式を含む。カレンダ・プログラム ではデータは時間と日付に関係するアポイントを含む。本発明は、データをモデ ル化するのを助ける道具を提供する。テキスト、構造化グラフィックス、サウン ド、および映像を含む特定のデータ形式をモデル化するためのクラスが存在する 。これらの特定のクラスに加えて、本発明は、コレクション・クラス、同一制御 、リカバリ・フレームワークおよびC++言語を含む、問題のモデル化をサポート する多数の他の抽象化を提供する。特定のデータ形式のためにデータ・モデルを カプセル化するクラスは、そのデータ・カプセルに含まれるデータをアクセスし 修正するための特定のプロトコルと、他のデータ・カプセルを埋め込み、他のデ ータ・カプセルに埋め込まれるためのジェネリックなプロトコルをオーバライド （override）にするためのサポートと、データが変わるときのすべての登録され たオブジェクトに対する通知と、データのプレゼンテーションを生成するための ジェネリックなプロトコルのオーバライドとを提供する。 答えなければならない次の質問はデータをどのように提供するかである。構造 化グラフィック・プログラムではグラフィック・オブジェクトの組は一般にキャ ンバス上に描かれる。スプレッドシートではそれは通常、セルの表あるいはグラ フである。プレゼンテー ション・プログラムではスライドの組あるいはアウトラインである。本発明は、 データ・カプセルに含まれるデータの“ながめ（ビュー、view）”を提供する。 ビューは“ビュー（view）システム”とグラフィック・システムのセルを用いて 生成される。しかしながら、サウンドあるいはビデオ・クリップを動作させるこ ともデータのプレゼンテーションとして考えられる。 次に、何が選択されるかである？ ワードプロセッサ・プログラムでは、選択されるのは文字の範囲であり、構造 化グラフィック・プログラムではグラフィック・オブジェクトの組である。スプ レッドシートではセルの範囲である。本発明は、システムがサポートする全ての 基本的なデータ形式のために選択クラスを提供する。ユーザによりなされた選択 を表す抽象ベース・クラスは選択されたデータの、アドレス空間から独立した指 定を提供する。テキストでは、これは文字に対する一対のポインタよりはむしろ 文字の数値範囲であるであろう。この限定は、他のユーザとの（リアルタイムで の）共同作業のとき、選択された範囲が他のマシーンとの間で交換されるので重 要である。ベース・クラスはまたジェネリック・プロトコルをオーバライドして 、この選択に対応する持続的選択を生成する。持続的選択はアンカー・オブジェ クトのサブクラスであり、持続的選択が変更の編集から生き延びなければならな いので、対応する短命 な選択より重いと考えられる。例えば、持続的テキスト選択は、テキストがその 前後に挿入されるときそれ自身を調整しなければならない。アンカーはハイパー メディアのリンク、データ・フローのリンクおよびアノテーションの実行に際し て使用される。 ベース・クラスはまた、データ・カプセル内に含まれるデータを吸収し、埋め 込み、送り出するためのオーバライド・ジェネリック・プロトコルを提供する。 ベース・クラスはそれらを生成するために使用されるユーザ・インターフェイス 技術から独立である。選択は、一般的に（例えばテキストの範囲あるいはセルを トラック（追尾）して）ユーザによる直接操作を介して生成されるが、スクリプ トを介してあるいはコマンドの結果として生成されてもよい。このユーザ・イン ターフェイスとの直交性が非常に重要である。ベース・クラスはまたデータ・カ プセルをアクセスするための特定のプロトコルを提供する。カプセル・クラスの 特定のサブクラスとモデル選択クラスのサブクラスとの間には非常に強い関連性 がある。 最後に、この選択された範囲について動作をすることができるコマンドは何か 。ワードプロセッサのプログラムでは、コマンドは文字の選択された範囲のスタ イルを変更するものでもよく、構造化グラフィック・プログラムではコマンドは グラフィック・オブジェクトを回転させるものでもよい。本発明は、多くのユー ザ・インターフェイス・コマンドと共に、カット、コピー、ペースト、ハイパー メディア・リンク・スタート、リンク完了、リンクの運行、リンク上でのデータ のプッシュ、リンク上でのデータのプルをするためのジェネリック・コマンドを 提供すると共に、全ての組込データ形式のための多数の組込コマンド・オブジェ クトを提供する。ユーザにより作られたコマンドを表すアブストラクト・ベース ・クラスは、ユーザ・アクションのセマンティクス（意味）を捉える責任を負い 、コマンドがドウ（do：実行）され、アンドゥ（undo：取り消し）され、リドゥ （redo：再実行）されることができかどうかを決定する。コマンド・オブジェク トは、コマンドがドゥされた後、コマンドをアンドゥするために必要な情報のす べてをカプセル化する責任を負う。コマンドが実行される前は、コマンド・オブ ジェクトは、ユーザ・アクションの非常にコンパクトな表現である。ベース・ク ラスは、それらを生成するために使用されるユーザ・インターフェイスの技術か ら独立である。コマンドはユーザによる直接の操作（例えば、グラフィック・オ ブジェクトの移動）を介して、あるいはメニューから一般に生成されるが、スク リプトを介して生成されることはできない。ユーザ・インターフェイスとの直交 性は非常に重要である。 フレームワークの利益 本発明内の抽象化にプラグを差し込む利益は、概念的モデルを提供するよりも 大きい。フレームワークにプラグを差すことはベース・オペレーティング・シス テム中に構成された多くの複雑な特徴を提供する。これは、比較的小さいメソッ ドをコールすることによりフレームワークが多数のユーザ特徴を実行することを 意味する。フレームワークのための符号化への投資がいくつかの特徴に渡って影 響をもたらす。 新種のデータが操作されると、新しいデータ形式がシステムの一部となる。デ ータのカプセルを取り扱うことができる既存のソフトウェアは修正無しに新しい データ形式を取り扱うことができる。これは、マッキントッシュ・コンピュータ ・システムのような現在のコンピュータ・システムとは異なる。例えば、スクラ ップ・ブック・デスク・アクセサリはある種のデータを格納することができるが 、テキストあるいはクイックドロー画像成分を有するデータを表示することがで きるだけである。対照的に、本発明のスクラップ・ブックは、オブジェクトの形 でデータを取り扱うので、あらゆる種のデータを表示する。生成された新しいデ ータ形式はシステム提供データ形式と全く同様に振る舞う。加えて、スクラップ ・ブック内のデータは、オブジェクトがデータを編集するための標準プロトコル を提供するので、編集可能である。 スクラップ・ブックの例はデータのカプセル化の長所を際立たせる。ソフトウ ェアがデータのカプセル化を扱うことができるように開発されていれば、アプリ ケーションを、新しいデータ形式を簡単に扱うように設計することができる。新 しいアプリケーションは修正無しに新しい形式のデータを表示し編集することが できる。 マルチレベル・アンドゥ 本発明はマルチレベル・アンドゥをサポートするように設計されている。この 特徴を折り込むことは、しかしながら、開発者の側に余分な努力を要求しない。 システムは、生成されるすべてのコマンド・オブジェクトを単に思い出すだけで ある。対応するコマンド・オブジェクトが存在する限り、ユーザは、データへの 特定の変更をアンドゥ、即ち取り消すことができる。システムが、コマンドを保 存し、どのコマンドをアンドゥあるいはリドゥ（再実行）すべきかを決定するの で、ユーザはアンドゥの手順を折り込まない。 データのカプセル化のプロトコルの一部は、データをストリームにファイルす ることと他の場所および／あるいは他の時間までデータを休ませることを行う。 システムは、このプロトコルを使用してドキュメントの保存を行う。デフォルト では、ユーザのデータ・オブジェクトは、保存されるときファイルに流される。 ドキュメントがオープンされているときは、データ・ オブジェクトは休まされる。システムは、データ管理フレームワークを使用して ディスクに書かれたデータが一貫性をもつ状態であることを確認する。ユーザは 、システムが壊れたときにデータがディスク上に保たれているように、しばしば ファイルを保存しようとする。システムがすべてのコマンド・オブジェクトを保 持するので、本発明はこの種の保存を必要としない。ドキュメントの状態は、ド キュメントの最新のディスクバージョンから始めて、その時点からのコマンド・ オブジェクトを再度与えることにより再構成することができる。信頼性のために 、システムはコマンド・オブジェクトが起動される毎にそれらをディスクに自動 的にログするので、システムが壊れたとしてもユーザは最後のコマンド以外失う ことはない。本発明はまたドキュメントのバージョン化をサポートする。ユーザ はドキュメントの現在の状態からドラフトを生成することができる。ドラフトは 特定の時点におけるドキュメントの不変の“スナップショット”である（ドラフ トを生成する１つの理由はコメントのために他のユーザにそれを回覧することで ある）。システムは新しいドラフトの生成に含まれる詳細を自動的に扱う。 協同作業 上記のように、ドキュメントは、ある過去の時の状態から始め、そのとき以降 なされたコマンド・オブ ジェクトのシーケンスを適用することにより再構築することができる。このため ユーザは故障の場合に仕事を回復することができ、リアルタイム協同作業をサポ ートすることができる。コマンド・オブジェクトは選択されたものについて動作 し、それらの選択されたものはアドレス空間に独立である。従って、選択された オブジェクトをネットワークを介して協同作業者に送ることができ、遠隔マシー ンで使用することができる。同じことがコマンド・オブジェクトについても言え る。１人の協同作業者が行ったコマンドを他の者に送り同じようにそれらの者の マシーンで実行することができる。協同作業者が同一のデータコピーから始める ならば、コピーは協同作業者が変更を行うにつれて“同期して”残る。選択の生 成はコマンド・オブジェクトを使用して行うので、すべての協同作業者は同じ現 在の選択をもつ。 システムは、“モデル・ペース・トラッキング”として知られている特徴を用 いて各協同作業者のマシーン上でマウス・トラッキングを行う。マウスの押下を 扱うように生成されたトラッカー・オブジェクトはユーザがマウスを動かすにつ れて一連のインクレメンタルコマンドを生成し実行する。これらのコマンドは協 同作業者に送られて各協同作業者により実行される。各協同作業者はそれが起き るにつれてトラッキング・フィードバックをビューすることになる。システ ムはまた共同作業ポリシーを確立する。共同作業ポリシーは、データに変更を加 えるときあるいは自由に変化するとき、ターンするように強制されるかどうかを 決定する。本発明はアプリケーション開発者から責任を取り除く共同作業マシー ンを取り扱う。 スクリプト コマンド・オブジェクトのシーケンスを管理するようにシステムを設計すると 、システムワイドのスクリプト道具を実行することが可能となる。コマンド・オ ブジェクトのシーケンスはローカルアクションのスクリプトと等価である。スク リプト機能は、あるドキュメントに適用されるコマンド・オブジェクトを単にト ラッキング（追尾）し続ける。スクリプト機能はまた、スクリプトに際して選択 オブジェクトを使用する。この機能は、適用する選択を変えることによりスクリ プトの注文化を提供する。コマンド・オブジェクトはそれらが特定の選択に適用 できるかどうかを示すためのプロトコルを含むので、システムはユーザのスクリ プトの変更が妥当であることを確認する。 ハイパーメディアのリンク アンカーとして知られている持続的な選択はリンク・オブジェクトにより接続 されることができる。リンク・オブジェクトは、その終点を形成する２つのアン カーへの参照を有する。システムでは、リンクは双方向であり、両端は等しい能 力を有する。リンクのよ り高いレベルの使用はリンクに方向を課すことができる。単一リンク・オブジェ クトは２つの標準的特徴、即ち運行とデータ・フローとをサポートする。ユーザ はリンクの一端から他端へ運行する。通常、これは指定アンカーを含み、持続的 な選択をハイライトとするドキュメントをオープンすることを含む。正確な振る 舞いは宛先でのアンカー・オブジェクトにより決定される。例えば、アニメーシ ョンへのリンクはアニメーションを演ずることができる。データベースクエリー へのリンクはクエリーを実行する。 また、リンクはデータ・フローを容易にする。リンクの一端で選択されたデー タは他端に転送され、そこで選択を置き換える。ほとんどの場合、その効果は、 ユーザが一端で選択をコピーし、他端へ運行するようにリンクを使用し、データ を貼り付けることと同じである。システムは、リンクの一端から他端への運行（ 例えば、宛先ドキュメントを置き、それをオープンし、宛先アンカーをビュー（ 視野）内にスクロールする等）が含まれる詳細を取り扱う。同様に、システムは 、リンクを横切るデータの転送の詳細を取り扱う。後者は、それが参照するデー タをアクセスし、修正するための選択のプロトコルを用いて実行される。 注釈（アノテーション） 本発明はシステムワイドの注釈の道具をサポートする。この道具により著者（ 使用者）は見直しのためド キュメントのドラフトを分配することができる。見直し者はドキュメントにポス ト・ノート（posted note）添付することができ、実行されたとき著者にドキュ メントを戻す。著者はポスト・ノートを調べ、それぞれについてアクションを取 る（著者はドキュメント内のポスト・ノートを生成することができる）。見直し 者が著者と同じソフトウェアをもつ必要はない。代わりに、見直し者は標準注釈 アプリケーションを使用することができる。このアプリケーションは著者のドラ フトからデータを読み、注釈可能なプレゼンテーションを生成する（そのような プレゼンテーションの生成は標準データ・カプセルプロトコルの一部である）。 見直し者は、ドキュメント内に選択を生成することができ、その選択にポスト ・ノートをリンクすることができる。ポスト・ノートと選択の間のリンクにより システムはそれが参照する選択に“近い”ポスト・ノートを位置決めすることが できる。リンクはまた注釈構造を明白にし、システムは注釈を処理するように標 準コマンドを実行することができる。ポスト・ノートの内容は、単なるテキスト あるいはグラフィックではなく、システム内で実行されるデータ形式でよい。ノ ートの内容はデータ・カプセルを用いて実行され、ノートをオープンすることは データの編集可能プレゼンテーションを生成することになる。 データ表現 データ表現は、モデル化するデータは何かとの質門への答えと関係する。本発 明はデータのモデル化を助ける道具を提供する。テキスト、構造化グラフィック ス、サウンドおよび映像を含めて、特定のデータ形式をモデル化するためのクラ スがある。これらの特定のクラスに加えて、本発明は問題をモデル化するのを助 ける多数の他の抽象化、コレクション（収集）クラス、同時の制御と回復フレー ムワーク、およびC++言語自身を提供する。本発明の主題では、特定データ形式 のためのデータ・モデルをカプセル化するクラスはカプセル化クラスのサブクラ スである。 カプセル化クラス（Encapsulator Class） 開発者は、カプセル化クラスから導かれるクラスを生成することにより特定形 式のデータ表現に対するコンテナを生成する。例えばグラフィック・オブジェク ト、様式化されたテキスト、スプレッドシートのセルのようなシステム内の各形 式のデータのために、ある形式のデータのためのコンテナとして働く異なる導か れたクラスが存在しなければならない。カプセル化クラスの各々は、それに含ま れるデータをアクセスし、修正するための形式の特定プロトコルを提供する。こ のプロトコルは、一般に、データを表示するためのプレゼンテーションにより、 またデータを修正するためのコマンドにより使用される。形式特定プロトコルに 加えて、カプセル化クラスは、“ブラック・ボックス”としてのデータ・カプセ ルの他のエイリアン（異なる見知らぬ）形式への埋め込みをサポートするジェネ リック・プロトコルを提供する。このプロトコルは導かれたクラスの中で実行さ れ、カプセル化データのためにプレゼンテーション、編集および選択の生成をサ ポートしなければならない。コンテナは、エイリアン・データ形式の埋め込みを サポートするように、このジェネリック・プロトコルを理解する必要があるにす ぎない。 データ表現の選択 データ形式の設計者は、特定形式のデータのための表現を設計するときに、C+ +オブジェクト・モデルと、選択されるべき豊富な標準クラスの組との両方をも っている。データを表現するためのユニークなクラスを設計する前に、本発明に より提供されるクラスが、常に考慮されるべきである。これにより、システム内 の既存のクラスに同様なあるいは同一の機能を提供する新しいクラスを生成する 無駄な努力を軽減することができる。これらのうちで最も基本となるのがC++オ ブジェクト・モデルである。設計者は、ユーザが扱うクラスを表現するためにユ ーザのメンタル（精神的）モデルに近づける１または２以上のクラスを生成する ことができる。 本発明の基本的なクラスはデータを表現する多くの 標準的な方法を提供する。収集クラスは、簡単な組から辞書までランク付けして 、メモリ内に関連付けられたオブジェクトを収集するための多数の方法を提供す る。持続的な間違いの少ないオブジェクトの収集を提供するためのディスクベー スの収集がまた使用可能である。グラフィック編集のような、２次元（2D）ある いは３次元（3D）のグラフィック・モデル化を必要とするデータ形式がまたサポ ートされている。多数の2Dと3Dのモデル化オブジェクトが変形され、マトリクス ・クラスおよび3Dカメラと共に提供される。同様に、本発明は全世界テキスト、 審美的なタイポグラフィおよび拡張可能なスタイル（様式）機構をサポートする 複雑なテキスト・データ形式を提供する。本発明はまた、サウンドおよび映像の ような時間ベースのメディアのためのサポートを提供する。複雑な時間制御機構 が使用可能であり、種々の形式の時間ベースメディア間の同期を提供する。 プレゼンテーション・プロトコル カプセル化クラスは、カプセル内に含まれるデータの種々のクラスのプレゼン テーションを生成するためのプロトコルを提供する。プレゼンテーションは、寸 描プレゼンテーション、“ブラウズ・オンリ”（拾い読み）プレゼンテーション 、選択可能プレゼンテーションおよび編集可能プレゼンテーションを含む。プレ ゼンテーションのためのサイズのネゴシエーション を行い、選ばれたサイズ内にデータを適応させるためのプロトコルがまた存在す る。このプロトコルを実行するカプセル化クラスのサブクラスは、他のカプセル へのデータの埋め込みをサポートする。現在サポートされているプレゼンテーシ ョンは、以下のものを含む。 ・寸描（Thumbnail）−このプレゼンテーションはユーザにカプセル内に何が 含まれているかを“ピーク”することができるように（覗くことができるように ）意図されている。一般にサイズは小さく、そのサイズに合うようにデータを縮 小および／あるいはクリップしてもよい。 ・拾い読み（Browse-only）−このプレゼンテーションによりユーザは通常の サイズでデータを見ることができるようになるが、いずれのデータも選択し修正 することはできない。 ・選択可能（Selectable）−このプレゼンテーションは、拾い読みプレゼンテ ーションにより提供される能力にデータを選択する能力を加える。データそれ自 身への修正を許すことなく、注釈がデータの選択に結びつけられることができる ように注釈の中で使用される。選択可能プレゼンテーションは、一般に拾い読み プレゼンテーションのサブクラスとして実行される。 ・編集可能（Editable）−このプレゼンテーション は、選択可能プレゼンテーションにより提供される能力にデータを修正する能力 を加える。これは、ユーザが新たなデータを生成し既存のデータを編集すること を可能とするプレゼンテーションである。現在、このプレゼンテーションはそれ 自身の編集のためのウインドゥを提供する。将来的にはその場で編集を可能とす るプレゼンテーションのためのサポートが加えられる。編集可能プレゼンテーシ ョンは一般に選択可能プレゼンテーションのサブクラスとして実行される。 変更通知 カプセル化クラスに含まれるデータが変更されたとき、クライアント（例えば データの使用者）に変更を通知する必要がある。カプセルは標準通知サポートの ための組込クラスにあり、カプセルがデータ表現への変更をクライアントに通知 することを可能とする。クライアントは、特定の変更についての通知あるいはす べての変更についての通知のためのカプセルに接続することができる。変更が起 きたとき、カプセルはすべての関連するクライアントに変更についての通知を伝 搬するように、このモデルに依頼する。 データのプレゼンテーション このセクションでは、どのようにしてシステムがデータをユーザにプレゼンテ ーションするかについて説明する。データが一旦システムに表現されると、適当 な意味ある方法でデータをユーザにプレゼンテーションすることがユーザ・イン ターフェイスの役割である。ユーザ・インターフェイスはユーザとモデル化デー タの間のダイアログを確立する。このダイアログはユーザがデータを見、あるい は他に知覚することを可能とし、ユーザにデータを修正あるいは処理する機会を 与える。このセクションはデータ表現に焦点を当てている。 ユーザ・インターフェイス 開発者は、データ・カプセルと相互作用するようにデータのプレゼンテーショ ンを容易にするクラスを生成する。プレゼンテーションからデータ・モデルを分 離することにより、本発明は同じデータの多数のプレゼンテーションを容易にす る。アップル社のマッキントッシュ・ファインダのようなアプリケーションは、 同一データを多数にプレゼンテーションすることを制限された形で既にサポート している。同じ時間に同じデータを異なる観点で表示することを可能とすること はある場合には有用である。これらの異なる観点は、同じデータの４つの異なる 観点を示す3DCADプログラムのような同じクラスのインスタンスであってもよ い。各種のプレゼンテーションのため、ユーザには、モデルを表示することがで きるビューと、モデルを選択し修正できるトラッキング（追尾）ツールと追尾コ マンドの組を前もって書くことを要求されていた。 静的プレゼンテーション 最も簡単なプレゼンテーション形式はデータの名称である。名称はデータの内 容あるいは形式を示すテキスト・ストリングである。例としては、“第４章”、 “1990年連邦税収”、“すべきこと”等がある。他の簡単なプレゼンテーション 形式であるアイコンは、データの小さいグラフィックプレゼンテーションである 。それは通常データ形式を示す。例としては、本、レポート、金融モデル、サウ ンドあるいは映像の記録、図面等がある。しかしながら、また、それらは印刷し ているプリンタのようなステータスを表示し、あるいは図面の縮尺図のような内 容を示してもよい。最後に、寸描プレゼンテーションはモデル・データの小さい ビューである。たとえば、縮尺された図、本の内容の表、縮尺された手紙、ある いは長い書類の縮尺された最初のページである。拾い読みプレゼンテーションは 、ユーザが通常のサイズでデータを見ることを可能とするが、データのいずれも 選択しあるいは修正することはできない。 選択可能プレゼンテーション 選択可能プレゼンテーションは、ユーザがデータを 見、調べ、データから情報を抽出することを可能とする。これらのプレゼンテー ションは、コンテクスト、即ち、何がデータか、データはどこか、データはいつ 生成されたかを提供する。それはリスト、グリッドのような構造化手法でデータ を外観としてあるいは部分的にプレゼンテーションするのを助けることができる 。それはまた、データ要素間の関係、データのコンテナあるいは同胞との関係、 あるいは他の依存性を表示するのに有用である。 選択可能プレゼンテーションはまたメタデータを表示することができる。例と しては、ユーザが現在処理しているデータ要素を示す現在選択がある。他の形式 のメタデータはデータ要素間のハイパーメディア・リンクである。ビューはまた 、データについて共同作業をしている他のユーザを示すことができる。 選択可能プレゼンテーションは、通常データ形式により非常に特定される。そ れらはウインドゥ、ビュー、およびデータ形式を最良に反映するようにカスタマ イズされたユーザ・インターフェイスオブジェクトからなる。いくつかの例は、 ・サウンドの記録−コントロール・パネルは可聴プレゼンテーションを実行す る。ビューは音楽のスコアとしてあるいは一連の波形としてサウンドを表す。ビ ューはサンプル番号あるいは時間表示を含む。 ・金融モデル−モデルは公式と他のパラメータの組 として見ることができる。時間についての特定のインスタンスで、あるいはスプ レッドシートのような特定の入力値で、あるいは種々のグラフィックなスタイル に、モデルからのデータを表すことができる。 ・本−モデルは、内容の表、インデックス、図のリストとしてみられることが できる。それは、一連のページ、一連の章、あるいは連続するテキストの流れと して見られることができる。 ・映像の記録−モデルは、一連の個々のフレーム、あるいは連続するプレゼン テーションとして見られることができる。ビューは追尾マーク、フレーム数、お よび時間表示を含む。 ・他のオブジェクトを含むコンテナ−オブジェクトは名称により、形式あるい は他の属性により、一連のアイコン、１組の寸描としてアルファベット順に表示 されることができる。 編集可能プレゼンテーション 編集可能プレゼンテーションは、データの修正を行うことを除いて、対話的プ レゼンテーションと同様である。編集可能プレゼンテーションは、マウスあるい は他のポインタでデータの直接の処理を可能とすることによりこれを行う。また 、データがメニュー項目と他のコントロールを介してシンボル的に処理されるこ とを可能とする。 データ・アクセス プレゼンテーションは、データとプレゼンテーションされるべき他の情報とを 決定するためにデータ・カプセルと相互に作用する（対話する）。プレゼンテー ションは要求されるデータをモデルにクエリー（照会）する。プレゼンテーショ ンは含まれるデータのすべてあるいは一部だけをプレゼンテーションしてもよい し、あるいはデータ・カプセルのデータから導かれてもよい。 変更通知 アクティブな単一のモデルの多くのプレゼンテーションが一時に存在すること ができるので、データは、協同作業者を含めて多くのソースから変更され得る。 モデル・データに関して、各プレゼンテーションは自身を更新し続ける責任があ る。これは、モデルのすべてあるいは部分が変更するとき、通知を登録すること により達成される。プレゼンテーションと関連するデータにある変更が生じたと き、プレゼンテーションは通知を受け取り、そのビューを更新する。変更通知は 以下にリストされている手法のいずれかで発生することが可能である。第１に、 変更通知は実際にモデル・データを変更するデータ・カプセル内のメソッドから 生成される。第２に、変更通知は変更を引き起こすコマンドから発生される。前 に述べたように、これら２つのアプローチには利益がある。データ・カプセ ル内から通知を発生することはデータが変化するときにはいつでもクライアント は通知されることを保証する。コマンドからの通知の発生は、“高級”通知を可 能とし、複雑な変更により生成される通知の混乱を減少させる。 通知フレームワーク外観 通知フレームワークは、オブジェクト間の変更情報を伝搬するための機構を提 供する。フレームワークは、オブジェクトが、それらが依存するオブジェクトに 関係することを表し、オブジェクトの変更についての通知を受け取ることを可能 とする。標準インターフェイスはクライアントに通知を提供するクラスのために 提供される。通知者クラスはクライアントのリストを管理しそれらのクライアン トに通知をデスパッチする手段を通知ソース・オブジェクトに提供する。通知者 オブジェクトは通知を受け取るオブジェクトのクラスについての特別の知識を要 求しない。接続オブジェクトは通知者オブジェクトからの通知のデスパッチを特 定の通知受信オブジェクトに提供する。これらの接続オブジェクトは通知が受信 者の異なるクラスにどのようにして配信されるかを特定することを可能とする。 最後に、通知オブジェクトは変更について記述した情報を輸送し、インタレスト は通知ソース・オブジェクトを記述する。 通知伝搬フローチャート 第18図は通知ソース・オブジェクトに対するオブジェクト発生識別フローチャ ートである。処理はターミナル1800で始まり、機能ブロック1810まですぐに通過 する。そこでは、通知受信者オブジェクトがそれ自身への接続を生成する。その 後、機能ブロック1820で、通知受信者オブジェクトは１またはそれ以上の通知ソ ース・オブジェクトからの１またそれ以上の通知に対して適切なインタレストを 加える。これらのインタレストは通知ソース・オブジェクトにより定義される。 クライアントオブジェクトは、機能ブロック1830、接続の際にインタレストに より特定される通知のために通知ソースに接続するよう接続オブジェクトに依頼 する。その後機能ブロック1840で、接続に際しての各インタレストでは、接続は インタレスト内の通知者との通知と関連するとして登録される。次に機能ブロッ ク1845で、システムは変更が検出されるまで待ち状態に入る。システム変更が起 きたとき、コントロールは直ちに1850まで通過し、そこで通知ソース・オブジェ クトは変化し、コールがその変更を記述する通知つきの通知者に通知する。 通知に関係する通知者と共に登録された各接続では、機能ブロック1860で、接 続は通知をデスパッチするよう依頼される。次に、機能ブロック1870では、接 続は通知受信者の適切なメソッドに通知をデスパッチする。最後に、機能ブロッ ク1880で、通知受信者は通知のための適切なアクションを起こし、テストが決定 ブロック1885で行われ、他の接続が通知に関係する通知者つきで登録されている か否かを決定する。他の接続が存在するときは、コントロールは1850に進む。サ ービスすべき他の接続が無いときは、コントロールは機能ブロック1845に進み、 次の変更を待つ。 データ仕様 データ仕様はデータ処理の選択を発行することを目的とする。ユーザが表現に 含まれるデータを処理しなければならないとき、データはそのデータのサブセッ トを特定できなければならない。ユーザは一般にこの仕様を“選択”と呼び、シ ステムはすべての選択クラスが降りたベース・クラスを提供する。本発明はまた システムがサポートする基本的データ形式のすべてのための選択クラスを提供す る。 モデル選択 表現内のデータのサブセットの仕様を含むオブジェクトはモデル選択クラスで ある。テキスト表現の場合には、ある可能な選択仕様は一対の文字オフセットで ある。構造化グラフィック・モデルでは、各形状にはユニークなIDが割り当てら れなければならず、選択仕様は１組のユニークなIDである。仕様のどれもが選択 データを直接ポイントせず、それらをデータの多数の コピーに適用することができる。 特定データのアクセス 選択は、データをアクセスし修正する表現プロトコルを理解し、ローカル・ア ドレス空間でデータを見つける方法を知る。コマンド・オブジェクトはデータ選 択を介して表現データをアクセスし、従って仕様からローカル・モデル内のリア ル・データに変換する知識を要求しない。それは選択オブジェクトの仕事であり 、アドレス空間独立仕様からリアル・データへのアクセスを提供する。テキスト ・カプセルでは処理はある範囲内に含まれる実際の文字に対するカプセルをクエ リーすることを要求できる。グラフィック・エディタのようなベース・モデルで は、選択はリアル・オブジェクトの代用物を保持する。カプセルはリアル・オブ ジェクトへ代用物を変換するためのルックアップ道具を提供する。 標準編集プロトコル モデル選択クラスは選択間のデータの交換のためのプロトコルを提供する。形 式ネゴシエーション、データの吸収、埋め込み、および運び出しを行うためのプ ロトコルを実行することにより、導かれたクラスは標準編集コマンドのほとんど のサポートを提供する。これは、システムにより提供される（カット、コピー、 ペースト、データをプッシュ等の）編集コマンドが、表現されたデータ形式のた めに機能し、各アプリケー ションの再実行を要求しないということを意味する。モデル選択クラスは、また 、アンカーとリンクの交換のために直接にサポートを提供するが、表現データの 交換をサポートするためいくつかのキーメソッドの導かれたクラスの実行上にあ る。 CopyDataは、導かれたクラスにより実行されなければならず、特定データのコ ピーを運び出す。実行は特定データのコピーを含む要求され形式の新たなデータ ・カプセルを生成してリターンする。 AdoptDataは、仕様に関連する表現にデータを吸収しあるいは埋め込むことを サポートするように導かれたクラスにより実行されなければならない。データが 吸収されるべきならば、それは受信者の表現に直接組み込まれることができる形 式でなければならない。吸収されたデータは仕様で定義されたように表現に加え られる。多くのデータ形式に対して現在特定されているデータを新たに吸収しデ ータで置き換えることは共通である。いずれかの置換されたデータはアンドゥを サポートするようにデータ・カプセルに戻される。データが埋め込まれるべきな らば、カプセルはブラック・ボックスとして組み込まれ、表現の子として加えら れる。 ClearDataは、関連する表現から特定されたデータをデリートするように導か れたクラスにより実行されなければならない。デリートされたデータを含む表現 の元来の形式のカプセルは戻されなければならない。 ユーザ・インターフェイス 仕様を生成するユーザ・インターフェイスは一般にはデータの表現の応答性で ある。多数の機構がデータ形式とプレゼンテーション・スタイルに基づいて使用 可能である。選択を生成するための最も好ましいユーザ・インターフェイスは直 接実行である。簡単なグラフィック・モデルでは、マウスでオブジェクトを直接 クリックしあるいはマウス・トラッカーを用いていくつかのオブジェクトを横切 って選択ボックスをドラッグすることによりオブジェクトを選択することができ る。テキストでは、選択はファインド・コマンドの結果として生成することがで きる。選択が生成される他の共通の手法は、“ファインド”のようなメニューコ マンドの結果としてである。コマンドが発行されたあと、ドキュメントは適切な 場所にスクロールされ、サーチされたテキストが選択される。 最後に、選択はスクリプトから生成され（あるいはプログラム的に発生され） る。その結果はユーザが直接選択を生成したかのようである。スクリプトのため の“名称付け”選択は選択を記述するための言語を生成することを含む。例えば 、テキストでは、選択は“２ページの第４節の２番目の語”である。本発明のア ーキテクチャはスクリプトのためのサポートを提供 する。 データの修正 データ修正（Data Modeification）は質問を発する。：この選択に関して動作 することができるコマンドは何か？ ユーザが表現内に含まれるデータを修正すべきとき、システムはなされるべき 修正の形式を正確に特定できなければならない。例えば、ワードプロセッサ・プ ログラムでは、ユーザは選択された範囲の文字のスタイルを変更することを望む ことができる。あるいは、構造化グラフィック・プログラムでは、ユーザはグラ フィック・オブジェクトの回転を望むことができる。データ・カプセルに含まれ るデータを修正するすべてのユーザのアクションは、“コマンド・オブジェクト ”により表現される。 モデル・コマンド・オブジェクト ユーザによりなされたコマンドを表すアブストラクト・ベース・クラスはモデ ル・コマンド・オブジェクトである。モデル・コマンド・オブジェクトのサブク ラスはドゥ、アンドゥ、リドゥされることができるというようなユーザ・アクシ ョンの意味を捉える。これらのサブクラスはそれらを生成するために使用される ユーザ・インターフェイス技術から独立している。MacAPPと異なり、ユーザ・ア クションの意味が知られるとすぐに、デバイス・イベントがシステムによりコ マンド・オブジェクトに翻訳される。 HandleDo（HandleDo）、 ハンドル・アンドゥ（HandleUndo）、 ハンドル・リドゥ（HandleRedo） 新しいクラスのコマンドを生成することは多数のメソッドをオーバライド（ov erride）することを含む。オーバライドするための最も重要な３つのメソッドは 、Handledo、HandleUndo、およびHandleRedoである。HandleDoメソッドは、その ままであるコマンド形式とそのコマンドが適用される選択とに基づいて適切にデ ータ・カプセルを変更するように応答可能である。例えば、ワードプロセッサに おいてコマンドがある範囲の文字に対するスタイル変更を含むならば、HandleDo メソッドはこのコマンドのあとに“アンドゥ（Undo）”する必要のある情報のす べてを保存する。スタイルの変更の例では、アンドゥ（undo）情報の保存は文字 範囲の旧スタイルを記録することも含む。ほとんどのコマンドに対するアンドゥ 情報は保存が非常に簡単である。しかしながら、ファインドおよび変更のような いくらかのコマンドは大量の情報を記録したあとでコマンドをアンドゥすること を含む。最後に、HandleDoメソッドは、データ・カプセルになされる変更を記述 する変更通知を発行する。 HandleUndoメソッドはコマンドが“ドゥ”される（done）前にそうであった状 態にドキュメントを戻す。 適用されなければならないステップは上記のHandleDoでなされたステップと同様 である。HandleRedoメソッドは、ドウ（do）され、そしてアンドゥ（undo）され たあとコマンドを“リドゥ（redo）”する。ユーザはしばしばアンドゥ／リドゥ （undo/redo）の組み合わせを用いてコマンドの結果を比較して、ドキュメント の２つの状態の間をいったりきたりする。一般に、HandleRedoメソッドは、Redo メソッドにおいて、最後に導かれた情報がこのコマンドが完了したとき再使用さ れることがきることを除いてHandleDoメソッドと非常に近い（情報は同じである ことが保証されるので、再計算する必要はない）。 ユーザ・インターフェイス コマンド・オブジェクトは、ユーザ・アクションの意味を捉える。実際、コマ ンドは（種々のユーザ・インターフェイス技術を用いて）ユーザにより最も多く 生成されるが、同様に他の手法で生成することができる“ワーク・リクエスト” を表す。重要な概念は、コマンド・オブジェクトがデータ・カプセルに含まれる データを修正するための唯一の手段を表すことである。データ・カプセルへのす べての変更は、無限のアンドゥの利益、保存無しのモデル、本発明の他の特徴が 実現されるべきならば、コマンド・オブジェクトにより処理されなければならな い。 コマンドを発行する最も好ましいユーザ・インター フェイスは、ある種の直接操作を含む。デバイス・イベントをコマンドに翻訳し 、ユーザ・フィードバック・プロセスを“ドライブ”するように応答可能なオブ ジェクトはトラッカーとして知られている。本発明は組込データ形式を処理する ための“トラッキング・コマンド”の豊かな組を提供する。例えば、直線、曲線 、多角形等のような“ピンク（Pink）”において2Dオブジェクトのすべてを回転 させ、スケーリングして、動かすためのトラッキング・コマンドがある。 コマンドを発行するための共通のユーザ・インターフェイスはメニュー・シス テムからあるいはコントロールを介している。メニューは生成され関連するコマ ンドの組がメニューに加えられる。ユーザがメニュー内の項目を選ぶとき、適切 なコマンドが“クローン（複製）”され、コマンドのドゥ・メソッドがコールさ れる。プログラマはデバイス・イベントに巻き込まれない。さらに、コマンドは それらが適用されることができる選択の形式が何かを知っているので、メニュー 項目はそれらが適切でないとき自動的に薄暗くさせられる。 最後に、コマンドはスクリプトから発行することができ（あるいはプログラム 的に発行することができ）、その結果はユーザがコマンドを直接発行したときと 同様である。“ピンク”アーキテクチャはスクリプトするためのサポートを提供 する。しかしながら、 この時点ではこれらのスクリプトを生成するために使用可能なユーザ・インター フェイスはない。 組込コマンド 本発明は、多くのユーザ・インターフェイス・コマンドと同様に、カット、コ ピー、ペースト、ハイパーメディア・リンクのスタート、リンクの完了、リンク の運行、リンクに関するデータのプッシュ、リンクに関するデータのプルのため のジェネリック・コマンドを提供することに加えて、全ての組込データ形式のた めの多数の組込コマンド・オブジェクトを提供する。 他の特徴 このドキュメントの前のセクションは、本発明の基本的な特徴に焦点を当てた 。本発明には、さらに進んだ特徴を実行する多くの追加される道具がある。特に 、これらの道具は、モデルベースのトラッキング（追尾）、ファイリング、アン カー、および共同作業を含む。 モデル・ベース・トラッキング トラッキング（追尾）は、直接処理ユーザ・インターフェイスの心臓部である 。トラッキングにより、ユーザは、テキストの範囲を選択し、オブジェクトをド ラッグし、オブジェクトを再サイズ調整し、オブジェクトを描くことが可能とな る。本発明は、モデルを実際に修正することにより多数のビュー（表示）、 および多数のマシーンに渡る機能にトラッキングを拡張する。トラッカーは、モ デルにコマンドを発行し、モデルはすべての関係するビューへ変更通知を発行す る。 モデル・ベース・トラッキングは、ドキュメント内でトラッキングするための 最良の解決策であるが、それは、以下の欠点を有する。（1）モデル・ビューを 、変更イベントへの急速応答を提供するように最適化しなければならない。（2 ）モデルは中間トラック状態を表すことができなければならない。 アンカー（Anchors） 持続性選択即ち“アンカー”はデータの仕様を表現する点で選択と非常によく 似ている。違いは、アンカーはデータへの変更に渡って維持されるので、アンカ ーは編集変更を生き続けなければならない点である。ドキュメントの初期で述べ たグラフィック選択の実行は持続的である。しかしながら、テキスト選択の実行 はない。ユーザが選択の前にテキストを挿入しあるいはデリートするならば、文 字オフセットを調整しなければならない。テキストアンカーを実行するためには ２つのアプローチがある。第１に、テキスト表現は、スタイルが維持される手法 と同様に、テキスト内を指すマーカーの集まりを維持する。アンカーはマーカー を参照するユニークなIDを含む。テキストが変更されたとき、マーカーはユニー クにされるが、アン カーは同じままである。他のアプローチは、テキストに対する編集履歴を維持す ることである。アンカーは時間スタンプと同様に１対の文字位置を含むことがで きる。テキストが編集される毎に、履歴は更新され、変更（例えば、時間Ｔに位 置Ｘからデリートされた５文字）を記録する。アンカーが使用されるとき、シス テムは、最後に使用されたとき以来起きた編集変更に基づいて文字位置を補正し なければならない。適切な時に、履歴は凝縮され、アンカーは永久的に更新され る。 システムは、アンカー道具を介して“フリー”のための非常に多数の特徴を提 供する。ハイパーメディア・コマンドのすべて（CreateLink、PushData、PullDa taおよびFollow）は、それらの実行時にアンカーを使用する。システム中の注釈 道具実行時にアンカーを使用する。ベース・データ・カプセルはアンカーとリン クの追尾を保つサービスを提供する。しかしながら、ユーザは、アンカーをプレ ゼンテーションを介してユーザに見えるようにする。アプリケーションはまたユ ーザがアンカーを選択するとき適当なコマンド・オブジェクトを発行しなければ ならない。アンカーとリンクのためのユーザ・インターフェイスが釘付けにされ たあと、ドキュメント・フレームワークは処理を簡略化するよう付加的サポート を提供する。 ファイリング ファイリングはデータを永久格納に保存しあるいは永久格納から再生するプロ セスである。ユーザがファイリング作業をするためにしなければならないことは 、データ・カプセルのための一連の操作を実行することのみである。本発明のデ フォルト・ファイリングは”イメージ”ベースである。ユーザがドキュメントを 開くとき、ドキュメントの内容全体はメモリに読み出される。ユーザがドキュメ ントを閉じるとき、ドキュメントの内容の全体がディスクに書き込まれる。この アプローチは、簡単で、フレキシブルで、理解しやすいので採用された。異なる フォーマットでデータを格納するためには、前もって存在する標準のファイル・ フォーマットとの互換性を保つために、２つのアプローチが可能である。第１に 、カプセル・クラスは実際のデータへの参照を一連の流れとすることができ、実 際のデータを見つけるために参照を使用することができ、あるいは新しいサブク ラスがファイル・サブクラスを生成し、リターンするように定義することができ る。 第１のアプローチの長所はデータ・カプセル型のドキュメント内でカプセル化 することができることである。第２のアプローチの長所は、完全なドキュメント のための既存のファイル・フォーマットに正確に適合するようにした完全な自由 である。 共同作業 同時ネットワーク共同作業は、２人あるいはそれ以上の人が同時に同じドキュ メントを編集することを意味する。システムはまた共同作業ポリシーを確立する 。即ち、ユーザがデータを変更するときあるいは自由に変更させるとき後退させ られるかどうかである。開発者は共同作業ポリシーあるいは共同作業の機構を心 配する必要はない。 協同作業選択スタイルのサポート 混乱の減少を助けモデル選択を増強するため、ドキュメント・アーキテクチャ は協同作業者のイニシャルと望ましいハイライトの束について情報を含む協同作 用者クラスを提供する。 多数選択のサポート 多数の選択をサポートするために、ユーザは、各協同作業者が選択を有するの でプレゼンテーション・ビューを修正しなければならない。アクティブな協同作 業者の選択が変わるとき、標準変更通知が送られる。受動的協同作業者の選択が 変わるとき異なる通知イベントが送られる。ビューは両方のイベントのために登 録すべきである。どちらかのイベントに応答して取られたアクションも通常同じ なので、両方のイベントのために同じハンドラー・メソッドを登録することによ り経済性が実現される。 本発明によるユーザ・インターフェイス 本発明のこの部分は、基本的に、先に議論されたオペレーティング・システム ・フレームワークの基本上に構築するユーザ・インターフェイスの観点に焦点が 絞られる。ユーザ・インターフェイスの第１の観点はユーザがコントロールとし て参照する種々のオブジェクトあるいはデータとの対話（相互作用）を管理する ことを可能とする機構である。 コントロール ユーザが他のオブジェクトあるいはデータを処理するよう対話するオブジェク トはコントロールと呼ぶ。コントロールはオブジェクトあるいはデータの現在の 状態を決定するためのコマンドを使用する。ユーザとの適切な対話に続いて、コ ントロールはコマンド・パラメータを更新し、それが実行されるようにする。コ ントロールの例はメニュー、ボタン、チェックボックス、およびらラジオ・ボタ ンである。 コントロールはオブジェクトあるいはデータの現在の状態を決定するためにコ マンドを使用する。ユーザとの適切な対話に続いて、コントロールはコマンド・ パラメータを更新し、それが実行されるようにする。例えば、チェックボックス はコマンド・パラメータをオンにあるいはオフにセットし、データ値を変更する ためにコマンドを実行する。 多くのコントロールはそれらが処理をするデータの 現在の値を表示する。例えば、チェックボックスはブール（代数）データ値が真 （TRUE）のときだけチェックを表示する。データが変わるにつれてコントロール の出現はここで述べられた通知システムを用いて日付を付けるよう保たれる。そ のプロセスはメニュー項目をイネーブル／ディスエーブルするように使用される プロセスと同様である。 コントロールが生成されるとき、コマンドが特定される。コントロールはこの コマンドのコピーを作り、それをフィールドfCommandに格納する。コマンドがい ずれかのデータ値を供給するならばコマンドの適切なゲット（Get）とセット（S et）のメソッドのポインタがまた特定される。コントロールはこれらのメソッド ・ポインタをフィールドfGetMethodとfSetMethodにそれぞれ格納する。その後、 コントロールはデータ値が日付以外であることを示す通知に接続する。各コマン ドはこのためにコネクトデータ（ConnectData）と呼ばれるメソッドを提供する 。 各コントロールは通知を受信すべきオブジェクトとメソッドを示すfDataComme ctionと呼ばれる接続オブジェクトを含む。この接続オブジェクトはコマンドへ のアーギュメントとして渡される。コマンド・オブジェクトは接続オブジェクト の接続メソッドをコールして、そのデータ値に影響を与えるかも知れない各通知 者とインタレストを加える。完了時に、コントロー ルは接続オブジェクトの接続メソッドをコールして第３図に示される接続を確立 する。コントロールはそのデータ値をそのコマンドから更新する。それはコマン ド（fCommand-〉（*fGetMethod()）のゲット（Get）メソッドをコールすること により行う。第５図に示されるように、コントロールはこの値を適切なフィール ドに格納する（たとえば、チェックボックスがfCheckedと名前が付けられたブー ル・フィールドに格納する）。その後、コントロールはその出現を更新する。画 面の一部が更新を必要としていることを示して、ビュー・システムの不当化メソ ッドをコールすることによりこのアクションを行う。 最後に、データの変更と通知が送られる。ある点で、コントロールにより反映 されているデータの値を変更するコマンドが実行される。このコマンドは、コン トロール、メニュー項目から、あるいは直接操作により実行することができる。 コントロールは第４図に示される通知を受け付けて次のユーザ選択を待つように 渡される。 コントロール・パネル コントロールのある集まりは、コントロール・パネルと呼ばれる。コントロー ル・パネル内のコントロールは一般に実際のデータに作用する（これはディフォ ルトであり、必要はない）。それらのアクションは通常直接的であり、互いに独 立である。コントロール・ パネルは必要によりコントロールの間で入力フォーカスの進行を制御する。コン トロール・パネルはシステムですべてのユーザ・インターフェイスに渡って共有 されるであろう。 ダイアログ・ボックス コントロールの他の集まりはダイアログ・ボックスと呼ばれる。ダイアログ・ ボックス内のコントロールは一般にプロトタイプのデータに作用する（これはデ ィフォルトであり、必要はない）。それらのアクションは通常グループ内に一緒 に集められ、その後ユーザがApplyボタンを押すとき一緒に実行される。ダイア ログ・ボックスは必要によりコントロールの間で入力フォーカスの進行を制御す る。 アクションにおけるコントロール ３つのアクションの役割を提供して、アクションにおけるコントロールを説明 する。第２図は種々のコントロールを示す。役割の例はコントロール（この場合 チェックボックス）、コマンド、選択およびデータ・カプセルと似た手法により 使用される。 チェックボックス200 チェックボックスの役割はデータ・カプセル内に格納 されたブール値を表示して変更を容易にすることである。この値はチェックの存 在不存在により表現される。 コマンド210 コマンドの役割はデータ・カプセルから値を得てチェックボッ クスからの方向に変更する ことである。 選択220 選択の役割はコマンドとデータとの間をインターフェイスすること である。 データ230 データはアクションの目標として採用される。 あなたを知ること 誰でもが第３図に示されるようによりよく互いを知りたい。コマンド310はコ ントロールが興味があるデータがどの通知を送ることができるかをチェックボッ クス300に知らせる（コマンド310がどのようにして知るかは他の者に関係がない ）。チェックボックス300は次に通知のためにデータ320に接続する。 誰にも知られず、ディレクタはチェックボックス300にコマンド310と対話する 最良の手法を話した。特に、それはコマンドのゲット値メソッドとセット値メソ ッドについて話された。チェックボックスはこの長所を少しあとで取り上げる。 データを反映すること 何かがデータに起きる−それは第４図に示されるように通知を送る。チェック ボックス400はインタレストを表現したそれらについて聞く。第４図では、デー タからの通知はチェックボックス内にＸを置くことにより反映される情報を太く する（ボールドにする）ように表現する。 チェックボックス510はデータから通知を受信して チェックボックス510を正しく表示する処理が第５図に示される。それは、知ろ うとするコマンド520のゲット値メソッドを用いて行う。正しい値は何かをチェ ックボックス510に知らせる前に、コマンド520は選択を介してデータに行き、実 際に正しい値を知っていることを確認する。チェックボックス510は必要により それ自身を更新する。 データを変更すること ユーザはこのシーンで、第６図に示されるようにチェックボックス600を一度 押す。チェックボックス600はコマンド610のセット値メソッドを用いて選択を介 してデータ620の値をセットする。全体のプロセスを第７図に再び示す。 アクション時のコントロール・パネル コントロール・パネルは第８図に示されるように一セットのコントロールを含 む単なるウインドゥである。これらのコントロールは現在の選択に作用するコマ ンドを含む。コントロールはコマンドがアクティブならばイネーブルされる。ユ ーザとの適切な対話に続いて、コントロールはコマンドを実行し、データを変更 する。 サウンド・コントロール・パネル コントロール・パネルの例として第８図に示すサウンド・コントローラを考え る。このコントロール・パネルはサウンドの再生を制御する４つのボタン800，8 02，804および806を含む。各ボタンは上記の“アクション時のコントロール”の セクションに述べられたように実行する。 プレイ800 このコントロールはTPayコマンドである。このコマンドはある条 件の下でのみアクティブで、それらの条件の下でのみコントロールをイネーブル にする。第１に、サウンドは適切なデータ・カプセル内で選択される。次にそれ は既に再生中であってはならない。最後に、現在のサウンド位置は最後の前のど こかになければならない。押されたときPlayボタンはTPlayコマンドを実行して 選択されたサウンドをスピーカーから出力させる。 ステップ802 このコントロールもまた、TPlayコマンドを含む。これは何であ ろう。さて、これを構成しているとき以来、TPlayコマンドがそれを再生すべき 期間を示すパラメータを取ることができる。ステップボタン（Stepボタン）のた めに、それは単一サンプルに設定される。StepボタンはTPlayボタンに対して述 べたのと同じ条件の下でのみイネーブルとされる。Stepボタンが押されると、TP layコマンドを実行して選択されたサウンドをスピーカーから出力させる。 ストップ804 このコントロールはTStopコマンドを含む。Stopコマンドは選択 されたサウンドが現在再生中であるときのみイネーブルとされる。押されたとき 、StopボタンはTStopコマンドを実行して選択されたサウンドの再生を停止させ 、現在のサウンド位置を開始点に設定する。 ポーズ806 このコントロールはまたTStopコマンドを含む。しかしながらStop ボタンと異なり、このTStopコマンドはサウンドを開始点に巻き戻さないよう設 定される。PlayボタンあるいはStepボタンを押すと再生が中断された場所から続 く。 アクション時のダイアログ・ボックス ダイアログ・ボックスは、それが一セットのコントロールを含む単純なウイン ドゥであるという点でコントロール・パネルと同様である。しかしながら、選択 されたデータへ作用するコントロールに変わって、それらは他のコマンドのパラ メータに作用する。Applyボタンが押されるまでだけが修正されたリアル・デー タである。 カラー・エディタ ダイアログ・ボックスの例として第９図に示すカラー・エディタを考える。そ れは３つのスライダを含む。一つはカラーの赤900、一つは青910、および一つは 緑920の成分のためのスライダである。スライダを望みの値に調整したあと、ユ ーザはApply930を押し て選択した範囲のカラーを変更する。 赤900，緑910，青910 ユーザにとって、これらのスライダは、ラベルを除いて 同一である。すべてのコントロールと同様に、各スライダは、ユーザとの対話に 続いて実行されるコマンドを含む。多くのコントロールとは異なり、特に選択さ れたデータにすぐに影響を与えるコントロール・パネル内のそれらと異なり、こ れらのスライダに含まれるコマンドは他のコマンドのパラメータ値を表示し修正 する。この場合、Applyボタン内に含まれるコマンドの赤、緑あるいは青のパラ メータの１つである。 Apply930 Applyボタンは、実行されるときに選択された範囲のカラーを変更 するTSetColorコマンドを含む。それは３つのパラメータを有する。カラーの赤 、緑および青の成分の各々に対して１つのパラメータである。これらのパラメー タは表示され、ユーザとの対話に応答してスライダにより設定される。Applyボ タンが押されると、このコマンドが実行され新しいカラーが設定される。カラー ・エディタに伴う内部アクションを例として第10図に示す。赤1000，緑1010，青 1020のスライダはTFloatControlCommandを含む。これらのコマンドはコントロー ルが表示する単一の浮動小数点値を含む。ユーザがスライダを調整するにつれて 、スライダはこの値を更新しそのコマンドを実行する。 TFloatControlCommandの選択によりApply1040ボタン内のTSetColorコマンドが 特定される。そのパラメータの１つは各TFloatControlコマンドが実行されると きに設定される。最後に、ユーザがApply1040ボタンを押すとき、TSetColorコマ ンドが実行され、選択されたカラー1050が変更される。 クラス 以下のセクションはコントロールおよびダイアログ領域のクラスとそれらの基 本的なメソッドを説明する。 コントロール コントロールは１またはそれ以上のコマンドへのユーザ・インターフェイスで ある。コントロールはその名称通りにコマンドについての情報を表示し、また、 それが現在のコンテキストの中でアクティブか否かを表示する。適切なユーザと の対話に続いて、コントロールはコマンドを実行する。適切なとき、コントロー ルはコマンドが修正するデータの現在値を得て、それをユーザに表示する。コマ ンドを実行する前にこのデータの新しい値を示すコマンド・パラメータをセット することができる。 オプションとしてのコントロール内のコマンドの付加的仕様でコントロールに ついての選択を生成するメソッド。ルックアップ・コマンドは、それらがどのく らい多くのコマンドを得て、それらがどのように格納 されるかについての、サブクラスにフレキシビリティを与えるための、純粋な仮 想関数である。 プレゼンテーションがオープンされクローズされるときコールされるメソッド 。プレゼンテーションがオープンされるとき、コントロールはその状態に影響を 与えることができる通知を接続する。プレゼンテーションがクローズされるとき これらの接続は切断される。 プレゼンテーションが活性化されまた非活性化されるときコールされるメソッ ド。プレゼンテーションが活性化されるとき、いくつかのコントロールはアクテ ィブのときだけ妥当な通知に接続される。プレゼンテーションの非活性化はこれ らの接続を切断する。 コントロールがイネーブルとされるかどうかに影響を与える通知者に接続しそ れから切断するためにコントロールが使用するメソッド。ConnectEnabledNotifi ersはコントロールがオープンされたときコマンドにより特定される通知者に接 続する。DisconnectEnabledNotifiersはコントロールがクローズされるときこれ らの接続を切断する。 コントロールのデータ値のプレゼンテーションに何かが影響を与えることを示 す通知を受信するメソッド。このメソッドはディフォルトにより何もしない。 通知のためのメソッド。クリエートインタレスト （Create interest）はコントロールのインスタンスにより特定されるインタレ スト（interest）を生成する。Notifyは通知を送り、インタレストを含み込むよ うにオーバーロード（overload）される。 コントロールのインタレスト 単一の通知者はコントロールの多くのサブクラスの中で共有される。特定のコ ントロールインスタンス内のインタレストを表すために、インタレストは特定さ れなければならない。コントロールインタレストは特定のコントロールを指すポ インタを含むインタレストである。このクラスはサブクラス無しで、通常そのま ま使用される内部クラスである。 コントロールの通知 各通知者はコントロールの多くのサブクラスの中で共有されている。コントロ ールがどこに通知を送るかを区別するために、通知は特定されなければならない 。コントロールの通知はその通知を送ったコントロールへのポインタを含む。こ のクラスはサブクラス無しで通常そのまま使用される。 コントロールのプレゼンター コントロールのプレゼンターはコントロールを包むので、プレゼンテーション ・データ・カプセルにより含まれることができる。それはすべてのプレゼンター ・オブジェクトが提供する標準的な振る舞いを提供する。このクラスはサブクラ ス無しで通常そのまま 使用される。 プレゼンテーションがオープンされたときとクローズされたときコールされる メソッド。それらはディフォルトでは何もしない。サブクラスはそれが包むオブ ジェクトのためのこれらのメソッドを処理しなければならない。コントロールに 対して、これらのメソッドは直接委任されなければならない。プレゼンテーショ ンがオープンされたとき、コントロールはその状態に影響を与えることができる 通知に接続する。クローズされるとき、接続は切断される。 プレゼンテーションが活性化されるときと非活性化されるときコールされるメ ソッド。それらはディフォルトでは何もしない。サブクラスはそれが包むオブジ ェクトのメソッドを処理しなければならない。コントロールに対して、これらの メソッドは直接委任される。プレゼンテーションが活性化されるとき、いくつか のコントロールはアクティブのときだけ妥当となる通知に接続する。非活性化さ れときは接続は切断される。 TControlSelection（コントロール選択） コントロール選択は、コントロール・プレゼンターの中に包まれプレゼンテー ションの際に格納される単一のコントロールと付加的にその中のコマンドを特定 する。 コントロール内のコマンドをアクセスするメソッ ド。これらはコマンドが特定されていなければ不当な値を戻す。 TUniControl（ユニコントロール） ユニコントロールは、単一のコマンドを提供し、適切なユーザとの対話に続い て実行させられるコントロールのためのアブストラクト・ベース・クラスである 。この形式のコントロールの例はボタンとチェックボックスである。 コントロールにより提供され実行されるコマンドを特定するメソッド。通知が 、コマンドが変更されたとき登録された接続に送られる。 コントロールがイネーブルとされるか否かに影響を与える通知者に接続するた めとそれから切断するためにコントロールが使用するメソッド。ConnectEnabled Notifiersはコントロールがオープンされるときコマンドにより特定される通知 者に接続する。DisconnectEnabledNotifiersは、コントロールがクローズされる ときこれらの接続を切断する。 コントロールがEnable（イネーブル）とされるべきか否かに影響を与える何か が起きたことを示す通知を受信するメソッド。更新イネーブル（UpdateEnabled ）はコマンドがアクティブか否かをチェックしてイネーブル（Enable）とディス ネーブル（Disable）を適切にコールする。 コントロールのデータ値のプレゼンテーション に影響を与える通知者に接続するためとそれから切断するためにコントロールが 使用するメソッド。ConnectDaTaNotifiersは、コントロールがオープンされると きコマンドにより特定される通知者に接続する。DisconnectDaTaNotifiersは、 コントロールがクローズされるときこれらの接続を切断する。データ値を表示し ないコントロール（例えばボタン）は、何もしないようにConnectDataNotifiers をオーバライドする。 ボタン ボタンは押されるとコマンドを実行するユニコントロールである。このクラス は通常サブクラス無しで使用され、単にコマンドをセットして離れる。 プレゼンテーションが活性化されるときと非活性化されるときにコールされる メソッド。プレゼンテーションが活性化されるとき、いくつかのコントロールは アクティブのときだけ適切な通知に接続する。非活性化されるときには、これら の接続は切断される。プレゼンテーションが活性化されるとき、ボタンはキー等 価通知のために登録する。この接続はプレゼンテーションが非活性化されるとき に切断される。 コントロールのデータ値のプレゼンテーションに影響を与える通知者に接続し またそれから切断してユーザを制御するメソッド。ConnectDataNotifiersはコン トロールがオープンされるときコマンドにより特定さ れる通知者に接続する。DisconnectDataNotifiersはコントロールがクローズさ れるときこれらの接続を切断する。データ値を表示しないコントロール（例えば ボタン）は何もしないように接続データ通知ConnectDataNotifiersをオーバライ ドする。 チェックボックス チェックボックスはブール値をセットするコマンドへのユーザ・インターフェ イスである。適切なユーザとの対話に続いて、チェックボックスは、値を変更す るようにコマンド・メソッドをコールしてそのコマンドを実行する。このクラス は通常サブクラス無しで使用され、単にコマンドとその値のゲッターとセッター をセットし、離れる。 スライダ スライダは、単一浮動小数点値を表示して適切なユーザとの対話に続いて変更 されることを可能とするユニコントロールである。スライダの例は第９図と第10 図に示した。 TMultiControl（マルチコントロール） マルチコントロールはいくつかのコマンドを提供するコントロールのためのア ブストラクト・ベース・クラスであり、適切なユーザとの対話に続いてそれらを 変更することを可能とする。この形式のコントロールの例はラジオ・ボタンとメ ニューである。 TRadioButton（ラジオ・ボタン） ラジオ・ボタンは２あるいはそれ以上のブール値を表示するマルチコントロー ルであり、適切なユーザとの対話に続いてそれらを変更することが可能となる。 ラジオ・ボタンは、第11図に示すように、正確に１つのボタンが選択されるとい う制約を有する。紙（Paper）が選択されると、1100でその円が黒くされる。プ ラスチック（Plastic）が選択されると、1110でその円が選択される。両方を選 択されることはできない。 コマンド コマンドは、オブジェクトへのあるいはオブジェクトのセットへのリクエスト をカプセル化して特定のアクションを行う。コマンドは通常、ボタンを押すこと や、メニュー項目を選択すること、あるいは直接処理のようなエンド・ユーザ・ アクションに応答して実行される。コマンドは、その出現を決定するためにコン トロールにより使用することができるそれら自身についての種々の情報（例えば 、名称グラフィック、キー等価、それらがアクティブか否か）を提供することが できる。サブクラスは、コマンドがアクティブか否かを決定するために、現在の 選択、アクティブ・ユーザ・インターフェイス要素、あるいは他のパラメータを 調べるメソッドを処理しなければならない。サブクラスは、このコマンドがアク ティブか否かに影響を与 えることができる通知インタレストを戻すようにゲット・アクティブ・インタレ ストをオーバライドしなければならない。 第12図は本発明による詳細論理を描くフローチャートである。フローチャート 論理は1200に進み、コントロールは機能ブロック1210にまで直接渡される。そこ でコマンド・オブジェクトはメニューに加えられる。この機能ブロックにより実 行されるステップは、1）コマンドからメニュー項目を生成するステップ、ここ でメニュー項目はコマンドを含む他のオブジェクトデータ構造であるステップ、 2）メニュー項目のリストにあるメニュー項目を追加するステップ、および3）メ ニューの出現が不当であることをデータ構造fValidにマークするステップである 。その後、メニューがプルダウンされると、出現はシステムの状態に基づいて再 計算される。 各メニューはビューである。ビューはサイズと位置の情報を含む。各メニュー はメニュー項目のリストを含む。各メニュー項目は現在の出現を反映するコマン ドと変数を含む。変数は、メニュー項目がイネーブルであるか否か（Boolean fE nabled）、その名称（TTextLabel fName）、そのグラフィック（TGraphicLabel fGraphic）、およびその出現が現在妥当か否か（Boolean fValid）を含む。これ らの変数の各々は、メニュー項目がいつ生成されたかをコマンド に訊ねることにより決定される。 次に、クエリーは、機能ブロック1220に示されるように、通知インタレストた めのコマンド・オブジェクトに送られる。各コマンドは異なる形式の通知に接続 する４つのメソッドを有する。i）その名称に影響を与える通知、ii）グラフィ ックに影響を与える通知、iii）コマンドがアクティブか否に影響を与える通知 、およびiv）いずれかのデータに影響を与える通知である。この場合、コマンド のために生成されたメニュー項目はアクティブな通知に接続する。それは接続オ ブジェクトをConnectActiveに渡すことにより行う。コマンドはその後、コマン ドがアクティブか否に影響を与える通知者に接続オブジェクトを接続する。その 後、コントロールは機能ブロック1230に通され、メニュー項目を描くことが必要 なときイネーブルな状態のコマンドをクエリーする。メニュー項目を描くために 、メニュー項目はそのコマンドのためにメソッド“IsActive”をコールする。そ のコマンドは、それが望むシステム状態がなんであるかを見て、決定ブロック12 40に示されるように、現在のコンテキスト内でそれがアクティブか否かを戻す（ 例えば、いくつかのコマンドは、特定の形式のウインドゥが正面にあるとき、あ るいは特定の形式のオブジェクトが選択されるときにのみアクティブである）。 その後、メニュー項目は機能ブロック1250および1260に示されるように、 コマンドにより戻される値にマッチするように、その内部状態（各メニュー項目 内のブール値）と出現を更新する。 ユーザ・アクションが入力ブロック1270に示されるようにコマンドを含むとき は、ユーザは常にコマンドが処理されるようにする。これはメニュ項目、コント ロール、あるいはオブジェクトの直接処理を介して行うことができる。このアク ションは、機能ブロック1280に示すようにドキュメント状態が修正されるように する。ドキュメントが通知を送るとき、以下のステップが実行される。1）ドキ ュメントにより送られた通知に接続されたいずれかのメニュー項目（あるいは他 のコントロール）は、通知メッセージを受信する。このメッセージはその通知に 送られたオブジェクトへのポインタと共に変更の名称を含む。2）その後メニュ ー項目はその状態を更新する。コントロールは更なる処理のため機能ブロック12 30に戻される。 第13図は、本発明による表示を示す。メニュー項目は編集（Edit）1300であり 、関連付けられた多数のサブメニュー項目を有する。アンドゥ（Undo）1310は、 アクティブメニュー項目であり、関連する機能を実行するように選択することが できる。リドウ（Redo）1320は非アクティブであり、灰色で提供され、この時点 では選択することができない。チェックボックスはまた、デバッグ用コントロー ル・パネル1350の一部として1360 に示されている。 プレゼンテーション・テンプレートと持続性 データプレゼンテーションはテンプレートから生成され、ユーザ・インターフ ェイス・オブジェクト内の期間保存される。すべてのデータを有するものはシス テム内ではモデルである。モデルはデータの処理を含み実行する。データ交換は 、カット、コピー、ペースト動作を介して実行される。データの参照は、選択、 アンカーおよびリンクにより提供される。データ・モデルは他の中に埋め込むこ とができる。ユーザは、関連するユーザ・インターフェイスにより提供されるプ レゼンテーション（例えば、アイコン、寸描、フレーム、ウインドウ、ダイアロ グ、コントロール・パネル）を介してモデルと対話する。データ・モデルはすべ てのプレゼンテーションを生成し、他のオブジェクトへのアクセスメソッドを代 理し、ユーザ・インターフェイスと呼ばれる。 ユーザ・インターフェイスは特定のモデルのためのプレゼンテーションの組、 例えばアイコン、寸描、フレーム、ウインドゥを含むモデルである。要求される とき、プレゼンテーションは望ましいプレゼンテーションの形式、ユーザ名、場 所、他の基準とに基づいて既に生成されているものから選択される。望ましいプ レゼンテーションが見つからないとき、新しいプレゼンテーションを生成して関 連するアーカイブ（保管 所）から１つをコピーすることにより、ユーザ・インターフェイスに加える。プ レゼンテーションは持続的プレゼンテーション情報（例えば、ウインドゥサイズ 場所、およびスクロール位置）がもはや要求されないときにはデリートされても よい。 プレゼンテーションは、データを見て処理するために使用されるユーザ・イン ターフェイス要素（例えば、メニュー、ウインドゥ、ツール）を包むプレゼンテ ーション可能なオブジェクトのセットを含む。プレゼンテーションはこれらのオ ブジェクトが提供するデータへの参照を提供する。プレゼンテーションは、プレ ゼンテーションが活性化されるときプレゼンテーション可能なオブジェクトをイ ンストールしあるいは活性化する。同様に、これらのオブジェクトはプレゼンテ ーションが非活性化されるときに除かれ、あるいは非活性化される。プレゼンテ ーションはその目的に従って同定され、（例えばアイコン、寸描、フレーム、ウ インドウ）、後の選択のためまだ決定されるべき基準（例えばユーザの同一性） を保持する。 プレゼンテーションは、プレゼンテーションがオープンされるときあるいはア クティブであるときに画面上に表示され、あるいは他に使用可能なプレゼンテー ション可能なオブジェクトの集まり（例えばユーザ・インターフェイス要素）か ら構成される。 プレゼンテーションは、アーカイブ（保管所）に含 まれるテンプレート・プレゼンテーションから生成される。これらはユーザ・イ ンターフェイス要素のようなオブジェクトから構成され、順にそれらはグラフィ ックとテキスト・ストリングのようなより小さいオブジェクトから構成される。 アーカイブはユーザ・インターフェイス要素（例えばウインドゥ、メニュー、 コントロール、ツール）とプレゼンテーション（例えば、アイコン、寸描、フレ ーム、ウインドゥ）を含むテンプレート・オブジェクトを有するモデルである。 ダイアログ・ボックスとコントロール・パネル コマンド・オブジェクトを異なる手法で用いることにより、コントロール群の ２つの独立した振る舞いを制御することができる。第１は、それらが直ちにデー タに影響を与えるか否か、あるいは設定が効果を上げる前に、ユーザがOKを押さ なければならないか否かである。第２はそれらが互いに独立か否か、あるいは設 定が原子動作を提供するか否かである。 コントロールはコマンドを含む。ユーザがコントロールを処理するとき、コン トロールはコマンド内にパラメータをセットしてそれが実行されるようにする。 コマンドは選択により特定されるモデル・データに作用する。 イミーディエイト データにすぐにに影響を与えるコントロールは、リ アル・モデル・データを特定する選択を含むコマンドを有する。ユーザがコント ロールを処理するときコマンドはこのデータを変更する。データが変わるとき、 それは変更通知を送り、データの状態に依存するビューとコントロールは正確に 現在の状態を反映する。 遅延 リアル・データを変更しないよう設計されたコントロールは代わりにプロトタ イプのデータに作用しなければならない。リアル・モデル・データはユーザがOK ボタンを押すような他のアクションを取るまで変更されない。これは２つの手法 で達成される。 コントロールはコントロールそれ自身を特定する選択を含むコマンドを含む。 ユーザがコントロールを処理するとき、コマンドはコントロールの値を変更する が、他のモデル・データを変更させない。ユーザがOKボタンを押すと、OKボタン 内のコマンドは、ユーザが処理した各コントロール内の値に一致するようにリア ル・モデル・データを変更する。 コントロールは、OKボタンにより含まれるコマンドのパラメータを特定する選 択を含むコマンドを有する。ユーザがコントロールを処理するとき、コマンドは OKボタンのコマンドを変える。ユーザがOKボタンを押すとき、OKボタンのコマン ドはそれ自身に含まれる値を一致させるようにリアル・モデル・データを変更 する。 独立 互いに独立に動作するコントロールはコントロール・パネルあるいはダイアロ グ期間が完了した後、個々にアンドゥできるアクションを要求し表現する。これ はコントロールにより実行された場合の、コマンドの通常の振る舞いである。 原子 コントロールの他のセットは一緒に働き、原子動作としてアンドゥされ、リド ゥされるように設計される。これは、ダイアログ・ボックスあるいはコントロー ルが開始されるときアンドゥ・スタック上にマークを置くことにより達成される 。終了したとき、コントロール・パネルを解散させることによりあるいは（上記 IIBのように）ユーザがOKボタンを押すときに、マークがアンドゥ・スタック上 に置かれたときから実行されるコマンドのすべてが単一のコマンド群に集められ る。この群は単一群としてアンドゥあるいはリドゥされることができる。 キャンセル （上記IIBのように、通常OKボタンに伴う）CANCEL（キャンセル）ボタンを含 むコントロール・パネルは、上記IIIBで述べた技術と同様な技術である。マーク は、ダイアログ・ボックスあるいはコントロール・パネルが開始されるときアン ドゥ・スタック上に置か れる。ユーザがCANCELボタンを押すと、マークがアンドゥ（Undo）・スタックに 置かれる前のすべてのコマンドがアンドゥ（Undo）される。この技術はコントロ ールがデータに直ちに影響を与えるか否かにかかわらず働く。 ダイアログ・ボックス内での原子コマンドの実行 他のオブジェクトあるいはデータを処理するようユーザが対話するオブジェク トはコントロールと呼ぶ。コントロールの例は、メニュー、ボタン、チェックボ ックス、およびラジオ・ボタンである。各コントロールはコマンドを含み、それ はエンド・ユーザ・アクションを実行する。コマンドは選択オブジェクトにより 特定されるデータに作用する。ユーザがコントロールを処理するとき、それはコ マンド内にパラメータをセットしてそれが実行されるようにする。このようにし て、データ値を変更する。 互いに独立に働くコントロールは、コントロール・パネルあるいはダイアログ 期間が完了したあと、個々にアンドゥされることができる表現アクションを要求 する。これは、コマンドがコントロールにより一旦実行されたとき通常の振る舞 いである。他の組のコントロールは共に動作するように設計され、原子動作に従 ってアンドゥされリドゥされるべきである。これはこの特許の主題である。 原子実行の詳細な論理は第14図に提供されるフロー チャートに示される。処理は端子1400に進み、コントロールは機能ブロック1410 にすぐに通され、ダイアログ・ボックスが活性化される。ダイアログ・ボックス が活性化されるとき、マークはアンドゥ・スタック上に置かれる。アンドゥ・ス タックはユーザが実行したすべてのコマンドのリストである。アンドゥが押され ると、スタックの最上部のコマンドがアンドゥされる。すぐにリドゥされなけれ ば、捨て去られる。その後、機能ブロック1410で、コントロールのユーザ処理が 検出される。コントロールの処理が機能ブロック1430で述べたように適切にコマ ンドのデータ値を変更して、コントロールを実行する。例えば、チェックボック スは０と１の間でコマンドのｆチェック（fChecked）フィールドを行き来する。 最後に、コマンドはアンドゥ・スタック上に記録され、機能ブロック1440に示さ れるように、続いてアンドゥされることができる。 判定ブロック1450で検出されるように、ユーザが続いてダイアログ・ボックス 内の各コントロールを処理すると、コントロールは機能ブロック1430に進む。し かしながら、判定ブロック1460で検出されるように、ユーザがOKボタンを押した ときは、コントロールは機能ブロック1420に進む。最後に、ダイアログ・ボック ス内の各コントロールがユーザの満足に達したとき、ユーザはOKボタンを押す。 マークが機能ブロック1440 でアンドゥ・スタック上に置かれて、以来実行されたすべてのコマンドは単一の コマンド群内に集められ、機能ブロック1470で示されるようにアンドゥ・スタッ ク上に戻される。コマンド群は多くのコマンドを一緒に集めるコマンドである。 実行され、アンドゥされ、あるいはリドゥされるとき、コマンド群は順番に各コ マンドを実行し、アンドゥし、あるいはリドゥする。コマンド群は、その後、単 一原子動作としてアンドゥされあるいはリドゥされることができるアンドゥ・ス タック上に戻される。 ダイアログ・ボックス内の遅延されたコマンド実行 ユーザが他のオブジェクトあるいはデータを処理するように対話するオブジェ クトは、コントロールと呼ばれる。コントロールの例はメニュー、ボタン、チェ ックボックス、ラジオ・ボタンである。各コントロールはコマンドを含み、それ はエンド−ユーザのアクションを処理する。コマンドは選択オブジェクトにより 特定されるデータに作用する。ユーザがコントロールを処理するときそれはコマ ンド内にパラメータをセットしてそれが実行されるようにする。これにより、デ ータ値が変更される。ユーザが他のアクションを実行するまでデータが遅延して 変更されることは、本発明の１つの特徴である。例えば、ダイアログ・ボックス 内のコントロールはユーザがOKボタンを押す まで、データ値を変更しようとしない。 コントロールが生成されるときコマンドが特定されなければならない。コント ロールはこのコマンドのコピーを作りそれをフィールドfCommandに格納する。コ マンドが何らかのデータ値を供給するならば、コマンドの適切なゲット（Get） メソッドとセット（Set）メソッドへのポインタがまた特定されなければならな い。コントロールはこれらのメソッド・ポインタをfGetMethodとfSetMethodのフ ィールドにそれぞれ格納する。コマンドにより修正されるデータは選択オブジェ クトにより特定される。通常、この選択オブジェクトはリアル・モデル・データ を特定する。代わりに、OKボタンのコマンド内のデータ値を特定する選択オブジ ェクトであってもよい。 ユーザがコントロールを処理するとき、コントロールのコマンドが実行されOK ボタンのコマンド内のデータ値が変更される。ユーザがダイアログ・ボックス内 の各コントロールを処理するとき、コントロールコマンドが実行されて、OKボタ ンのコマンド内のデータ値が変更される。このようにして、ユーザがOKボタンを 押すと、OKボタン内のコマンドがコントロールのコマンドにより処理されるよう にそれ自身内に含まれるデータ値に一致するようにリアル・モデル・データを更 新する。この処理はコントロールの処理が完了するまで繰り返される。 ラベル ラベルはグラフィックあるいはテキスト・ストリングを含むグラフィック・オ ブジェクトである。それらはウインドゥ、メニュー、ボタン、および他のコント ロールを同定するために使用される。ラベルはそれらのコンテナの状態に従って それらの外見を変えることができる。それらは中間明度の灰色のバックグラウン ド上に描かれ、特別の状態を表示する必要のないときに自然に現われる。ラベル は、非アクティブのとき、禁止されているとき、あるいは選択されたとき、その 外見を変える。 非アクティブ ウインドゥ・タイトルはウインドゥが正面最上部でないとき非アクティブにセ ットされる。同様に、コントロールのラベルはコントロールが正面最上部のウイ ンドゥあるいはコンテナ内にないとき非アクティブにセットされる。グラフィッ ク・ラベルは、薄暗く出現させるために、非アクティブのとき55％の白と混ぜら れている。テキスト・ラベルでは、非アクティブペイントはHSVカラー・モデル の飽和成分を処理することにより自然のペイントから導かれる。飽和は、非アク ティブのとき0.45倍される。 禁止（ディスエーブル） コントロール・ラベルはコントロールが特定のコンテキスト中で適用しないと きには薄暗くされる。グラフィック・ラベルは非アクティブのときには薄暗くす るため46％の白と混ぜられている。テキスト・ラベルでは、禁止ペイントはHSV カラー・モデルの飽和成分を処理することにより自然のペイントから導かれる。 飽和は、禁止のときに0.54倍される。 選択 コントロール・ラベルはコントロールが処理されるにつれてハイライトにされ る。グラフィックとテキストはそれらの自然状態で描かれ、ハイライト状態のと きに白いバックグラウンド上に描かれる。 スマート・コントロール・ラベル コントロールはオブジェクトあるいはデータの現在の状態を決定するためのコ マンドを使用する。ユーザとの適切な対話に続いて、コントロールはコマンド・ パラメータを更新してそれが実行されるようにする。例えばチェックボックスは コマンド・パラメータをオンあるいはオフにセットして、そのコマンドを実行し てデータ値を変更する。コントロールはその機能を示すようにラベルを表示する 。このラベルはグラフィックあるいはテキスト・ストリングを含むグラフィック ・オブジェクトである。コントロールが状態を変えるとき、ラベルは、開発者が 付加的なコードを書くこ とを要求することなく自動的にその出現を変える。これらの状態は、アクティブ ／非アクティブ、イネーブル／ディスエーブルおよび選択／非選択を含む。 第15図はスマート・ラベル処理と関連する詳細論理を示し、その処理は開始タ ーミナル1500に進む。そこでは、コントロールはスマート・ラベルの初期化のた めすぐに1510に進む。コントロールが生成されるとき、そのラベルはその関連す るコマンドにより提供されるテキスト・ストリングあるいはグラフィックで初期 化される。各コマンドはこの目的のためGetGraphicとGetNameと呼ばれるメソッ ドを提供する。コントロールはメソッドSetActiveをコールすることにより現在 アクティブか非アクティブかをラベルに知らせる。同様に、コントロールはSetE nabledメソッドをコールしてそれがイネーブルであるか否かをラベルに知らせる 。また、SetSelectedメソッドをコールしてユーザにより現在選択されているか 否かをラベルに知らせる。 スマート・ラベル処理での次のステップはラベルが描かれるとき機能ブロック 1520で起きる。コントロールが活性化されているとき、それはそのラベルの描写 （Draw）メソッドをコールしてラベルをその画面上に出現させる。非アクティブ ならばラベルは通常よりも薄暗く描かれる。これはHSV カラー・モデルの飽和成 分を処理することによりなされる。飽和は非アクティブ のとき0.45倍される。ディスエーブルならば、ラベルは通常よりも薄暗く描かれ る。これはHSV カラー・モデルの飽和成分を処理することによりなされる。飽和 はラベルがディスエーブルのとき0.54倍される。選択されたならば、ラベルはハ イライトされたバックグラウンド上に出現させられる。ラベルは通常、中間色グ レーのバックグラウンド上に描かれる。ハイライトされるときラベルは白いバッ クグラウンド上に描かれる。他には、ラベルは通常通り描かれる。 次の処理はラベルが機能ブロック1530に示されるように活性化されている／非 活性化されているとき起きる。コントロールが活性化されているあるいは非活性 化されているとき、それはSetActiveメソッドをコールしてラベルに知らせる。 コントロールは、再描画される必要がある画面の一部を示すアーギュメントつき で無効化（Invalidate）をコールすることによりその出現を更新することが必要 であることを示す。その後、機能ブロック1540で、処理はコントロールがイネー ブルあるいはディスエーブルされるとき起きる。コントロールは、イネーブルあ るいはディスエーブルされるとき、SetEnabledメソッドをコールすることにより ラベルに知らせる。その後、コントロールは、再描画される必要がある画面の一 部を示すアーギュメントつきで無効化（Invalidate）をコールすることによりそ の出現を更新することが必要であると示す。 テストが判定ブロック1550で実行され、コントロールが選択されているか非選 択であるかを判定する。コントロールが選択されあるいは非選択であるときは、 SetSelectedメッソドをコールすることによりラベルに知らせる。その後、コン トロールは、再描画される必要がある画面の一部を示すアーギュメントつきでIn valiate（無効化）をコールすることによりその出現を更新することが必要であ ると示し、コントロールは更なる処理のため機能ブロック1520に進む。 スマート・ウインドゥ・ラベル タイトルはその目的を示すためにウインドゥ内に表示される。例えばドキュメ ントを編集するためのウインドゥのためのタイトルは通常ドキュメントの名称で ある。ラベル・オブジェクトはタイトルの追尾を保つために使用される。このラ ベルはグラフィックあるいはテキスト・ストリングを含むグラフィック・オブジ ェクトである。ウインドゥが状態を変えると、ラベルは、開発者が付加的なコー ドを書くことを要求することなく、その出現を自動的に調整する。ウインドゥは アクティブあるいは非アクティブのどちらかである。スマート・ウインドゥ・ラ ベル処理は第16図のフローチャートで示され、その詳細論理はそれを参照して説 明される。 第16図の処理はターミナル1600に進み、そこでコントロールはタイトルが初期 化されるべきために機 能ブロック1610にすぐに進む。ウインドゥ・タイトルはウインドウが生成される とき開発者により特定される。このタイトルはfTitleと呼ばれるTLabelオブジェ クト内に格納される。コントロールは、メソッドSetActiveをコールしてアクテ ィブかあるいは非アクティブかをタイトルに知らせる。その後機能ブロック1620 に進む。ウインドゥが描かれるとき、そのfTitleオブジェクトのDrawメソッドを コールしてタイトルが画面上に出現するようにする。非アクティブのときタイト ルは通常より薄暗く描かれる。これはHSV カラー・モデルの飽和成分を処理する ことによりなされる。飽和はラベルが非アクティブのとき0.45倍される。他の場 合には、タイトルは通常通り描かれる。 次のステップはタイトルが機能ブロック1630で活性化されている／非活性化さ れているとき処理される。ウインドゥが活性化されているあるいは非活性化され ているとき、それはSetActiveメソッドをコールしてそのfTitleオブジェクトに 知らせる。その後、ウインドゥは、再描画される必要がある画面の一部を示すア ーギュメントつきでInvalidateをコールすることによりその出現は更新すること が必要であると示す。その後、その新しい状態を反映するようにタイトルを再描 画するためにコントロールは機能ブロック1620に戻る。 デコレーション ユーザ・インターフェイス要素の多くの視覚的測面は、多くの要素間で共通で ある。例としてシャドウ、境界、およびラベルがある。個々の可視的特徴はデコ レーションとして参照される。デコレーションは他のグラフィックスと結合され てウインドゥとコントロールのような特定のユーザ・インターフェイス要素の可 視的形状を形成する。本発明の主題は多くのことなる形式のデコレーションをサ ポートすることである。 バックグラウンド 他のオブジェクトの後ろに描かれるデコレーションはバックグラウンドと呼ば れる。１つの形式のバックグランドは周囲の描画面とフラッシュするように描か れる。それはフレームつきであるいはフレーム無しで描かれてもよい。他の形式 のバックグランドはハイライトとシャドウつきで描かれ、それは回りの描画面か ら持ち上げられているように見える。最後の形式のバックグランドはハイライト とシャドウつきで描かれ、それは周囲の描画面より後退して見える。 これらのバックグランドの使用例はボタンである。通常ボタンを述べるテキス トあるいはグラフィックは持ち上がったバックグランドの上に描かれる。ユーザ により押されれると、テキストあるいはグラフィックは後退したバックグランド 上に再描画される。他のウインドゥがアクティブのときのようにボタンが非アク ティブならば、ボタンのテキストあるいはグラフィックはフラッシュ・バックグ ランド上に薄暗く描かれる。 境界 他のオブジェクトあるいはエリアを囲むデコレーションは境界と呼ぶ。境界の 例はフレームとシャドウである。フレームはリアル・ワールド内でのペイントを 包み込むフレームのように他のグラフィックを囲む境界である。バックグランド のように、フレームは、周囲の描画面よりしたに後退したように、フラッシュす るように、あるいはそれより持ち上がったように描くことができる。シャドウは オブジェクトの回りにシャドウを加える特定の形式の境界であり、周囲面より浮 いているかのようにそれを見せる。 ユーザ・インターフェイス要素の多くの視覚的測面は、多くの要素間で共通で ある。例としてシャドウ、境界、およびラベルがある。これらの個々の視覚的特 徴の各々はデコレーションとして参照される。デコレーションは他のグラフィッ クスと結合されてウインドゥとコントロールのような特定のユーザ・インターフ ェイス要素の視覚的形状を形成する。あるデコレーションはハイライトとシャド ウを用いて周囲描画面より上にあるいは下にあるかのように見せる。デコレーシ ョンはこれらのハイライトとシャドウのペイントを自動的に導くことができる。 塗りつぶし（Fill Paint） 塗りつぶしはデコレーシヨンの基本的カラーを表す。すべての他のペイントは 塗りつぶしから導かれる。塗りつぶしはfFillPaintと呼ばれるカラー・フィール ド内に管理者により格納される。塗りつぶしは通常、デコレーションが生成され るときに作成者により特定される。しかしながら、カラーが特定されないと、中 間色グレーが選択される。 フレーム・ペイント（Frame Paint） フレーム・ペイントはデコレーションの回りに線を描くために使用され可視的 なコントラストを提供する。フレーム・ペイントはfFramePaintと呼ばれるTColo rのフィールド内にデコレーションにより格納される。フレーム・ペイントはデ コレーションが生成されるとき開発者により特定されてもよい。しかしながら、 フレーム・ペイントが特定されないと、塗りつぶしから自動的に計算される。こ れはHSV カラー・モデルの飽和と値成分を処理することによりなされる。飽和は 最大値が１として、４倍される。値は４で割られる。 ハイライト・ペイント（Highlight Paint） ハイライト・ペイントは、オブジェクトが実際の３次元オブジェクトであるな らば光がそのオブジェクトにあたる線を描くために使用される。ハイライト・ペ イントはfHighlightPaintと呼ばれるTColorフィール ド内にデコレーションにより格納される。ハイライト・ペイントはデコレーショ ンが生成されるとき開発者により特定されてもよい。しかしながら、ハイライト ・ペイントが特定されないと、塗りつぶしから自動的に計算される。これはHSV カラー・モデルの飽和と値成分を処理することによりなされる。飽和は0.8倍さ れる。値は最大値を１として、1.25倍される。 シャドウ・ペイント（Shadow Paint） シャドウ・ペイントは、オブジェクトが実際の３次元オブジェクトであるなら ば光がそのオブジェクトにあたる線を描くために使用される。ハイライト・ペイ ントはfHighlightPaintと呼ばれるTColorフィールド内にデコレーションにより 格納される。ハイライト・ペイントはデコレーションを生成するとき開発者が特 定してもよい。しかしながら、ハイライト・ペイントが特定されないと、塗りつ ぶしから自動的に計算される。これはHSV カラー・モデルの飽和と値成分を処理 することによりなされる。飽和は0.8倍される。値は最大値を１として、1.25倍 される。 セマンティックからの入力シンタクスの分離 グラフィック・ユーザ・インターフェイスはマウスを動かし、それらを選択す るためにオブジェクトをクリックし、移動またはコピーのためにオブジェクトを ドラッグし、その後それらをオープンするためにダブル・クリックすることによ り処理される。これらの操 作は直接操作あるいは対話と呼ばれる。マウスをユーザが押し、動かし、離すこ とに対応するイベントのシーケンスは入力シンタクスと呼ばれる。あるイベント ・シーケンスは、セマンティック操作と呼ばれる特定のアクションを示すために 使用される。 セマンティック操作を処理するコードから入力シンタクスを理解するためのコ ードを分離することは本発明の主題である。この処理は相互作用（対話，Intera cts）と相互作用可能（対話可能，Interactable）と呼ばれるオブジェクト内に それぞれ埋め込まれる。第17図はオブジェクトがどのようにして生成され、動か され選択されることができるオブジェクトとの一般的な対話の間でどのように互 いに通信するかを示す。 処理はターミナル1700に進み、そこでコントロールは機能ブロック1710にすぐ に通され、マウス・ボタンが押されたかどうかを決定する。マウス・ボタンが押 された位置で画面の一部に対して応答可能なオブジェクトにイベントが送られる 。このオブジェクトはビュー（View）と呼ばれる。その後、機能ブロック1720で 、インタラクタ（Interactor）が入力シンタクスを説明するために生成される。 これはビューのメソッド・インタラクタ生成（CreateInteractor）をコールする ことによりなされる。インタラクタ（Interactor）が生成されると、可能なユー ザ・アクションを実行するオブ ジェクトへのポインタがパラメータとして渡される。 この議論のために、ユーザが、選択され動かされることができるオブジェクト 上でマウス・ボタンを押したとする。この場合、選択を実行するオブジェクトと 目標オブジェクトに向かって移動するオブジェクトとがパラメータとしてインタ ラクタ（Interactor）に渡される。初期のビュー（View）はこれらの振る舞いの 両方を実行することができるであろう、あるいはそれらは１つあるいは２つの別 のオブジェクトにより実行されることができるであろう。オブジェクトあるいは 複数のオブジェクトは相互動作可能（Interactable）と統括的に呼ばれる。 インタラクタ（Interactor）は機能ブロック1730で開始される。この処理はイ ンタラクタ（Interactor）Viewに戻してインタラクタ（Interactor）の処理を進 める。これはInteractorStartメソッドをコールしてパラメータとして初期マウ ス・イベントを渡すことによりなされる。StartメソッドはfInitialEventに初期 マウス・イベントを保存する。インタラクタ（Interactor）は変数fIntercation Typeを定数kSelectにセットすることにより選択（Select）モードにはいる。そ れはそのSelectBeginメソッドをコールすることにより選択動作を開始するよう インタラクタブル（Interactable）に依頼する。 その後、インタラクタ（Interactor）は、短い時間待って、機能ブロック1740 で示されるように、通過する。新しいマウスイベントが、マウスの現在の状態を 示す時間となったとき、インタラクタ（Interactor）に送られる。その後、シス テムはマウスが判定ブロック1750でまだ押されていることを検出すると、コント ロールは機能ブロック1740にまで通される。他に、コントロールはターミナル17 60に通される。マウス・ボタンがまだ押されていれば、インタラクタ（Interact or）はまだ正しい状態にあると確信して、Interactableに正しい操作を実行する よう依頼する。インタラクタ（Interactor）はfInteractionがkSelectionであれ ば、Selecting（選択中）である。fInteractionTypeがkMovingであれば、それは Moving（移動中）である。 選択（select）中ならば、インタラクタ（Interactor）は現在のマウス位置と 初期マウス位置を比較する。現在のマウス位置はGetCurrentLocationをコールす ることにより得られる。初期マウス位置はGetInitialLocationをコールすること により得られる。２つが同じかあるいは多少しか異ならなければ、ユーザはまだ オブジェクトを選択している。その後、インタラクタ（Interactor）は、そのSe lectRepeatメソッドをコールすることにより選択操作を継続するようInteractab leに依頼する。しかしながら、２つの点 が予め決められたスレッシュホールド以上に異なるときには、ユーザはオブジェ クトを動かし始めている。この場合、インタラクタ（Interactor）はそのSelect Endメソッドをコールすることにより選択操作を終了するようInteractableに依 頼する。その後、その移動開始メソッドをコールして移動動作を始めるようにIn teractableに依頼する。各々の場合、現在のマウス位置は引数（argument）とし て渡される。Moving（移動中）ならば、インタラクタ（Interactor）はMoveRepe atをコールして移動動作を継続するようインタラクタブルInteractableに依頼す る。それは引数（argument）として現在のマウス位置を渡す。 ユーザがマウス・ボタンを離すとき、それは現在の動作の終了を知らせる。Se lecting（選択中）ならば、インタラクタ（Interactor）は、そのSelectEndメソ ッドをコールして選択動作を終了するようInteractableに依頼する。移動中なら ば、インタラクタ（Interactor）はそのMoveEndメソッドをコールして移動動作 を終了するようInteractableに依頼する。 局所化プレゼンテーション 局所化はアプリケーションを更新するプロセスであり、特定の場所のユニーク な表現に従う。それは、言語の翻訳、グラフィック置換、およびインターフェイ ス要素の再配向を含む。例えば、ラベル、タイトル、およびメッセージの中で使 用されるテキストは選択さ れた言語に依存する。その方向と配向はメニュー、メニュー・バー・タイトル、 スクロールバーあるいはツールバーの配置と配向に影響を与える。同様に、アイ コンと他のグラフィックシンボルの選択は開発に依存する。不幸にも、メモリ内 にユーザ・インターフェイス要素の多くの局在化されたバージョンをもつことは 非常に高いものとなる。代わりに、ユーザ・インターフェイス要素の局在化バー ジョンは、メモリ内で要求されるまでディスク上に保たれる。 さらに、ユーザ・インターフェイス要素のすべての追尾を保ち、どのバージョ ンが使用されるべきかを決定することは非常にエラーとなりやすく高価である。 代わりに、ユーザ・インターフェイス要素が要求されるとき適切なものが現在の 言語と他の文化的パラメータに従ってシステムにより自動的に選択しメモリに読 み込む。 一旦局所化されると、ユーザ・インターフェイス要素はディスク・ディクショ ナリ内に格納される。ディスク・ディクショナリは、キーに与えられるとき、そ れをディスク内にあるいはディスクから読んだあとに値を戻るオブジェクトであ る。このディスク・ディクショナリは保管所（アーカイブ）と呼ばれるオブジェ クトにより管理される。アーカイブは特定の表現を構成する個々のユーザ・イン ターフェイス要素を一緒に置く。適当なユーザ・インターフェイス要素の選択の プロセスは第19図に提供される。 処理はターミナル1900に進み、ユーザがプレゼンテーションをリクエストする ときすぐに機能ブロック1910に通される。TOpenPresentationCommandはデータ・ モデルに送られ、ユーザがこのデータをビューあるいは編集したいということを 示す。このコマンドはTOpenPresentationCommand呼ばれる。プレゼンテーション はユーザがあるデータをビューしあるいは編集することを可能とするユーザ・イ ンターフェイス要素の組である。プレゼンテーションはユーザインターフェース オブジェクト内の期間に渡って格納され、このようにしてユーザのために連続性 を維持する。ユーザ・インターフェイス要素はメモリ内で必要となるまでディス クに格納される。それらはユーザがリクエストしたデータプレゼンテーションの 一部として要求され、あるいは翻訳あるいは他の局所化プロセスのために必要と されることがある。各ユーザ・インターフェイス要素はその要素をユニークに参 照するIDを含む。しかしながら、同じユーザ・インターフェイス要素のすべての 局在化バージョンは単一のIDを共有する。 局在化バージョンを異ならせるために、特定の言語、記述方向、および他の文 化的パラメータが各局在化されたユーザ・インターフェイス要素と共に格納され る。一緒に、これらのパラメータは場所として参照される。ユーザ・インターフ ェイス要素のすべては ファイルに格納される。このファイルは１つあるいはそれ以上のキー／値の対付 きで、ディクショナリと同様に組織化される。そのキーはIDと場所を結合するオ ブジェクトである。値はユーザ・インターフェイス要素それ自身である。 新しいプレゼンテーションが機能ブロック1920で次に生成されなければならな い。適切なプレゼンテーションは既に存在しないので、新しいものがユーザ・イ ンターフェイス、アーカイブによりテンプレートから生成されなければならない 。新しいプレゼンテーションはそのCreatePresentationメソッドをコールするこ とによりアーカイブの中に格納されるテンプレートから生成される。プレゼンテ ーションの形式はパラメータとしてこのメソッドに渡される。この形式は、表示 されるべきデータの形式、それがそれ自身のウインドゥあるいは他のプレゼンテ ーションの一部の中に存在すべきか否か等の情報を含む。最後に、機能ブロック 1930で、アーカイブは場所に従ってユーザ・インターフェイス要素を選択して、 プレゼンテーションを構築する。アーカイブが特定の形式のプレゼンテーション を構築することができれば、それはプレゼンテーションを構築しユーザ・インタ ーフェイスオブジェクトにこれを戻す各ユーザ・インターフェイス要素を一緒に 集める。 アーカイブが構築することができる各プレゼンテー ションでは、それはプレゼンテーションを一緒に構築するユーザ・インターフェ イス要素のリストをもつ。ユーザ・インターフェイス要素はコールされたディス ク・ディクショナリにより維持されているディスク上に格納される。キーを与え ると、ディスク・ディクショナリは対応するユーザ・インターフェイス要素を戻 す。ユーザ・インターフェイス要素のIDはこのキーの基本的部分を構成する。キ ーの第２の要素は望ましい場所である。場所は、ユーザの自然言語と他の文化的 属性を特定するオブジェクトである。場所は、参照サーバ（Preferences Server ）からアーカイブにより自動的に得られる。このサーバーはユーザに関連する個 々の好みのすべてを含む。 好みのサーバーから得られる場所はIＤと共に、TUserInterfaceElementKeyと 呼ばれる単一のオブジェクトの中に結合される。このキーはパラメータとしてデ ィスク・ディクショナリのGetValueメソッドに渡される。一致するIDと場所もつ ユーザ・インターフェイス要素が見つけられると、プレゼンテーションの一部と して戻され含まれる。他に、場所パラメータはキーから省略されなければならず 、あるいは他の場所がユーザ・インターフェイス要素のが見つけられるまで特定 されなければならない。 対話フレームワーク・システム オブジェクト指向オペレーティング・システムのグ ラフィック・ユーザ・インターフェイスのユーザは、しばしば、マウスを動かし 、オブジェクトを選択するためにクリックし、移動あるいはコピーのためにオブ ジェクトをドラッグし、その後オブジェクトをオープンするためにダブル・クリ ックする。これらの動作は直接操作あるいは対話と呼ばれる。マウスをユーザが 押し、移動し、離すことに対応するイベントのシーケンスは入力シンタクスと呼 ぶ。あるイベント・シーケンスが特定のアクションを示すために使用され、セマ ンティック動作と呼ばれる。本発明は、Select（選択），Peek（ピーク），Move （移動），AutoScroll（自動スクロール）およびDrag/Drop（Copy）（ドラッグ ／ドロップ）（コピー）をサポートするオブジェクトのセマンティック動作に入 力シンタクスを翻訳するための方法と装置を開示する。 本発明は、マウス・ボタンの押下を検出し以下の論理を採用する。 （a）ユーザがマウス・ボタンを押したときオプションキーが押されていたら 、システムは変数fInteractionTypeを定数kDragにセットすることによりドラッ グ・モードに入る。その後システムは動作の目標として選択されたオブジェクト を用いてドラッグ動作を進める。あるいは、 （b）オプションキーが押されていなかったならば、システムは変数fInteract ionTypeを定数kSe1ectに セットすることにより選択モードに入る。その後、選択動作が進められる。 ユーザが既にマウス・ボタンを押していて押したままに保っているときには、 以下の論理が関係する。システムは選択モードにあり、システムは最初にユーザ がマウスを、移動スレッシュホールドと呼ばれるあるスレッシュホールド以上に 動かしたか否かを判定する。これは、GetInitialLocationメソッドにより戻され る初期のマウス位置をGetCurrentLocationメソッドにより戻される現在のマウス 位置と比較することによりなされる。マウスが移動スレシュホールド以上に動か されていればシステムは選択モードを終了し移動モードに入る。それは変数Inte ractionTypeを定数kMoveセットすることにより行う。システムはその後そのSele ctEndメソッドをコールして選択動作を終了するようオブジェクトをクエリーす る。その後、システムはそのMoveBeginメソッドをコールすることにより移動動 作を開始する。 他に、マウスが動いていないときには、システムはマウスがどのくらい長く押 されたままかをチェクするGetCurrentTimeメソッドにより戻される現在の時間と を比較することによりなされる。マウスがピーク（peek）スレシュホールドと呼 ばれるあるスレシュホールド以上押下されたままならば、システムは選択モード を終了しピーク・モードに入る。それは変数 fInteractionTypeを定数kPeekにセットすることにより行う。それは、そのSelec tEndメソッドをコールして選択動作を終了するようオブジェクトに依頼して、そ のPeekBeginメソッドをコールしてピーク動作を開始する。他に、マウスが動か されないとき、あるいはあるピーク・スレシュホールドを越えて押されなときは 、システムはオブジェクトのSelectRepeatをコールして選択動作を継続する。シ ステムがユーザが移動モードにあることを検出したときは、システムはまずユー ザがウインドゥ内で、あるいはウインドゥの境界上で、あるいはウインドゥの外 でマウスを動かしたか否かを判定する。それは、GetCurrentLocationメソッドに より戻される現在マウス位置とGetContainerBoundsにより戻されるオブジェクト のコンテナの境界とを比較して行う。 マウスがまだウインドゥの境界内にあれば、システムはオブジェクトのMoveRe peatメソッドをコールして移動動作を継続する。マウスがウインドゥの境界上に あれば、これは自動スクロール動作を示す。システムはマウス位置により示され る方向にスクロールするようにオブジェクトのコンテナに依頼する。これは、コ ンテナのAutoScrollメソッドをコールして、現在のマウス位置をパラメータとし て通すことによりなされる。一旦完了すると、システムは、オブジェクトのMove Repeatメソッドをコールして移動動作を継続す る。 マウスがウインドゥの外にあれば、システムは移動動作を終了してドラッグ・ モードに入る。それは、変数fInteractionTypeに定数kMoveをセットすることに より行う。それは、そのMoveEndメソッドをコールして移動動作を終了するよう オブジェクトに依頼する。それは、そのDragBeginメソッドをコールしてドラッ グ動作を開始するようにオブジェクトに依頼する。システムがドラッグ・モード にあるときには、システムはオブジェクトのDragRepeatメソッドをコールしてド ラッグ動作を継続する。システムがピーク・モードにあるときには、システムは 最初に、移動スレッシュホールドと呼ばれるあるスレッシュホールドを越えてマ ウスをユーザが移動したか否かを判定する。これは、GetInitialLocationメソッ ドにより戻される初期マウス位置とGetCurrentLocationメソッドにより戻される 現在マウス位置とを比較してこれを行う。 マウスが移動スレシュホールドを越えて動いていたときには、システムはピー ク動作を終了して移動モードに入る。それは、変数fInteractionTypeを定数kMov eにセットすることにより行う。それは、そのPeekEndメソッドをコールしてピー ク動作を終了するようオブジェクトに依頼する。それは、そのMoveBeginメソッ ドをコールして移動動作を開始する様にオブジェクトに依頼する。他に、マウス が動かさ れていないときには、システムはオブジェクトのPeekRepeatメソッドをコールし てピーク動作を継続する。 システムがマウス・ボタンをユーザが離したことを検出したときには、選択モ ードにあれば、システムは選択モードを終了する。それは変数fInteractionType を定数kNoneにセットすることにより行う。システムはそのメソッド選択終了を コールして選択動作を終了するようオブジェクトにクエリーする。システムが移 動モードにあるときには、システムは移動モードを終了する。それは変数fInter actonTypeを定数kNoneにセットすることによりこれを行う。その後、システムは そのMoveEndメソッドをコールして移動動作を終了するようオブジェクトにクエ リーして、変数fInteractonTypeを定数kNoneにセットすることによりドラッグ・ モードを終了する。システムがピーク・モードにあるときには、システムはピー ク・モードを終了する。それは変数fInteractonTypeを定数kNoneにセットするこ とにより行う。それは、そのPeekEndメソッドをコールしてピーク動作を終了す るようオブジェクトに依頼する。 ユーザがスクロールバーを動かすにつれて動的にウインドゥの内容を更新する ことを可能とするハードウェアとソフトウェアのシステムを提供することが本発 明の基本的目的である。システムはユーザがスク ロールバーを押したことを検出する。ユーザがスクロールバーを押したとき、シ ステムはスクロール・コマンドの初期化を始め、ウインドゥ内に表示されている データ部分を変更する。コマンドはスクロールのようなエンド・ユーザ・アクシ ョンを処理するオブジェクトである。スクロール・コマンドは１つのパラメータ 、内容のビューがスクロールされるべき位置を有する。システムはこの位置を現 在のスクロール位置にセットする。これは、コマンドのSetScrollPositionメソ ッドをコールして、スクロールバーのメソッドのGetScrollPositionにより戻さ れる値に位置にスクロールを設定することによりなされる。 ユーザがスクローバー内でマウスを動かすときには、システムはスクロール・ コマンドの実行を継続してウインドゥ内に表示されているデータ部分を動的に変 更する。システムはコマンドのスクロール位置を新しいスクロール位置にセット する。この処理はコマンドSetScrollPositionをコールしてスクロールバーのメ ソッドのGetScrollPositionにより戻される値に等しく値をセットすることによ りなされる。コマンドの実行は、その後、そのDoRepeatメソッドをコールするこ とにより繰り返される。これによりビューの内容が新しい位置にスクロールされ る。この処理はユーザがマウス・ボタンを押し続けている間継続する。 ユーザがマウス・ボタンを離したときには、システ ムはスクロール・コマンドの実行を終了してウインドゥ内に表示されているデー タ部分を動的に変更する。システムはコマンドのスクロール位置を最終スクロー ル位置にセットする。この処理はコマンドSetScrollPositionをコールしてスク ロールバー・メソッドのGetScrollPositionにより戻される値に位置にそれが等 しくなるようにセットすることによりなされる。 第20図は本発明によるスクロールと関連する詳細論理を示すフローチャートで ある。処理はターミナルブロック2000に進み、すぐに機能ブロック2010に通され る。そこで、現在のスクロール位置が現在のカーソル位置に基づいて初期化され る。その後、判定ブロック2020で、スクロールバーつまみ（scrollbar thumb） 選択されたかどうかを検出するようにテストを行う。スクロールバーつまみの例 を第21A図にラベル2110に示す。スクロールバーつまみが選択されたときには、 コントロールは、スクロールバーが動かされたか否かを判定するために判定ブロ ック2030に通される。そうならば、スクロール位置はスクロールバーつまみの新 しい位置に送られ、表示がすぐスクロール動作に反映して再フォーマットされユ ーザのために表示がなされる。スクロールバーつまみが動いていなければ、他の テストが判定ブロック2050で行われ、スクロールバーつまみが離されたか否かが 判定される。そうでなけれ ば、コントロールは判定ブロック2030に戻される。スクロールバーつまみが離さ れていれば、コントロールは機能ブロック2060に通され、スクロール動作を終了 してシステムを非スクロール動作状態に戻り、処理はターミナル2070で完了する 。 第21A図、第21B図、および第21C図は本発明によるウインドゥ・スクロールを 示す。第21A図では、スクロールバーつまみ2110はウインドゥ2112の最上部にあ る。第21B図は、スクロールバーつまみ2120がウインドゥの中央に動かされ、従 ってウインドゥの内容2122が更新されることを示す。第21図は、スクロールバー つまみ2140がウインドゥの底部に動かされ、ウインドゥの最も底の部分が表示さ れていることを示している。

【手続補正書】特許法第１８４条の８ 【提出日】１９９５年１月１１日 【補正内容】 （原文明細書第１頁） 明細書 コンピュータ・システムでダイアログ・ボックスを実行する方法 発明の分野 本発明は、一般的には、表示システムにおける改良に関し、特に、コンピュー タ・システムでダイアログ・ボックスを実行する方法に関する。 背景技術 ワークステーション・ソフトウェアの開発者の間で、ユーザ・インターフェイ ス内の一貫性を維持しながらフレキシブルなソフトウェア環境を提供することの 重要性が増してきている。この種の動作環境を提供する初期の試みがヘルナンデ スらの米国特許第4,686,522号に開示されている。この特許は、少なくともひと つのコントロール・ディスプレイを含むダイアログ・ボックス・ディスプレイを 作成するため、コンピュータで使うオブジェクト指向ダイアログ・システムを示 している。グラフィカル・ユーザ・インターフェース・プログラムとアプリケー ションとの間で使用するオブジェクト指向・グラフィカル・ユーザ・インターフ ェースは、欧州特許第0-4990409号で開示されている。この特許は、少なくとも ひとつのコントロール・ディスプレイを含むダイアログ・ボックス・ディスプレ イをどのように作成するかを開示していない。 コマンドはまた、どのアプリケーションが現在アクティブであるかに拘わらず 、ユーザとの一貫したインターフェースを反映する必要がある。全てのコマンド が一貫した方法で機能することを可能にする革新的なハードウエア及びソフトウ エアシステムを提供することは、従来のどの公報の出願人も意図していない。 発明の概要 従って、本発明の主要目的は、コマンド・オブジェクトを使用してコントロー ル群の２つの独立した作用を制御することである。第１は、コントロールがデー タに即時に影響を与えるか、設定が有効になる前にユーザはOKを押す必要がある かどうかである。第２は、コントロールが相互に独立しているか、あるいは、コ ントロール設定が結合されて、アトミック・オペレーション（atomic operation ）を表しているかを区別するものである。 ダイアログ（dialog）は、コマンドの中でパラメータを設定するコマンドから 構成され、特定のパラメータを使用してコマンドが実行されるようにするもので ある。コマンドは、選択（selection）によって指定されたモデル・データに作 用する。 データに即時に影響を与えるコントロールは、リアル・モデル・データ（real model data）を指定する選択を含むコマンドを含んでいる。ユーザがダイアログ を操作すると、コマンドによってそのデータが変更される。データが変更される と、ビュー（view）とコントロールが、データの状態に応じて、データの現在状 態を正確に反映するように変更通知が送られる。 リアル・データが一時データに作用するまで一定に保たれるように設計された ダイアログは異なるアプローチを使用している。リアル・モデル・データは、ユ ーザがボタンを押すといった、別のアクションを行うまで変更されない。このア プローチを容易にするために、次のようなロジック（論理）が採用されている。 第１は、コントロールがそのコントロール自体を指定している選択を含んでいる 場合である。 （原文明細書第33頁） 原子 コントロールの他のセットは一緒に働き、原子動作としてアンドゥされ、リド ゥされるように設計される。これは、ダイアログ・ボックスあるいはコントロー ルが開始されるときアンドゥ・スタック上にマークを置くことにより達成される 。終了したとき、コントロール・パネルを消すさせることによりあるいは（上記 IIBのように）ユーザがOKボタンを押すときに、マークがアンドゥ・スタック上 に置かれたときから実行されるコマンドのすべてが単一のコマンド群に集められ る。この群は単一群としてアンドゥあるいはリドゥされることができる。 キャンセル （上記IIBのように、通常OKボタンを伴う）CANCEL（キャンセル）ボタンを含 むコントロール・パネルは、上記IIIBで述べた技術と同様な技術である。マーク は、ダイアログ・ボックスあるいはコントロール・パネルが開始されるときアン ドゥ・スタック上に置かれる。ユーザがCANCELボタンを押すと、マークがアンド ゥ（Undo）・スタックに置かれた後のすべてのコマンドがアンドゥ（Undo）され る。この技術はコントロールがデータに直ちに影響を与えるか否かにかかわらず 働く。 ダイアログ・ボックス内での原子コマンドの実行 他のオブジェクトあるいはデータを処理するようユーザが対話するオブジェク トはコントロールと呼ぶ。コントロールの例は、メニュー、ボタン、チェックボ ックス、およびラジオ・ボタンである。各コントロールはコマンドを含み、それ はエンド・ユーザ・アクションを実行する。コマンドは選択オブジェクトにより 特定されるデータに作用する。ユーザがコントロールを処理するとき、それはコ マンド内にパラメータをセットしてそれが実行されるようにする。このようにし て、データ値を変更する。 互いに独立に働くコントロールは、コントロール・パネルあるいはダイアログ 期間が完了したあと、個々にアンドゥされることができる表現アクションを要求 する。これは、コマンドがコントロールにより一旦実行されたとき通常の振る舞 いである。他の組のコントロールは共に動作するように設計され、原子動作とし てアンドゥされリドゥされるべきである。 原子実行の詳細な論理は第14図に提供されるフローチャートに示される。処理 は端子1400に進み、コントロールは機能ブロック1410にすぐに通され、ダイアロ グ・ボックスが活性化される。ダイアログ・ボックスが活性化されるとき、マー クはアンドゥ・スタック上に置かれる。アンドゥ・スタックはユーザが実行した すべてのコマンドのリストである。アンドゥが押されると、スタックの最上部の コマンドがアンドゥされる。すぐにリドゥされなければ、捨て去られる。その後 、機能ブロック1410で、コントロールのユーザ処理が検出される。コントロール の処理が機能ブロック1430で述べたように適切にコマンドのデータ値を変更して 、コントロールを実行する。例えば、チェックボックスは０と１の間でコマンド のｆチェック（fChecked）フィールドを行き来する。最後に、コマンドは 【手続補正書】特許法第１８４条の８ 【提出日】１９９５年３月１５日 【補正内容】 請求の範囲 １．メモリ手段（14，16）、前記メモリ手段にストアされるモデル・データ（23 0）、前記モデル・データを使う複数のオブジェクト（300，400，510，600）、 ユーザ・コマンドを受け取る手段（24，26）およびディスプレイ（38）を含み、 前記ストアされたモデル・データのディスプレイを含み、かつ、前記ストアされ たモデル・データを変更するためにユーザが操作できるコントロール・ディスプ レイを有するダイアログ・ボックス・ディスプレイ（1020，1040，1050）を前記 ディスプレイ上に生成するオブジェクト指向ダイアログ・システムにおいて、 （a）第１のユーザ・コマンドに応答して、前記コントロール・ディスプレイ を生成するメソッド、前記データ・ディスプレイを生成するメソッド、前記モデ ル・データを変更するモディファイ（modify）コマンドを生成するメソッド、お よびデータ変更通知を生成するメソッドを有するコントロール・オブジェクト（ 1040，1410）を生成する手段と、 （b）第２のユーザ・コマンドに応答して、前記ダイアログ・ボックス・ディ スプレイ（1000，1010，1020，1230，1410）をアクチベートする手段と、 （c）前記コントロール・ディスプレイ（1270，1280，1430，1440）のユーザ 操作に応答して、前記ストアされたモデル・データと前記モデル・データ・ディ スプレイとを変更する前記モディファイ（modify）・コマンドを実行する手段と 、 （d）前記ストアされたモデル・データ（1290，1470）の変更に応答して、デ ータ変更の通知を生成するメソッドを実行し、それに関するモデル・データの変 更通知を前記複数のオブジェクトへ送る手段と を具備することを特徴とするオブジェクト指向ダイアログ・システム。 ２．さらに、前記コントロール・ディスプレイのユーザ操作に応答して、コマン ド・オブジェクトを生成する手段（1270，1280）と、前記コントロール・オブジ ェクトに置かれ、前記コマンド・オブジェクトに応答して、前記モディファイ・ コマンドを実行する手段とを具備することを特徴とする請求の範囲第１項に記載 のオブジェクト指向ダイアログ・システム。 ３．前記データ変更の通知に応答して、システム情報の現在状態を正確に反映す るように前記複数のオブジェクトのコントロールを行うプロセッサ手段（1290， 1810〜1885）をさらに具備することを特徴とする請求の範囲第１項に記載のオブ ジェクト指向ダイアログ・システム。 ４．モデル・データ・ディスプレイ情報をストアする一時記憶手段（14，16，23 0）をさらに含むことを特徴とする請求の範囲第１項に記載のオブジェクト指向 ダイアログ・システム。 ５．第３のユーザ・コマンドに応答して、前記モデル・データを前記ストアされ たモデル・データ・ディスプレイ情報に変更する割込み検出手段（1530，1540） をさらに含むことを特徴とする請求の範囲第１項に記載のオブジェクト指向ダイ アログ・システム。 ６．第４のユーザ・コマンドに応答して、前記モデル・データを変更する第２の モディファイ・コマンドを生成するメソッドを含む第２のコントロール・オブジ ェクトを生成する手段（1240，1250，1260，1270，1280，1290）と、第５のユー ザ・コマンドに応答して、前記モディファイ・コマンドと前記第２のモディファ イ・コマンドを実行する手段とをさらに具備することを特徴とする請求の範囲第 １項に記載のオブジェクト指向ダイアログ・システム。 ７．第６のユーザ・コマンドに応答して、前記コントロール・オブジェクトから 独立して作動する第２のコントロール・オブジェクト（1440）を生成する手段を さらに具備することを特徴とする請求の範囲第１項に記載のオブジェクト指向ダ イアログ・システム。 ８．第７のユーザ・コマンドに応答して、前記コントロール・オブジェクトと一 緒に作動する第２のコントロール・オブジェクト（1440）を生成する手段をさら に具備することを特徴とする請求の範囲第１項に記載のオブジェクト指向ダイア ロ グ・システム。 ９．メモリ手段（14，16）、前記メモリ手段にストアされるモデル・データ（23 0）、前記モデル・データを使う複数のオブジェクト（300，400，510，600）、 ユーザ・コマンドを受け取る手段（24，26）およびディスプレイ（38）、前記ス トアされたモデル・データのディスプレイを含み、かつ前記ストアされたモデル ・データを変更するためにユーザが操作できるコントロール・ディスプレイを有 するダイアログ・ボックス・ディスプレイ（1020，1040，1050）を前記ディスプ レイ上に生成する手段をもつコンピュータ・システムでダイアログ・ボックスを 実行する方法において、 （a）第１のユーザ・コマンドに応答して、前記コントロール・ディスプレイ を生成するメソッド、前記モデル・データ・ディスプレイを生成するメソッド、 前記モデル・データを変更するモディファイ（modify）コマンドを生成するメソ ッドを有するコントロール・オブジェクト（1040，1410）を生成するステップと 、 （b）第２のユーザ・コマンドに応答して、前記ダイアログ・ボックス・ディ スプレイ（1000，1010，1020，1230，1410）をアクチベートするステップと、 （c）前記コントロール・ディスプレイ（1270，1280，1430，1440）のユーザ 操作に応答して、前記ストアされたモデル・データと前記モデル・データ・ディ スプレイとを変更する前記モディファイ（modify）・コマンドを実行するステッ プと、 （d）前記ストアされたモデル・データ（1290，1470）の変更に応答して、デ ータの変更通知を生成する前記メソッドを実行し、それに関するモデル・データ の変更通知を前記複数のオブジェクトへ送るステップと を具備することを特徴とする方法。 10．ステップ（b）は、リアル・モデル・データを表示するダイアログ・ボック ス・ディスプレイをアクチベートするステップを含むことを特徴とする請求の範 囲第９項に記載の方法。 11．ステップ（d）は、前記複数のオブジェクトがシステム情報の現在状態を正 確 に反映するように前記複数のオブジェクトにデータ変更の通知を行うステップ（ d1）を含むことを特徴とする請求の範囲第９項に記載の方法。 12．ステップ（c）は、コマンド・オペレーションをバッファリングするステッ プ（c1）を含むことを特徴とする請求の範囲第９項に記載の方法。 13．ステップ（c）は、ステップ（c1）でバッファリングされたコマンド・オペ レーションを実行するかどうかをユーザが判断するステップ（c2）を含むことを 特徴とする請求の範囲第９項に記載の方法。 14．ステップ（c）は、ステップ（c1）でバッファリングされた複数のコマンド ・オペレーションの実行を同期するステップ（c3）を含むことを特徴とする請求 の範囲第９項に記載の方法。 15．ステップ（c）は、ステップ（c1）でバッファリングされた複数の相互に独 立したコントロール・アクションを実行するステップ（c4）を含むことを特徴と する請求の範囲第９項に記載の方法。 16．ステップ（c）は、一緒に作動して一つのアクションを実行するように複数 のコントロールを調整するステップ（c5）を含むことを特徴とする請求の範囲第 ９項に記載の方法。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 アンダーソン，デイヴィッド，アール アメリカ合衆国 95014 カリフォルニア 州 クパチーノ ウエスト エステイツ ドライブ 10761

Claims (1)

1. 【特許請求の範囲】 １．コマンド・システムであって、 （a）コマンド・データ構造をストアするメモリ手段と、 （b）該当の実行を示すパラメータをコマンド・データ構造にセーブ（格納） するプロセッサ手段と、 （c）ユーザが正しいコントロール実行を行うためにコントロールを操作する と、コマンド・データ構造を修正するプロセッサ手段と、 （d）コントロール実行に応答してダイアログをアクチベートするプロセッサ 手段とを具備することを特徴とするコマンド・システム。 ２．リアル・モデル・データを指定しているダイアログをアクチベートすること を含むことを特徴とする請求の範囲第１項に記載のコマンド・システム。 ３．システム情報の現在状態を正確に反映するようにデータ変更の通知を行うプ ロセッサ手段を含むことを特徴とする請求の範囲第１項に記載のコマンド・シス テム。 ４．コマンド・オペレーションをバッファリングする一時記憶手段を含むことを 特徴とする請求の範囲第１ 項に記載のコマンド・システム。 ５．ユーザが一時的コマンド・オペレーションを受け付けたかどうかを判断する 割込み検出手段を含むことを特徴とする請求の範囲第１項に記載のコマンド・シ ステム。 ６．ユーザがコマンド・オペレーションを受け付けたことと同期する記憶手段と プロセッサ手段とを含むことを特徴とする請求の範囲第１項に記載のコマンド・ システム。 ７．相互に独立して作用するコントロールを含むことを特徴とする請求の範囲第 １項に記載のコマンド・システム。 ８．一緒に作用してアクションを実行するコントロールを含むことを特徴とする 請求の範囲第１項に記載のコマンド・システム。 ９．コマンド・システムの方法であって、 （a）コマンド・データ構造をストアし、 （b）該当の実行を示すパラメータをコマンド・データ構造にセーブ（格納） し、 （c）ユーザが正しいコントロール実行を行うために コントロールを操作すると、コマンド・データ構造を修正し、 （d）コントロール実行に応答してダイアログをアクチベートするステップか らなることを特徴とするコマンド・システムの方法。 10．リアル・モデル・データを指定しているダイアログをアクチベートするステ ップを含むことを特徴とする請求の範囲第９項に記載のコマンド・システムの方 法。 11．システム情報の現在状態を正確に反映するようにデータ変更の通知を行うス テップを含むことを特徴とする請求の範囲第９項に記載のコマンド・システムの 方法。 12．コマンド・オペレーションをバッファリングするステップを含むことを特徴 とする請求の範囲第９項に記載のコマンド・システムの方法。 13．ユーザが一時的コマンド・オペレーションを受け付けたかどうかを判断する ステップを含むことを特徴とする請求の範囲第９項に記載のコマンド・システム の方法。 14．ユーザがコマンド・オペレーションを受け付けたことと同期するステップを 含むことを特徴とする請求の範囲第９項に記載のコマンド・システムの方法。 15．相互に独立のコントロール・アクションを実行するステップを含むことを特 徴とする請求の範囲第９項に記載のコマンド・システムの方法。 16．一緒に作用してアクションを実行するようにコントロールを調整するステッ プを含むことを特徴とする請求の範囲第９項に記載のコマンド・システムの方法 。