JP4277002B2 - グラフィカルレイアウト／プレゼンテーションオブジェクトのホスティングを行うシステム - Google Patents

Description

本発明は、一般的にコンピューティングデバイスに関する。具体的には、本発明は、グラフィカルドキュメント／ユーザインターフェースを介して表示されるグラフィカル要素を配置するコンピューティングコンポーネントに関する。

コンピューティングシステムで実行されるアプリケーションのグラフィカル出力の表示および／またはレンダリングには、多数のタスクが含まれる。そのようなタスクの１つが、レイアウト／プレゼンテーション管理である。レイアウト／プレゼンテーション管理は、割り当てられたディスプレイスペース（たとえば長方形）でのディスプレイ要素の組の配置および装飾に関係する。「レイアウト」および「プレゼンテーション」は、他の文脈では区別可能である場合があるが、本明細書で使用されるプレゼンテーションおよびレイアウトは、交換可能であり、同等の用語として扱われなければならない。レイアウト／プレゼンテーションシステムによって処理されるディスプレイ要素によって、グラフィカル出力システムのレンダリングコンポーネントおよびグラフィカルディスプレイドライバにグラフィカル出力が供給される。そのようなレンダリングコンポーネントによって、モニタおよびプリンタなどのグラフィカルディスプレイハードウェアが駆動される。

コンピューティングシステムによって実行されるレイアウト／プレゼンテーションオペレーションに、グラフィカルディスプレイ要素に対して実行されるさまざまな機能が含まれる。そのようなオペレーションの例が、エディタアプリケーションのグラフィカルディスプレイユーザインターフェースの割り当てられた次元内でテキストを配置することである。レイアウトオペレーションによって、テキストの行のコンテンツおよび指定された長方形区域内での配置が決定される。もう１つの例が、標準化された境界を有する要素（たとえば、ダイアログボックス、ツールバー、コントロールバーなど）のフレーム作成である。これらのオペレーションを、本明細書では「フィーチャ」とも称する。コンピュータシステムのレンダリングコンポーネントによって、ディスプレイ要素の状態に基づいてグラフィカル出力データが作られるが、このディスプレイ要素の状態は、潜在的に、前に実行されたレイアウト／プレゼンテーションオペレーション、すなわちフィーチャによって修正される。

さまざまなプレゼンテーションエンジンが既知である。たとえば、ＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）の「ユーザモジュール」によって、グラフィカルユーザインターフェースのトップレベルウィンドウに関するレイアウトオペレーションが実行される。ＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）のダイアログボックスマネージャによって、オブジェクトは、予め定められた位置に配置され、オブジェクトのグループ化が可能になる。オブジェクトの位置決めは、論理的な形で行われ、物理デバイスと独立している。ＪＡＶＡ（登録商標）ＳＷＩＮＧによって、オブジェクトに関して指定されたプロパティに基づく、ビュー内のオブジェクトに関する基本的な配置オペレーションが可能になる。

レイアウト／プレゼンテーションオペレーションは、多数の形で実行されてきた。アプリケーション自体によって、そのディスプレイ要素のレイアウトオペレーションを完全に実行することができる。このレイアウト（または「プレゼンテーション」）オペレーションは、アプリケーション内でカプセル化される。アプリケーションの現在の状態に関連する１つまたは複数のビューに関して、アプリケーションによりディスプレイ要素が装飾／配置される。アプリケーションに割り当てられたディスプレイ領域内で要素がアプリケーションにより配置される。その後、配置されたディスプレイ要素に対応するディスプレイ出力が、グラフィックスシステム／ドライバに対してアプリケーションによりレンダリングが行われる。

ＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）ＸＰオペレーティングシステムに組み込まれたもう１つのレイアウト処理の配置では、アプリケーションによって呼出し可能な、予め定められたレイアウトフィーチャの組がサポートされている。このレイアウトフィーチャの組には、アプリケーションのユーザインターフェースグラフィカルディスプレイ要素の特殊化されたレイアウト／プレゼンテーションオペレーションが含まれる。たとえば、供給される長方形の境界ジェネレータなどの予め定められたレイアウト／プレゼンテーションフィーチャの組によって、グラフィカルディスプレイの要素の編成およびプレゼンテーションの特定の諸態様に関するアプリケーション開発者に対するプログラミング負荷が減る。予め定められたフィーチャの組によって、前述の境界など、ある種の基本的なディスプレイフィーチャ／機能の実行に関する一貫性（ｃｏｎｓｉｓｔｅｎｃｙ）も実現される。アプリケーションによって、予め定められたレイアウト機能性に、アプリケーション自体に組み込まれた追加のレイアウトオペレーションが補足される。

アプリケーションによって呼出し可能な予め定められたレイアウトフィーチャを含む既知のレイアウト処理アーキテクチャによって、コンピュータシステムのレンダリングコンポーネントへのグラフィカルデータおよびコマンドのレンダリングの前にビューを配置する途中でアプリケーションが出会うプログラミングレイアウトタスクが単純になる。しかし、既知のレイアウト処理アーキテクチャでは、アプリケーションによって呼出し可能な予め定められたレイアウトフィーチャの組に関する機能強化または修正がすぐにはサポートされない。したがって、たとえば、新しいレイアウトフィーチャは、プレゼンテーション／レイアウトアーキテクチャによって供給される事前定義のレイアウトフィーチャにフィーチャを置くのではなく、アプリケーションコードに直接に置かれる。その後、実行中に、アプリケーションによって、予め定められたレイアウト機能性および内部で実行されるレイアウト／プレゼンテーションオペレーションの組合せを使用して、レイアウトが計算される。

本発明には、グラフィカル出力レイアウト管理システム内に組み込まれるプレゼンタ（ｐｒｅｓｅｎｔｅｒ）システムが含まれる。そのようなレイアウト管理は、ディスプレイスペースでオブジェクトを配置し、サイズを変更し、置くといった形を目標とする。そのようなシステムによって、プログラムの表示可能なコンテンツを表すデータを含むグラフィカル要素（たとえば、表示されるか印刷されるページに配置される必要があるテキストのブロック）を提供するプログラムの代わりに、レイアウトが処理される。プレゼンタによって、グラフィカル要素のコンテンツを提示するディスプレイ状態を定義することによって、グラフィカル要素に対する相補的な役割（データを指定する）が実行される。したがって、プレゼンタによって、対応するグラフィカル要素のレイアウト記述が保持される。

本発明によれば、プレゼンタシステムによって、ビュー内のグラフィカル要素に関連するプレゼンタのホスティングが行われ、配置される。プレゼンタシステムには、多数のタイプのプレゼンタの派生物をサポートするという役割において、プレゼンタクラスがそこから派生されるプレゼンタ基底クラスが含まれる。その後、プレゼンタが、派生されたプレゼンタクラスからインスタンス化される。

プレゼンタシステムには、プレゼンタホストインターフェースも含まれる。ホストインターフェースには、グラフィカル要素に関連するプレゼンタに従ってビュー内のグラフィカル要素をレイアウトするメソッドが含まれる。したがって、ビュー内のグラフィカル要素のレイアウトは、関連するプレゼンタによって指定される。

請求項に、本発明の特徴を詳細に示すが、本発明およびその特徴は、添付図面と共に考慮される下記の詳細な説明から最もよく理解される。

ユーザインターフェースおよびドキュメントのレイアウト／プレゼンテーションアーキテクチャを本明細書で開示する。開示されるレイアウト／プレゼンテーションアーキテクチャには、ドキュメント／ユーザインターフェースの関連する基礎のデータ（グラフィカル要素）のビュー表示を実行するグラフィカルレイアウト処理／レンダリングコンポーネント（プレゼンタ）が含まれる。プレゼンタシステムによって、プレゼンタのホスティングが行われる。ホストとして実行されるにあたり、対応するグラフィカル要素に対する変更に応答して、プレゼンタの組を含むビューの更新がプレゼンタシステムにより組織化され、調整される。したがって、プレゼンタシステムによって、対応するプレゼンタオブジェクトにより更新され、キャッシングされ、およびレンダリングが行われるビュー状態に、グラフィカル要素の状況（たとえばデータ状態）をリンクする機構が提供される。

本発明を実施するプレゼンタシステムベースのレイアウト／プレゼンテーションアーキテクチャの特質の１つは、それによってホスティングが行われるプレゼンタの型に関する高い拡張性である。プレゼンタシステムによって提供されるプレゼンタ基底クラスによって、対応するグラフィカル要素により提供される情報のレイアウトおよびレンダリングに使用可能なプレゼンタ型（オブジェクトクラス）の組の拡張が実現される。プレゼンタ基底クラスから派生されるさまざまなプレゼンタ型によって、基底プレゼンタクラスにより指定されるデフォルトメソッドに対しオーバーライドを行うという形で特定のレイアウト／レンダリングメソッドが組み込まれる。プレゼンタオブジェクトクラスの組からインスタンス化されるプレゼンタオブジェクトによって、対応するグラフィカル要素のデータ状態によるレイアウト／プレゼンテーションフィーチャが実施される。

プレゼンタシステムによって、プレゼンタオブジェクトクラスの組からインスタンス化されたプレゼンタオブジェクトのホスティングが行われる。プレゼンタシステムによって、プレゼンタオブジェクトのライフタイム管理（すなわち、作成、削除など）が実行される。プレゼンタシステムによって、変更されたプレゼンタだけの選択的な更新のためにダーティ追跡（ｄｉｒｔｙ ｔｒａｃｋｉｎｇ）が行われる。プレゼンタシステムによって、プレゼンタのチェーン化が提供されメインのプレゼンタへの装飾が可能となる。プレゼンタシステムによって、プレゼンタの更新およびレンダリングも調整される。

本発明の一実施形態では、潜在的にビュー状態に影響するグラフィカル要素に対する変更の通知が通知ハンドラによって実現される。通知ハンドラによって、プレゼンタにより実行される変更処理から変更通知処理を分離することが可能になる。各プレゼンタ要素型は、通知ハンドラ型に関連する。各通知ハンドラプロセスによって、対応するグラフィカル要素が変更される。更新が必要な場合には、通知ハンドラによって、関連するプレゼンタオブジェクトのダーティネス（ｄｉｒｔｉｎｅｓｓ）プロパティの設定が始められる。ダーティネスプロパティの設定によって、対応するグラフィカル要素の変更に応答するプレゼンタオブジェクトの再計算が行われる。

例として本明細書で説明されるユーザインターフェースレイアウト／プレゼンテーションアーキテクチャは、グラフィカルユーザ／ドキュメントインターフェースを有するアプリケーションのホスティングを行うオペレーティングシステムに組み込まれる。アプリケーション、プレゼンタ、ならびにオペレーティングシステムおよびデバイス用ドライバのデバイス用レンダリングコンポーネントによって、ディスプレイデバイスハードウェア（たとえば、モニタ、プリンタなど）へのインターフェース／ドキュメントグラフィカル出力デバイス制御コマンド／データのレンダリングが行われる。レンダリングが行われる出力のレイアウトフィーチャは、少なくとも部分的に、プレゼンタシステムによりホスティングが行われるプレゼンタによって実行されるレイアウト／プレゼンテーション処理およびレンダリングに基づいている。

このプレゼンテーションアーキテクチャによって、表示される要素のデータ状態をそのビュー状態から分離することが可能になる。そのような分離によって、基礎になるグラフィカル要素の新しい豊かなディスプレイパーソナリティを作成するための、拡張性のある非常にカスタマイズが容易なプラットフォームがもたらされる。本発明の一実施形態では、ディスプレイ要素は、グラフィカル要素オブジェクト（要素のデータ状態を表す）および特定のビューで要素をレイアウトする、少なくとも１つの関連するプレゼンタオブジェクト（ビュー状態を表す）によって表される。プレゼンタによって、関連する要素のレイアウトのカスタマイズされた更新処理が実行される。また、プレゼンタによって、レイアウト更新後に要素のビューのレンダリングが行われる。

プレゼンタオブジェクトを使用することによって、表示される要素のデータ状態とビューでの表示が分離される。その結果、各グラフィカル要素（表示データソース）が、潜在的に、グラフィカル要素の別個のビュー（たとえば、写真要素のフルスケールビューおよびサムネイルビュー）を提供する複数のプレゼンタを有することができる。複数のプレゼンタを単一のグラフィカル要素に関連付ける能力によって、単一の要素を、フィールド内の複数の位置に関連付けることも可能になる（たとえば、単一のグラフィカル要素を複数の列の間で分割するなど）。また、プレゼンタシステムによって、単一の要素への異なるタイプの複数の別個のプレゼンタのチェーニングがサポートされ、これによって、要素の基本的なビューにさまざまなカスタマイズされた装飾を付加することがサポートされる。例示的なディスプレイレイアウト／レンダリングアーキテクチャの上記ならびに他の態様を、以下で図面を参照して説明する。

図１に、本発明を実施するプレゼンタシステムベースのディスプレイレイアウト／レンダリングアーキテクチャを実行する適切なオペレーティング環境１００の例を示す。オペレーティング環境１００は、適切なオペレーティングシステムの１つの例にすぎず、本発明の使用または機能性の範囲に関して限定を示唆することを意図されたものではない。本発明と共に使用するのに適する他の周知のコンピューティングシステム、コンピューティング環境、および／またはコンピューティング構成に、パーソナルコンピュータ、サーバコンピュータ、ラップトップ／ポータブルコンピューティングデバイス、ハンドヘルドコンピューティングデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境、および類似物が含まれるが、これに限定されない。プレゼンタシステムを含む開示されるレイアウト管理アーキテクチャは、図１に示されたものなど、コンピューティングシステムのディスプレイ機能性に関する拡張性、統合、および均一性を含む多数の種々の関心を想起させる。

本発明を、プログラムモジュールなど、コンピュータによって実行されるコンピュータ実行可能命令によって実行されるステップおよびプロセスの組の全般的な文脈で説明する。一般に、プログラムモジュールには、特定のタスクを実行するか特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。例示的な実施形態を、単一のコンピュータシステムでローカルに実行されるプロセスに関して説明するが、本発明は、潜在的に、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境で動作するネットワークノードに組み込まれる。分散コンピューティング環境では、一般に、プログラムモジュールを、メモリストレージデバイスを含むローカルおよびリモートの両方のコンピュータ記憶媒体に配置することができる。

図１を続けて参照すると、本発明を実施する例示的なシステムには、コンピュータ１１０の形の汎用コンピューティングデバイスが含まれる。コンピュータ１１０のコンポーネントには、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを含むさまざまなシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１を含めることができる。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バス、およびさまざまなバスアーキテクチャのいずれかを使用するローカルバスを含む複数のタイプのバス構造のいずれかとすることができる。例としてこれに限定されないが、そのようなアーキテクチャには、Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびメザニンバスとも称されるＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスが含まれる。

コンピュータ１１０には、通常は、さまざまなコンピュータ読取可能な媒体が含まれる。コンピュータ読取可能な媒体は、コンピュータ１１０によってアクセスできるすべての使用可能な媒体とすることができ、コンピュータ読取可能な媒体には、揮発性および不揮発性の媒体、取外し可能および固定の媒体の両方が含まれる。例としてこれに限定されないが、コンピュータ読取可能な媒体には、揮発性および不揮発性、取外し可能および固定の両方の媒体が含まれるコンピュータ記憶媒体および通信媒体が含まれる。コンピュータ記憶媒体には、揮発性および不揮発性、取外し可能および固定の両方の媒体が含まれるが、これはコンピュータ読取可能命令、データ構造、プログラムモジュール、または他のデータなどの情報の保管のためのあらゆる方法または技術で実装される。コンピュータ読取可能な媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリテクノロジ、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光学ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージデバイス、あるいは所望の情報を保管するのに使用でき、コンピュータ１１０によってアクセスできる任意の他の媒体が含まれるが、これに限定されない。通信媒体によって、通常は、搬送波または他のトランスポート機構などの変調されたデータ信号内でコンピュータ読取可能命令、データ構造、プログラムモジュール、または他のデータが実装され、通信媒体には、すべての情報配信媒体が含まれる。用語「変調されたデータ信号」は、信号内で情報をエンコードする形で１つまたは複数の特性を設定または変更された信号を意味する。例としてこれに限定されないが、通信媒体に、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体が含まれる。上記のいずれかの組合せも、コンピュータ読取可能な媒体の範囲に含まれなければならない。

システムメモリ１３０には、読取専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体が含まれる。起動中などにコンピュータ１１０内の要素の間での情報の転送を助ける基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）が、ＲＯＭ１３１に保管されることもある。ＲＡＭ１３２には、通常、処理ユニット１２０によって即座にアクセス可能および／またはこれによって現在操作されつつあるデータおよび／またはプログラムモジュールが含まれる。例としてこれに限定されないが、図１に、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。

コンピュータ１１０に、他の取外し可能／固定の揮発性／不揮発性コンピュータ記憶媒体を含めることもできる。単に例として、図１に、固定不揮発性磁気媒体から読み取るかこれに書き込むハードディスクドライブ１４１、取外し可能不揮発性磁気ディスク１５２から読み取るかこれに書き込む磁気ディスクドライブ１５１、ＣＤ ＲＯＭまたは他の光学媒体などの取外し可能不揮発性光ディスク１５６から読み取るかこれに書き込む光ディスクドライブ１５５を示す。例示的なオペレーティング環境で使用できる他の取外し可能／固定、揮発性／不揮発性コンピュータ記憶媒体に、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ、および類似物が含まれるが、これに限定されない。ハードディスクドライブ１４１は、通常は、インターフェース１４０などの固定メモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、インターフェース１５０などの取外し可能メモリインターフェースによってシステムバス１２１に接続される。

上述の図１に示したドライブおよびそれに関連するコンピュータ記憶媒体によって、コンピュータ１１０のコンピュータ読取可能命令、データ構造、プログラムモジュール、および他のデータのストレージが提供される。図１では、たとえば、ハードディスクドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を保管するものとして図示されている。これらのコンポーネントを、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同一または異なるもののいずれかとすることができることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は、最低でも異なるコピーであることを示すために、異なる符号が与えられている。ユーザは、キーボード１６２、および一般的にマウス、トラックボール、またはタッチパッドと称するポインティングデバイス１６１などの入力デバイスを介してコンピュータ１１０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）に、マイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナ、または類似物を含めることができる。上記および他の入力デバイスは、しばしば、システムバスに結合されたユーザ入力インターフェース１６０を介して処理ユニット１２０に結合されるが、パラレルポート、ゲームポート、またはｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ（ＵＳＢ）など、他のインターフェースおよびバス構造によって接続することもできる。モニタ１９１または他のタイプのディスプレイデバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続することができる。モニタのほかに、スピーカ１９７およびプリンタ１９６など、出力周辺インターフェース１９５を介してコンピュータ１１０に接続することができる他の周辺出力デバイスも含めることができる。

コンピュータ１１０は、潜在的に、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク化された環境で動作する。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、リモートコンピュータ１８０には、通常、コンピュータ１１０に関して上記で説明した要素の多数またはすべてが含まれるが、図１には、メモリストレージデバイス１８１のみを示す。図１に示された論理接続には、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３が含まれるが、他のネットワークも含めることができる。そのようなネットワーキング環境は、オフィス、会社全体のコンピュータネットワーク、イントラネット、およびインターネットではありふれたものである。

ＬＡＮネットワーキング環境で使用される時に、コンピュータ１１０は、ネットワークインターフェースまたはネットワークアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用される時に、コンピュータ１１０に、通常は、インターネットなどのＷＡＮ１７３を介する通信を確立する、モデム１７２または他の手段が含まれる。モデム１７２は、内蔵または外付けとすることができるが、ユーザ入力インターフェース１６０または他の適当な機構を介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関して示されたプログラムモジュールまたはその一部を、リモートメモリストレージデバイスに保管することができる。例としてこれに限定されないが、図１に、メモリストレージデバイス１８１に常駐するリモートアプリケーションプログラム１８５を示す。図示されたネットワーク接続が、例示的であり、コンピュータの間の通信リンクを確立する他の手段を使用できることが理解されるであろう。

図２は、本発明を実施するレイアウト／プレゼンテーション管理システムアーキテクチャの、ソフトウェアモジュールおよびプログラムならびにインスタンス化されたオブジェクトおよびデータコンポーネントを識別する高水準概略図である。図２に示された例示的なレイアウト／プレゼンテーション管理システムアーキテクチャには、プレゼンタシステム２００が含まれ、このプレゼンタシステム２００によって、オペレーティングシステム２０５で実行されるアプリケーション２０４の要求時にビューオブジェクトクラス（以下で説明する図８を参照されたい）から作成されるビュー２０２に関連する階層式に配置されたプレゼンタオブジェクトの組に基づく表示可能オブジェクトのレイアウト／プレゼンテーションがサポートされる。

本発明の一実施形態で、各ビュー（たとえば、ビュー２０２）は、ビュー内の表示可能オブジェクトを保持する責任を負う対応するプレゼンタシステム（たとえば、プレゼンタシステム２００）を有する。本発明の実施形態では、ビュー２０２は、プレゼンタシステム２００によって作成されるすべてのビジュアルのルートである。ビュー２０２内に表示されるコンテンツは、バッキングストア２０８内のグラフィカル要素２０６に基づく。アプリケーション２０４は、バッキングストア２０８内のグラフィカル要素２０６のソースである。アプリケーションに関連するビュー、プレゼンタシステム、ビューに関するプレゼンタツリー、およびグラフィカル要素ツリーの間の関係を示す例を、以下で説明する図３に示す。

図２に示されたレイアウト／プレゼンテーション管理システムアーキテクチャは、機能コンポーネントの組に分割される。図示のコンポーネントの間の線は、コンポーネントの間の相互作用パスを表す。本発明は、図２に示された例示的な実施形態のコンポーネントの特定の配置およびその図示された例示的な相互作用に限定されない。むしろ、本明細書に記載の機能コンポーネントは、本発明の代替の実施形態により異なる形でグループ化される。

本発明の一実施形態では、アプリケーション２０４によって、ビューオブジェクトクラスアプリケーションプログラムインターフェース（以下で説明する図８のビュークラス構造を参照されたい）のコンストラクタメソッドが呼び出されて、ビュー２０２オブジェクトインスタンスのルートオブジェクトが作成される。ビュー２０２を作成するメソッド呼出しによって、バッキングストア２０８に含まれるグラフィカル要素２０６のルートグラフィカル要素への参照が引き渡される。ビュー２０２を作成した後で、ビュー２０２のＤｏＬａｙｏｕｔメソッドへの呼出しによって、ビュー２０２のプレゼンタツリーが作成され、ルートプレゼンタオブジェクトは、ビュー２０２を作成したコンストラクタメソッドに当初に渡されたルートグラフィカル要素に対応する。ビュー２０２のプレゼンタツリー（図２には図示せず）には、ビュー２０２のビジュアル出力を編成し、レンダリングする責任を負うプレゼンタの組が含まれる。

本発明の一実施形態では、各ビュー（たとえば、ビュー２０２）によって、プレゼンタシステム（たとえば、プレゼンタシステム２００）が所有される。したがって、ＤｏＬａｙｏｕｔメソッドに応答して、ビュー２０２によって、新しいプレゼンタツリーの作成が開始され、そのツリーが呼出し側（たとえば、アプリケーション２０４）に返される。当初は、ビュー２０２によって、プレゼンテーションエンジンオブジェクトクラスのコンストラクタメソッドが呼び出され、プレゼンタホストアプリケーションプログラムインターフェース（プレゼンタホストＡＰＩ）を含むプレゼンテーションエンジン２１２インスタンスが作成される。プレゼンテーションエンジン２１２には、グラフィカル出力をサポートするコンピューティングシステム内のレイアウト／プレゼンテーションオペレーションを実行する際に、調整および組織化して実行する実行コードが含まれる。プレゼンテーションエンジン２１２によって実行／調整される機能には、プレゼンタオブジェクト（ルートバージョンと子バージョンの両方）の作成、プレゼンタの表示状態の再計算の調整、レンダリング、プレゼンタのライフタイム管理、ダーティ追跡、複数のプレゼンタの単一要素へのチェーニング、および増分レイアウトの実行が含まれる。プレゼンテーションエンジン２１２のプレゼンタホストＡＰＩの呼出し可能メソッドの例を、以下で図１２を参照して説明する。これらのメソッドは、ビュー２０２のプレゼンタオブジェクトツリーを作成し、保持する高水準要求である。プレゼンテーションエンジン２１２によって実行される識別されたタスクは例示的であり、当業者は、本発明の代替実施形態で、プレゼンテーションエンジン２１２によって追加／代替のタスクを実行できることを理解するであろう。

プレゼンテーションエンジン２１２によって、プレゼンタシステム２００が構築され、ビュー２０２に関連するプレゼンタオブジェクトが処理される。本発明の一実施形態では、プレゼンタシステム２００にプレゼンタ基底クラス２１６が含まれる。プレゼンタ基底クラス２１６は、本明細書に記載のシステムのレイアウト管理機能性を掘り下げることができるプレゼンタサブクラスおよびプレゼンタオブジェクトを作成する、機能満載の基底クラスである。プレゼンタ基底クラス２１６には、仮想（オーバーライド可能）プログラムコードおよびデータ構造体を含むテンプレートが含まれ、このテンプレートからプレゼンタクラス２１４の組が派生する。プレゼンタクラス２１４は、特定のディスプレイプロパティ／挙動を有する、グラフィカル要素であって、ビューに対応する特殊化されたプレゼンタ型の組を備える。プレゼンタ基底クラス２１６から派生されたカスタマイズされたプレゼンタクラス２１４によって、たとえば、コンテンツがレイアウトされ、子オブジェクトが配置され、添付された要素のビジュアルが作成され、活字印刷ドキュメントのためコンテンツにページが振られ、グラフィカル要素２０６を含むビジュアルが増分式に更新される。プレゼンタ基底クラス２１６によって定義される仮想メソッドをオーバーライドし、補足することによって、プレゼンタクラス２１４の組の各プレゼンタクラスの特殊化された機能が確立する。プレゼンタクラス２１４の組からインスタンス化されるプレゼンタオブジェクトによって、グラフィカル要素２０６のディスプレイ態様が表され処理される。

本発明の一実施形態では、プレゼンタオブジェクトクラス２１４の組は事前定義のプレゼンタクラス２１８および外部プレゼンタクラス２２０の両方を含み、拡張可能でもある。事前定義のプレゼンタクラス２１８の組は、プレゼンタシステム２００と共に提供される。外部プレゼンタオブジェクトクラス２２０は、一般に、プレゼンタシステム２００と独立にインストールされる。しかし、外部プレゼンタオブジェクトクラス２２０のプレゼンタシステム２００との正しい統合が、プレゼンタ基底クラス２１６のパブリッシング（ｐｕｂｌｉｓｈ）が行われたインターフェース仕様（以下で図４ａおよび４ｂを参照して説明する）によって実現される。外部プレゼンタクラス２２０の開発者は、プレゼンタ基底クラス２１６のカスタマイズ可能なレイアウト／レンダリングメソッドに関連するプログラムコードおよびデータ構造体をオーバーライド／修正して、カスタムサイズ変更、子オブジェクトの位置決め、およびレンダリング機能を達成する。その後、外部プレゼンタクラス２２０の組の中に、たとえば新しいオブジェクトクラスを含むファイルをコンピュータのファイルシステム内の指定されたディレクトリにインストールすることによって、新しいプレゼンタクラスはインストールされる。

本発明の一実施形態では、プレゼンタクラス２１４に、たとえばコンテンツレイアウト、子オブジェクトの配置、ビジュアルの作成、ドキュメントコンテンツのページ割り振り、およびビジュアルの増分的更新（たとえば、複数のディスプレイスクリーンにまたがるＨＴＭＬページ）を含む、レイアウトフィーチャを実行するためのプレゼンタクラスが含まれる。特定のプレゼンタ型の例には、さまざまな形でフォーマットされたテキスト（たとえば太字、斜体など）を測定し、表示するテキストプレゼンタ、指定されたイメージを測定し、表示するイメージプレゼンタ、複数の子プレゼンタの間でスペースを区分するドックプレゼンタが含まれる。

プレゼンタシステム２００およびプレゼンタクラス２１４を作成した後に、ビュー２０２およびプレゼンタシステム２００に関連するプレゼンタオブジェクトの組が、ビューについて、ルートプレゼンタオブジェクトから始めてインスタンス化される。プレゼンテーションエンジン２１２を作成するための、プレゼンテーションエンジンオブジェクトクラスへのコンストラクタメソッド呼出しによって、ビュー２０２のルートグラフィカル要素が識別されることに留意されたい。インスタンス化の後に、プレゼンテーションエンジン２１２によって、グラフィカル要素２０６が呼び出されて、ビュー２０２のルートグラフィカル要素に関連するプレゼンタオブジェクト型が判定される。グラフィカル要素のプレゼンタ型を判定した後に、プレゼンテーションエンジン２１２によって、グラフィカル要素２０６により識別されるプレゼンタオブジェクト型に対応するプレゼンタクラス２１４のうちの１つのクラス上でメソッドが呼び出されて、ビュー２０２のルートプレゼンタオブジェクトがインスタンス化される。

プレゼンタクラス２１４とバッキングストア２０８との間のパスによって示されるように、ルートプレゼンタを含むプレゼンタオブジェクトによって、バッキングストア２０８のグラフィカル要素２０６がアクセスされ、特定のグラフィカル要素のプロパティが判定される。たとえば、特定のグラフィカル要素のプレゼンタオブジェクトによって、特定のグラフィカル要素の子グラフィカル要素と各子グラフィカル要素のプレゼンタ型とを識別することができる。その後、プレゼンタオブジェクトによって、識別された子グラフィカル要素ごとに、それ自体のメソッド（たとえば、ＧｅｔＣｈｉｌｄＰｒｏｘｙＦｏｒＥｌｅｍｅｎｔ４８６）が呼び出されて、プレゼンタシステム２００の子プロキシクラス２２２から子プロキシオブジェクトがインスタンス化される。子プロキシオブジェクトは、親プレゼンタオブジェクトに割り当てられるディスプレイスペース内で入れ子にされるプレゼンタオブジェクトのラッパーオブジェクト（プレゼンタオブジェクトクラス２１４からインスタンス化される）である。子プロキシクラス２２２によって、カプセル化およびセキュリティの必要が満たされる（たとえば、子プレゼンタオブジェクトによって、親プレゼンタオブジェクトまたはアプリケーション２０４によるアクセスを、子プレゼンタ内に含まれるプレゼンタの内容に制限する）。代替案では、子プロキシオブジェクトによって提供されるカプセル化レイヤがバイパスされ、親プレゼンタが、その子プレゼンタに直接アクセスする。

本発明の一実施形態で、要素の子プロキシオブジェクトを作成するプレゼンタオブジェクトのメソッドによって、子プロキシクラス２２２のコンストラクタメソッドが呼び出され、子グラフィカル要素の識別が渡され、子グラフィカル要素の新しい子プロキシオブジェクトおよびプレゼンタオブジェクトがインスタンス化される。インスタンス化されると、新しい子プロキシオブジェクトによって、識別された子グラフィカル要素に関して指定されるプレゼンタ型に対応するプレゼンタコンストラクタを介し、子グラフィカル要素のプレゼンタオブジェクトが作成される。子プロキシオブジェクトによって、親プレゼンタオブジェクトへのそれ自体の参照が返される。親プレゼンタオブジェクトによって、子プロキシオブジェクトへの参照のアレイ配列内で、返された子プロキシオブジェクト参照が保持される。したがって、プレゼンタオブジェクトの子プロキシオブジェクト配列項目は、親プレゼンタが関連する親グラフィカル要素の子グラフィカル要素に対応する。

図２に示されたグラフィカル要素配置／プレゼンテーションアーキテクチャのもう１つの態様が変更通知である。本発明の実施形態では、通知ハンドラクラス２２４の組が、プレゼンタクラス２１４からインスタンス化されるプレゼンタオブジェクトのために提供される。通知ハンドラクラス２２４は、通知ハンドラ基底クラス２２５に従って定義される。通知ハンドラ基底クラス２２５は、通知ハンドラクラス２２４のインターフェースを定義する抽象クラスである。通知ハンドラ基底クラス２２５によって、２つの仮想メソッドのインターフェース定義（図６参照）が提供され、対応するプレゼンタクラス２１４に従って通知ハンドラクラス２２４で実装される。通知ハンドラクラス２２４によって、増分的レイアウト更新すなわち、対応するグラフィカル要素の組に対する変更によって影響を受けるプレゼンタオブジェクトだけの再計算が支援される。本発明の一実施形態では、通知ハンドラが、グラフィカル要素およびビューの組合せについて指定される。複数のプレゼンタが、単一のグラフィカル要素／ビュー組合せについて作成される場合には、単一の通知ハンドラが、ビュー内の要素の複数のプレゼンタを更新するための、要素に対する変更を追跡する単一のソースとして動作する。各プレゼンタ型によって、特定の対応する通知ハンドラ型が指定される。通知ハンドラを必要とする、ある要素のプレゼンタオブジェクトがインスタンス化される時、プレゼンタシステムによって、指定された型の対応する通知ハンドラが作成され、通知ハンドラがプレゼンタオブジェクトにリンクされる。

通知ハンドラクラス２２４のインスタンスによって、プレゼンタオブジェクトのどの部分がダーティであり、したがって更新を必要とするかが判定される。当初、通知関係は、ビュー（たとえばアプリケーション２０４のビュー２０２）内のプレゼンタについて作成されるグラフィカル要素と通知ハンドラの間で確立される。通知ハンドラは、プレゼンタシステム２００のプレゼンテーションエンジン２１２を介してバッキングストア２０８内のグラフィカル要素に関連する変更通知を受け取る。通知ハンドラによって、プレゼンタの、要素に対する変更によって影響を受けた部分がある場合、その部分が判定される。通知ハンドラによって、影響された部分の情報がプレゼンタシステム２００に返される。プレゼンタは、プレゼンテーションエンジン２１２によって「ダーティ」としてマークされる。プレゼンタシステム２００によって、ビュー（たとえばビュー２０２）に関して保持されるデータ構造体内のすべてのプレゼンタに関して「ダーティ」プレゼンタ情報が蓄積される。後に、ビューのレイアウトを再計算する呼出しに応答して、プレゼンタシステム２００のプレゼンテーションエンジン２１２によって、ダーティプレゼンタに対してのみ更新メソッド／オペレーションが呼び出される。したがって、通知ハンドラクラス２２４によって、プレゼンタクラス２１４から作成されたプレゼンタオブジェクトのうちの影響されたものだけへのレイアウト更新の制限が可能になる。

本発明を使用するレイアウト管理システムアーキテクチャは、レイアウトされた要素が定義されたビューに従って最終的にその上で表示される特定の出力ハードウェアデバイスと独立に動作する。図２に示されたレイアウト／プレゼンテーション管理システムアーキテクチャによって、グラフィカルディスプレイ出力に関する前処理ステップが実行される。本発明の一実施形態では、レイアウト／プレゼンテーション管理システムアーキテクチャに関連する配置された出力が、デバイス独立である。その後、レンダリングステージの間に、プレゼンタオブジェクトによって、コンピューティングシステムのグラフィカル出力コンポーネントに対して再計算されたビューのレンダリングが行われる。しかし、本発明の他の実施形態では、レイアウト／プレゼンテーションシステムの出力が、プレゼンタオブジェクト２１４またはプレゼンタシステム２００のいずれかによって呼出し元のアプリケーション２０４に返され、アプリケーション２０４によって、レンダリングタスクが実行される。本発明の実施形態では、プレゼンタクラス２１４から派生したプレゼンタオブジェクト、ビュー２０２、またはアプリケーション２０４のどれによって発行されるものであっても、レンダリングコマンドが、ユーザのコンピュータのグラフィックサブシステムおよびグラフィックデバイスドライバ２３４に渡される。グラフィックサブシステムおよびグラフィックデバイスドライバ２３４によって、モニタ２３６またはプリンタ２３８などの特定の選択された出力デバイスへのレンダリング命令およびデータが変換される。

上記で説明したレイアウト／プレゼンテーション管理システムアーキテクチャを要約すると、プレゼンタシステム２００によって、アプリケーション２０４などのアプリケーションのためのデバイス独立のレイアウト処理プラットフォームが提供される。レイアウト処理は、プレゼンタシステム２００によってホスティングが行われるプレゼンタクラス２１４の組からインスタンス化されたプレゼンタオブジェクトによって実行される。プレゼンタシステム２００は、ビュー２０２によって所有される。プレゼンタオブジェクトは、グラフィカル要素２０６の特定のビュー状態／レンダリングに対応する。ビュー状態（プレゼンタオブジェクト）を要素状態（グラフィカル要素２０６）から分離することによって、単一の要素状態について複数のビュー状態／プレゼンタを独立して指定できるようになる。レイアウトは、ビュー２０２などのビューに分離され、各ビューは、アプリケーション２０４に割り当てられた出力スクリーン上の特定の長方形またはグラフィカルプリンタ出力のドキュメントページなどのディスプレイ領域に対応する。データ状態とビュー状態とを分離することによって、単一の要素によってグラフィカル要素の複数のビューを駆動でき、したがって、さまざまなビュー／形で単一のグラフィカル要素を表示できるようになる。

開示されるレイアウト管理システムアーキテクチャのもう１つの特徴が高い拡張性である。プレゼンタクラス２１４の組の拡張は、プレゼンタシステム２００およびプレゼンテーションエンジン２１２のプレゼンタホストＡＰＩによって提供されるプレゼンタ基底クラス２１６によって実現される。

上述のレイアウト管理システムアーキテクチャによって、グラフィカル出力をグラフィカルユーザインターフェースおよびプリンタにレンダリングするアプリケーションのための様々な高度なレイアウト処理フィーチャがサポートされる。単一の要素（グラフィカル要素）を複数のビュー状態（プレゼンタ）に分離する能力によって、プリンタ出力またはディスプレイスクリーン上のドキュメントのプリンタ出力ビューをレンダリングする時のアプリケーションでのページ割り振りおよび複数の列への要素の分割（ページ割り振りの１形態）が支援される。そのようなアプリケーションには、ウェブブラウザおよびワードプロセッシングプログラムが含まれる。

複数のプレゼンタのもう１つの利点は、所与のディスプレイスペース内にコンテンツを収めることを複数試みることをアプリケーションが実行できる点である。アプリケーションは、単一の要素について、複数の入力パラメータを用いて異なるプレゼンタオブジェクトに対する複数の試行をインスタンス化することができ、その後、ユーザにグラフィカル要素の表示されたビューのうちで最良のビューを選択させることができる。

上記で説明したレイアウト管理アーキテクチャから生じるもう１つの利点は、１組の対応する要素に関する１組のプレゼンタを含むビューに対して増分的更新を実行できることである。変更は、バッキングストア（たとえば、図３のバッキングストア２０８を参照されたい）で要素ごとに実施される。通知ハンドラおよびプレゼンタシステム２００によって、バッキングストア内の対応する要素への変更によって影響を受けたプレゼンタに対応するビューの更新を限定するための基盤が提供される。

例示的なレイアウト管理アーキテクチャのもう１つの利点は、以前に作成されたプレゼンタで実施される要素のビュー状態を装飾できる点である。これは、特定の要素型について指定される型のプレゼンタに追加のプレゼンタをチェーニングすることによって達成される。チェーニングによって、開発者が、要素の特定のプレゼンタ型により指定されるビュー状態に境界、背景などを追加してユーザインターフェースおよびドキュメント出力の機能強化が可能になる。

本発明を使用するレイアウト管理システムの全般的なアーキテクチャを説明したので、図３に移るが、この図には、特定の例示的なビューに関するビュー、プレゼンテーションエンジン、ビュー内のプレゼンタオブジェクト、グラフィカル要素、および通知ハンドラの間の関係が示されている。

概念的には、ビューによって、指定されたプレゼンタに従いバッキングストア２０８内に表されるグラフィカル要素の組をレイアウトする特定の形が定義される。本発明の一実施形態では、ビューは出力フィールド（たとえば、ディスプレイスクリーン）内の長方形によって定義される。長方形およびその位置のほかに、ビューによって、ビューに含まれるグラフィカル要素および関連するプレゼンタも指定される。さらに、本発明の一実施形態では、各ビューは、それ自体のプレゼンタシステムインスタンス（たとえば、ビュー２０２ａのプレゼンタシステム２００ａおよびビュー２０２ｂのプレゼンタシステム２００ｂ）に関連することに留意されたい。

図３を続けて参照すると、バッキングストア２０８に、ビュー２０２ａおよび２０２ｂに関連するグラフィカル要素（Ｅｘ）の編成された（ｏｒｇａｎｉｚｅｄ）集合が含まれる。グラフィカル要素（Ｅｘ）は、編成されたユーザコンテンツのエンティティである。要素の例としては、グラフィカルユーザインターフェース（ＧＵＩ）ボタンまたはテキストパネル、テキストエディタウィンドウ、ビットマップなどがある。本発明の一実施形態では、バッキングストア２０８内のグラフィカル要素（Ｅｘ）がツリーの形で配置される。バッキングストア２０８内で保持されるグラフィカル要素２０６の組の各要素（Ｅｘ）は、プロパティ／プレースホルダ（明示的または他の明示的なプロパティ／プレースホルダから暗黙のいずれかとすることができる）の組に関連する。グラフィカル要素の１つまたは複数のそのようなプロパティ／プレースホルダによって、コンピュータシステムの他のコンポーネントと共同するグラフィカル要素のコンテンツがレイアウトされ、レンダリングが行われる。本発明の一実施形態では、チェーニングされるプレゼンタは、明示的に定義されるか、またはこれに替えて、ある要素について指定される他のプロパティから示唆される（たとえば、２ピクセルの「境界」プロパティによって、境界チェーニングが行われたプレゼンタが示唆される）。グラフィカル要素について指定されるプロパティ型は、特定のグラフィカル要素に依存し、これには、色、フォント名、高さ、幅などが含まれる。

バッキングストア２０８は、潜在的に複数のビュー（たとえば、ビュー２０２ａおよび２０２ｂ）に関連する。潜在的に複数のビューのそれぞれによって、バッキングストア２０８内のグラフィカル要素の組に対応するプレゼンタオブジェクトインスタンスの組が排他的に所有される。したがって、複数のビューで提示されるグラフィカル要素の場合に、プレゼンタオブジェクトは、各ビュー内の要素について作成される（たとえば、要素Ｅ２のプレゼンタＰ２およびプレゼンタＰ２’）。プレゼンタが関連するグラフィカル要素は、要素オーナーフィールドで指定され、プレゼンタから対応するグラフィカル要素への破線に対応する。これは、図２および３に示された、単一のグラフィカル要素によって提供される情報を操作する複数のプレゼンタをサポートするプレゼンテーションアーキテクチャの一例にすぎない。

複数のビュー（およびプレゼンタ）をバッキングストア２０８内のグラフィカル要素の同一の集合に添付する上記で説明した能力を実装するプレゼンテーションアーキテクチャの結果として、グラフィカルユーザインターフェースによって、グラフィカル要素によって提供される情報の同一の組の複数のビューを表示することができる。たとえば、ＭＩＣＲＯＳＯＦＴ社のＰＯＷＥＲＰＯＩＮＴなどのアプリケーションで、同一のスライドグラフィカル要素に関して、１つのスライドに同時に２つのビュー、すなわちメインビューおよびプレビュー（またはサムネイル）ビューがサポートされる。

単一のグラフィカル要素の複数のプレゼンタオブジェクトインスタンスを作成する能力によって、複数のページ／列にまたがる単一のグラフィカル要素（たとえば、ドキュメントテキスト）のページ割り振りも実装される（すなわち、１つのグラフィカル要素が２つのページにまたがって分割される場合、そのページごとに１つの要素について２つのプレゼンタオブジェクトが作成される）。図３を参照すると、親プレゼンタオブジェクト（たとえば、Ｐ５）によって、グラフィカル要素（たとえば、Ｅ５）から、その要素内のコンテンツ（たとえば、テキスト要素Ｅ８）が２つの列にまたがって提示可能であることを示すプロパティが渡されて受け取られる。ドキュメントの２つの別々に離れた列／ページの長方形に対応する２つの子プレゼンタオブジェクトＰ８ａおよびＰ８ｂは、グラフィカル要素Ｅ８によって提供されるテキストを表示するためにプレゼンタＰ５の下でインスタンス化される。

単一のグラフィカル要素に関する複数のプレゼンタのインスタンス化のもう１つのケースは、装飾（たとえば、境界、背景、フレームなど）がグラフィカル要素に割り当てられる場合に生じる。チェーニングが行われたプレゼンタの例は、要素Ｅ４のチェーニングが行われたプレゼンタＱ４によって提供されるが、これはプレゼンタＰ４によって定義された長方形の周囲に境界を設け、要素Ｅ４内のデータフィールドが供給するテキストを保持する。その要素オーナーフィールドでグラフィカル要素Ｅ４を指定することによって、プレゼンタＱ４およびプレゼンタＰ４の両方がグラフィカル要素Ｅ４にリンクされ／関連付けられる。本発明の一実施形態で、親プレゼンタは、その子の１つに対応する要素から、チェーニングが行われたプレゼンタが必要である（たとえば、２ピクセルの境界が、要素で指定される）ことを検出する。チェーニングが行われたプレゼンタＱ４の場合、プレゼンタＰ１によって、それ自体のメソッドが呼び出され、子要素Ｅ４の子（プロキシ）プレゼンタが作成されると、Ｅ４のプロパティより、チェーニングが行われたプレゼンタ（Ｑ４）が必要であることが認識される。まず、子プロキシ／プレゼンタＱ４が、作成され、プレゼンタＰ１の子プレゼンタとして識別される。Ｑ４によって、子プロキシ／プレゼンタＰ４が作成される。したがって、Ｐ４は、プレゼンタＱ４の子プレゼンタである。チェーン内の次のプレゼンタ（Ｐ４）を識別する情報が、チェーニングが行われたプレゼンタＱ４の子プロキシ内に保管される。

同一のグラフィカル要素にリンクされ、バッキングストア２０８内のグラフィカル要素の組について複数のビュー（およびプレゼンタシステム）を作成する複数のプレゼンタを伴う特定の例示的なケースを説明したので、図３に表示されるエンティティの間の関係を次に説明する。上述のように、ビュー２０２ａおよび２０２ｂは、それぞれプレゼンタシステム２００ａおよび２００ｂを所有する。プレゼンタシステム２００ａは、プレゼンタクラスがそれに対して記述されるＡＰＩを含むコードおよび基底クラスを介して作成され、ビュー２０２ａのプレゼンタの組３０２をサポートする。プレゼンタシステム２００ｂは、ビュー２０２ｂについて作成され、プレゼンタの組３０３をサポートする。

バッキングストア２０８内のプレゼンタ（Ｐｘ）とグラフィカル要素（Ｅｘ）との間の線によって示されるように、プレゼンタ（Ｐｘ）は、対応するグラフィカル要素（Ｅｘ）に関連する。プレゼンタ（Ｐｘ）によって、対応するグラフィカル要素（Ｅｘ）のビュー状態が表される。バッキングストア２０８内のグラフィカル要素（Ｅｘ）は、たとえば、多数の可能な方法の１つではあるが、アプリケーションによって構築されるツリー構造内で保持される。そのような方法の例には、パーサを介してテキストマークアップファイルを実行すること、グラフィカル要素をインスタンス化するコードを使用することなどが含まれる。プレゼンタの組３０２のツリー構造は、プレゼンタシステム２００ａによって、そのプレゼンテーションエンジンにより提供されるインターフェースの特定のメソッド（たとえば、ＤｏＬａｙｏｕｔ）の呼出しに応答して構築される。上記で図２を参照して説明したように、プレゼンタオブジェクトツリーのノードは、特定のビューに関連するグラフィカル要素ツリーのノードによって決定される。ビュー内のグラフィカル要素は、ビュー、その子、孫などについて指定されるルートグラフィカル要素によって決定される。

ビュー１のプレゼンタの組３０２は、階層的に配置される。ルートプレゼンタＰ１は、２つの子プレゼンタＰ２およびＰ４を有する（Ｑ４は、プレゼンタＰ４に対する装飾プレゼンタである）。プレゼンタＰ２は、子を有しない。しかし、プレゼンタＰ４は、２つの子プレゼンタＰ５およびＰ７を有する。プレゼンタＰ５は、子プレセンタＰ８ａおよびＰ８ｂを有し、これらは、単一のグラフィカル要素Ｅ８に関連する。２つのプレゼンタオブジェクトの間での単一のグラフィカルプレゼンタのそのような共有／分割は、たとえば、テキストグラフィカル要素Ｅ８が、親テキストグラフィカル要素Ｅ５の２つの列の間で分割される時に生じ、グラフィカル要素Ｅ５は、型ＴｅｘｔＰｒｅｓｅｎｔｅｒのプレゼンタ（Ｐ５）を有する。Ｅ５のコンテンツ（Ｅ８）を２つの列にまたがって分割することを要求するＥ５のプロパティにプレゼンタＰ５が留意する時、プレゼンタＰ５によって、列分割処理が開始される。プレセンタＰ８ａおよびＰ８ｂは、２つの列のグラフィカル要素Ｅ８のグラフィカルな部分（ｅｘｉｓｔｅｎｃｅ ｏｆ ｐａｒｔｓ）に対応する。

単一のグラフィカル要素が、複数の関連するプレゼンタオブジェクトを有することができることを以前に注記した。例示的な３つのケースに分けられた。複数のビュー２０２ａおよび２０２ｂ並びに対応する図３のプレゼンタシステム２００ａおよび２００ｂによって示される第１のシナリオでは、単一のグラフィカル要素（たとえば、Ｅ２）は、それぞれビュー２０２ａおよび２０２ｂに関連する対応するプレゼンタＰ２およびＰ２’を有する。そのようなビューは、たとえば、写真イメージ処理アプリケーションによって生成されるユーザインターフェースの異なる領域に表示される写真イメージ（Ｅ２）のサムネイルビューおよびフルサイズビューに対応する。この場合に、プレゼンタＰ２およびＰ２’は、要素を含む各ビュー２０２ａおよび２０２ｂで要素Ｅ２について作成される。単一の要素（たとえば、テキスト要素Ｅ８）に関する複数のプレゼンタを含む第２のシナリオでは、プレゼンタ要素Ｐ８ａおよびＰ８ｂが、単一のプレゼンタ要素Ｐ５によって定義される長方形の中の２つの列に対応する。これに替えて、ビュー内の複数のプレゼンタが同一のグラフィカル要素を参照するケースは、たとえば、親が、ビューのレイアウトの複数の試みを実行し、その試行を保存する時に生じる。第３のシナリオでは、グラフィカル要素（たとえば、Ｅ４）のデータ状態ではなく、別のプレゼンタ（たとえば、Ｐ４）に依存するプレゼンタ（たとえば、Ｑ４）が、他のプレゼンタにチェーニングされ、これによって最初のプレゼンタによって供給されるディスプレイフィーチャが豊かになる。プレゼンタチェーニングの例が、主プレゼンタに境界装飾を提供する境界プレゼンタである。

上記で、図２を参照して、子プロキシクラス２２２からインスタンス化される子プロキシオブジェクトが、親プレゼンタオブジェクトの各子プレゼンタオブジェクトのラッパーであることを注記した。ビュー２０２ａのプレゼンタツリー構造のグラフィカル描写では、子プロキシオブジェクトが、親プレゼンタをその子プレゼンタオブジェクトに接続する線の矢印の先によって表される。子プロキシオブジェクトによって、その親プレゼンタオブジェクトによるアクセスが子プレゼンタオブジェクトに制限される。

通知ハンドラ（Ｎｘ）は、グラフィカル要素（Ｅｘ）に対するデータ状態の変更について、対応するプレゼンタ（Ｐｘ）に通知する責任を負う。通知ハンドラＮｘは、プレゼンテーション／レイアウト管理システムのオペレーションに必須ではない。むしろ、通知ハンドラによって、ビュー内の要素の変更が行われる時、すべてのプレゼンタに対してではなく、増分的更新が実現される。

図４ａおよび４ｂを参照すると、プレゼンタ基底クラスには、メソッド、プロパティ、およびフィールドの組が含まれる。本発明の一実施形態では、プロパティは、特定の参照されるプレゼンタオブジェクトについて、そのオブジェクトのゲット／セットオペレーションを呼び出すことによってアクセスされる。ｂａｃｋｇｒｏｕｎｄプロパティ４００によって、プレゼンタ背景のペイント値が指定される。ｂａｃｋｇｒｏｕｎｄ ｏｐａｃｉｔｙプロパティ４０２によって、背景の不透明度を指定する値が保管される。ｂｏｒｄｅｒプロパティ４０４によって、プレゼンタのレイアウトスペースの縁に沿って描かれる境界の太さを指定する値が保管される。ｂｏｒｄｅｒプロパティ４０４によって、たとえば、プレゼンタに割り当てられた長方形の上辺、下辺、右辺、および左辺の境界幅を示す４つの値が保管される。ｂｏｒｄｅｒ ｃｏｌｏｒプロパティ４０６によって、プレゼンタの回りの境界の色を指定する値が指定される。ｂｏｒｄｅｒ ｓｔｙｌｅプロパティ４０８によって、境界ディスプレイスタイルの組の１つを示す値が保管される。境界スタイルの例に、ｓｏｌｉｄ、ｇｒｏｏｖｅ、ｒｉｄｇｅ、ｉｎｓｅｔ、およびｏｕｔｓｅｔが含まれる。

ｂｏｕｎｄｉｎｇ ｂｏｘプロパティ４１０によって、プレゼンタグラフィックス（または子）が描かれる領域（たとえば、長方形）が指定される。ｂｏｕｎｄｉｎｇ ｂｏｘプロパティ４１０のデフォルトサイズは、ｌａｙｏｕｔ ｓｉｚｅフィールド４６０によって指定されるサイズと同一である。しかし、境界ボックスサイズは、レイアウトサイズを超えるようにすることができ、これによって、プレゼンタがレイアウトサイズの外に描画することが可能になる。

その一方で、ｃｌｉｐプロパティ４１４に真がセットされる場合、プレゼンタ（およびその子プレゼンタ）は、ｌａｙｏｕｔ ｓｉｚｅフィールド４６０によって指定される長方形の外部に描画することができない。ｃｌｉｐプロパティ４１４に真がセットされる場合、ｂｏｕｎｄｉｎｇ ｂｏｘプロパティ４１０は、レイアウトサイズより大きくならない。これによって、描画されるプレゼンタが、それに割り当てられたレイアウトサイズの外でグラフィックスをレンダリングしないことが保証される。

ｃｈｉｌｄｒｅｎプロパティ４１２は、親プレゼンタ内で入れ子にされた子プレゼンタへの参照（たとえば、直接／間接のハンドル、ポインタなど）および親プレゼンタのレイアウトスペース内での変換された位置が保管される、配列または他の適切な多要素データ構造である。ｃｈｉｌｄｒｅｎプロパティ４１２は、プレゼンタのＯｎＵｐｄａｔｅメソッド呼出し（以下で説明する）のコンテキストでの最初の使用時に移植される。「最初の使用時」とは、親プレゼンタが子集合を逐次要求し、子集合は、バッキングストア（たとえばバッキングストア２０８）内のグラフィカル要素のツリーから、親プレゼンタに対応するグラフィカル要素の子グラフィカル要素に対応するプレゼンタを移植される時を指している。ｃｈｉｌｄｒｅｎプロパティ４１２によって、ビュー内のプレゼンタに関する入れ子にされた関係を反映する階層の確立／保持が実現される。本発明の一実施形態では、配列項目によって、子プロキシオブジェクトが参照される。子プロキシオブジェクトは、親プレゼンタオブジェクトに割り当てられたディスプレイスペース内で入れ子にされる子プレゼンタオブジェクトのラッパーオブジェクトである。子プロキシオブジェクトラッパーによって、必要なカプセル化およびセキュリティが満足される（たとえば、子プレゼンタによって、親プレゼンタによるアクセスがその子プレゼンタのコンテンツに制限される）。

上記で説明したように、ｃｌｉｐプロパティ４１４は、プレゼンタのコンテンツが、クリッピングすることによって、ｌａｙｏｕｔ ｓｉｚｅフィールド４６０により指定されるプレゼンタのレイアウトサイズに閉じこめられるかどうかを制御する。

プロパティの組によって、プレゼンタのスペース内でコンテンツに割り当てられるスペースが指定される。ｂｏｒｄｅｒプロパティ４０４の他に、ｐａｄｄｉｎｇプロパティ４１６によって、コンテンツによって占められずに残される境界の内側のスペースの量が指定される。ｃｏｎｔｅｎｔ ｈｅｉｇｈｔプロパティ４１８によって、プレゼンタ内のコンテンツの高さすなわち、プレゼンタのうちでｂｏｒｄｅｒプロパティ４０４およびｐａｄｄｉｎｇプロパティ４１６で指定される値を考慮に入れた後に残されるプレゼンタの部分の高さを示す値が指定される。ｃｏｎｔｅｎｔ ｗｉｄｔｈプロパティ４２０によって、ｂｏｒｄｅｒプロパティ４０４およびｐａｄｄｉｎｇプロパティ４１６の寸法を考慮に入れた後にプレゼンタ内でコンテンツに割り当てられる幅を示す値が指定される。ｃｏｎｔｅｎｔ ｈｅｉｇｈｔプロパティ４１８およびｃｏｎｔｅｎｔ ｗｉｄｔｈプロパティ４２０の組合せによって、プレゼンタ内でコンテンツが潜在的に占めるプレゼンタの領域が指定される。

ｈｅｉｇｈｔプロパティ４２２およびｗｉｄｔｈプロパティ４２４によって、プレゼンタの実際の高さおよび幅が指定され、この２つの値には、コンテンツ、パディング、および境界の寸法が含まれる。ｄｅｆａｕｌｔ ｈｅｉｇｈｔプロパティ４２６およびｄｅｆａｕｌｔ ｗｉｄｔｈプロパティ４２８によって、特定のプレゼンタオブジェクトについてｈｅｉｇｈｔプロパティ４２２およびｗｉｄｔｈプロパティ４２４が供給されない時にプレゼンタに割り当てることができるデフォルト値が指定される。ｍａｘｉｍｕｍ ｗｉｄｔｈプロパティ４３０およびｍｉｎｉｍｕｍ ｗｉｄｔｈプロパティ４３２によって、ｗｉｄｔｈプロパティ４２４に割り当てられる値の範囲が指定される。

プレゼンタのもう１つの寸法プロパティが、ｍａｒｇｉｎプロパティ４３４である。ｍａｒｇｉｎプロパティ４３４によって、プレゼンタの境界の外のバッファスペースが指定される。ｍａｒｇｉｎプロパティ４３４は、子プレゼンタによって指定され、入れ子にされたプレゼンタの階層を含むレイアウトを配置する時に親プレゼンタによってアクセスされる。

ｖｉｓｉｂｉｌｉｔｙプロパティ４３６によって、プレゼンタの可視性状態が指定される。ｖｉｓｉｂｉｌｉｔｙプロパティ４３６は、プレゼンタおよびその子に対応するグラフィカルイメージをレンダリングする方法（またはするかどうか）を判定するために参照される。本発明の一実施形態では、潜在的な可視性状態にｖｉｓｉｂｌｅ、ｃｏｌｌａｐｓｅｄ、およびｈｉｄｄｅｎが含まれる。

複数のプレゼンタプロパティが、プレゼンタをレイアウト／プレゼンテーション管理システム内の他のエンティティにリンクするのに使用される。ｐｒｅｓｅｎｔｅｒプロパティ４３８によって、グラフィカル要素をレイアウトし、レンダリングするのに使用されるプレゼンタ型が指定される。プレゼンタ型は、当初は、グラフィカル要素でセットされ、プレゼンタシステム２００によって、ｐｒｅｓｅｎｔｅｒプロパティ４３８がグラフィカル要素から読み取られ、ｐｒｅｓｅｎｔｅｒプロパティ４３８によって識別されるプレゼンタ型に対応するプレゼンタオブジェクトがインスタンス化される。ｐｒｅｓｅｎｔｅｒプロパティ４３８は、インスタンシエータ（ｉｎｓｔａｎｔｉａｔｏｒ）に渡され、このインスタンシエータによって、識別されたプレゼンタ型のインスタンスが作成される。ＩｓＭａｉｎＰｒｅｓｅｎｔｅｒプロパティ４４０によって、プレゼンタが唯一のプレゼンタであるか、グラフィカル要素オブジェクトに関連するチェーニングが行われたプレゼンタの組の（たとえば最後の）主プレゼンタであるかが指定される。図３を参照すると、プレゼンタＰ４は、Ｂ４およびＰ４を含むチェーンの主プレゼンタである。本発明の一実施形態では、ＩｓＭａｉｎＰｒｅｓｅｎｔｅｒプロパティ４４０が、Ｂｏｏｌｅａｎ型のプロパティである。

ｅｌｅｍｅｎｔ ｏｗｎｅｒプロパティ４４２によって、プレゼンタがインスタンス化される原因となったグラフィカル要素が識別される。図３を参照すると、プレゼンタ（Ｐｘ）を対応するグラフィカル要素（Ｅｘ）に接続する破線によって、ｅｌｅｍｅｎｔ ｏｗｎｅｒプロパティ４４２のコンテンツによって指定される関連が表されている。ｌａｙｏｕｔ ｃｏｎｔｅｘｔプロパティ４４４によって、レイアウト処理中のプレゼンタ間メッセージングを実現するグローバルコンテキストが指定される。ｌａｙｏｕｔ ｃｏｎｔｅｘｔプロパティ４４４に保管される値によって、プレゼンタは、プレゼンタシステム２００と独立にメッセージを渡せるようになる。ｎｏｔｉｆｉｃａｔｉｏｎ ｈａｎｄｌｅｒプロパティ４４６によって、プレゼンタに関する通知ハンドラへの参照が指定される。ｎｏｔｉｆｉｃａｔｉｏｎ ｈａｎｄｌｅｒ ｔｙｐｅプロパティ４４８によって、ｎｏｔｉｆｉｃａｔｉｏｎ ｈａｎｄｌｅｒプロパティ４４６によって参照される通知ハンドラの型が指定される。

ｄｉｒｔｉｎｅｓｓプロパティ４５０によって、特定のプレゼンタが変更され、したがって更新処理を必要とするかどうかが指定される。プレゼンタシステム２００およびレイアウト管理アーキテクチャの関連するコンポーネントによって、レイアウトの増分処理がサポートされる。各プレゼンタによって保持されるｄｉｒｔｉｎｅｓｓプロパティ４５０によって、プレゼンタごとに、プレゼンタが更新を必要とするかどうかが示される。

図４ａを続けて参照すると、プレゼンタ基底クラスのフィールドの例示的な組が要約されている。本発明の一実施形態では、これらのフィールドは、（Ｃ＋＋クラスの周知のメンバ変数に類似の）共通言語ランタイム（ＣＬＲ）フィールドである。本発明の一実施形態では、上記で説明したこのプロパティは、フィールドに類似している。しかし、グラフィカル要素（たとえば、グラフィカル要素２０６）のプロパティは、バッキングストア（たとえば、バッキングストア２０８）によって所有され、管理される。プロパティが変更されると、バッキングストアによって、その変更がプレゼンテーションエンジンに通知される。プレゼンテーションエンジン（たとえば、プレゼンタシステム２００のプレゼンテーションエンジン２１２）によって、適当な通知ハンドラ２２４に通知される。したがって、プロパティの場合、変更通知は前述の通知ハンドラの１つを介して受け取られる。その一方で、フィールドは、バッキングストア２０８によって管理されない（その代わり、たとえばＣＬＲによって管理される）。したがって、フィールドが変更される時、プレゼンテーションエンジンに対して変更通知が行われない。

ｌａｙｏｕｔ ｓｉｚｅフィールド４６０によって、プレゼンタの割り当てられたレイアウトスペースの寸法が保持される。ｌａｙｏｕｔ ｓｉｚｅフィールド４６０は、隣接するプレゼンタをページ／ユーザインターフェースレイアウトに配置するのに使用される。ａｆｆｅｃｔｓ ｌａｙｏｕｔフィールド４６２は、変更された時にプレゼンタのレイアウトに影響するプレゼンタのプロパティ（たとえば、ｂｏｒｄｅｒ、ｐａｄｄｉｎｇなど）の集合である。ａｆｆｅｃｔｓ ｐａｒｅｎｔ ｌａｙｏｕｔフィールド４６４は、要素（たとえば要素Ａ）について変更される時に、指定されたプレゼンタを有する要素（要素Ａ）の最初の親のレイアウトをダーティにする（すなわち、潜在的に影響する）プレゼンタのプロパティ（たとえば、ｍａｒｇｉｎ、ｖｉｓｉｂｉｌｉｔｙなど）の集合である。ｅｆｆｅｃｔｓ ｒｅｎｄｅｒフィールド４６６は、プレゼンタの無効化および再レンダリングをトリガする通知機構である。

図４ｂにリストされたプレゼンタ基底クラス２１６のメソッドを参照すると、ＯｎＵｐｄａｔｅメソッド４７０によって、要素に関するプレゼンタの測定タスクおよび位置決めタスクが実行される。プレゼンタ作成者は、ＯｎＵｐｄａｔｅメソッド４７０の基底クラスバージョンを上書きして、要素の対応するビューのカスタマイズされたレイアウトサイズ変更／位置決め挙動を作成／提供する。

ＯｎＵｐｄａｔｅメソッド４７０の第１のデフォルトオペレーションは、プレゼンタのサイズ変更である。ＯｎＵｐｄａｔｅメソッド４７０によって、渡されるＢｏｘＳｉｚｅＩｎｆｏパラメータでプレゼンタサイズ寸法が受け取られる。ＯｎＵｐｄａｔｅメソッド４７０によって、指定されたＢｏｘＳｉｚｅＩｎｆｏならびｄｅｆａｕｌｔ ｗｉｄｔｈプロパティ４２８値およびｄｅｆａｕｌｔ ｈｅｉｇｈｔプロパティ４２６値に従って、ｌａｙｏｕｔ ｓｉｚｅフィールド４６０で指定された寸法がセットされる。プレゼンタのサイズ変更／位置決め情報の追加のソースが、開示されたプレゼンタベースのレイアウト／プレゼンテーション処理アーキテクチャに組み込まれ、そのようなソースが本発明の代替の実施形態で使用される。

ＯｎＵｐｄａｔｅメソッド４７０の第２のデフォルトタスクは、プレゼンタのローカル寸法スペース内での子プレゼンタの位置決めである。ＯｎＵｐｄａｔｅメソッド４７０の基底クラスバージョンによって、ｃｈｉｌｄｒｅｎプロパティ４１２で識別される子プレゼンタのＯｎＵｐｄａｔｅメソッド４７０が反復的に呼び出されて、その寸法および子が発見される。子プレゼンタを発見し、測定する時に、その子は、個々の子の変換メソッド（以下で説明する）を呼び出すことによって、親プレゼンタ内で位置決めされる。子プレゼンタのＯｎＵｐｄａｔｅメソッド４７０への反復的な呼出しは、プレゼンタでそれ以上子が指定されなくなった時に終了する。ｌａｙｏｕｔ ｓｉｚｅフィールド４６０にサイズを登録し、子プレゼンタを反復的に呼び出す／位置決めするほかに、ＯｎＵｐｄａｔｅメソッド４７０メソッドによって、ＯｎＵｐｄａｔｅメソッド４７０への呼出しを考慮して再レンダリングが望ましいかどうかを示す値が、呼出し側に返される。

ｒｅｇｉｓｔｅｒ ａｔｏｍメソッド４７１によって、ｌａｙｏｕｔ ｃｏｎｔｅｘｔ４４４に関するプレゼンタのストリング名ならびにプレゼンタへの拡張によって保持されるものを含むプレゼンタの他の適当なリストが登録される。ｒｅｇｉｓｔｅｒ ａｔｏｍメソッド４７１は、たとえば、標準的でない方法（たとえば、プレゼンタアプリケーションプログラムインターフェースによって現在サポートされていない方法）で別のプレゼンタオブジェクトと通信するために呼び出される。プレゼンタによって、アトムが登録され、その後、そのアトムを使用して通信することが望まれるオブジェクトが設定される。たとえば、子プレゼンタは、親プレゼンタにテキスト系統（ｄｅｓｃｅｎｔ）を通信することを望む。子プレゼンタは、「系統」というラベル／タグを付けられたアトムを登録し、そのアトムの識別を受け取る。子は、系統を計算して識別を使用してアトムに値を設定する。親プレゼンタは、（「系統」の登録によって受け取られる）識別法を使用して、保管された情報を検索する。

ＯｎＵｐｄａｔｅＢｏｕｎｄｉｎｇＢｏｘメソッド４７２によって、プレゼンタの更新されたｂｏｕｎｄｉｎｇ ｂｏｘプロパティ４１０が作られる。ＯｎＵｐｄａｔｅＢｏｕｎｄｉｎｇＢｏｘメソッド４７２は、再レンダリングを必要とすることを示す値（たとえば「ｔｒｕｅ」）がＯｎＵｐｄａｔｅメソッド４７０によって返される場合に呼び出される。プレゼンタ基底クラスで提供されるＯｎＵｐｄａｔｅＢｏｕｎｄｉｎｇＢｏｘメソッド４７２のデフォルト実装では、プレゼンタのｃｈｉｌｄｒｅｎプロパティ４１２で識別される子プレゼンタをスキャンし、変換された子のＢｏｕｎｄｉｎｇ Ｂｏｘプロパティを、ｌａｙｏｕｔ ｓｉｚｅフィールド４６０に保管されたプレゼンタの寸法と組み合わせる（すなわち、長方形の数学的和集合を実行する）。ＯｎＵｐｄａｔｅＢｏｕｎｄｉｎｇＢｏｘメソッド４７２の基底クラスの実装では、ｃｌｉｐプロパティ４１４にもアクセスが行われ、それが「ｔｒｕｅ」である場合、子の境界ボックスを無視する。その代わりに、子プレゼンタを親プレゼンタのｌａｙｏｕｔ ｓｉｚｅフィールド４６０寸法までにクリッピングする。ｌａｙｏｕｔ ｓｉｚｅフィールド４６０の外側で描画するプレゼンタでは、このメソッドを上書きする。そのようなカスタマイズされたプレゼンタクラスによって、基底プレゼンタクラスが呼び出され、上書きコードで追加の「インク領域」が追加される。本発明の一実施形態では、プレゼンタが、実際に必要なものより大きく「インク領域」を見積もることが許容される。ｂｏｕｎｄｉｎｇ ｂｏｘプロパティ４１０領域が、プレゼンタの描画に必要な領域より小さい場合には、その描画はプレゼンタについて指定されたｂｏｕｎｄｉｎｇ ｂｏｘプロパティ４１０寸法に基づいてクリッピングされる。

ＯｎＲｅｎｄｅｒメソッド４７４は、再レンダリングを要求する／必要とするプレゼンタに関して呼び出される。ＯｎＲｅｎｄｅｒメソッド４７４は、プレゼンタおよびその子プレゼンタのすべてを再レンダリングするための、プレゼンタに対する主要な呼出しである。ＯｎＲｅｎｄｅｒメソッド４７４は、ＯｎＵｐｄａｔｅメソッド４７０がレイアウト（たとえば、シーン）内の「ダーティ」プレゼンタのすべてに対して呼び出された後に呼び出されることが好ましい。本発明の一実施形態では、ＯｎＲｅｎｄｅｒメソッド４７４は、プレゼンタオブジェクトに対するＯｎＵｐｄａｔｅメソッド４７０呼出しによって、プレゼンタが再レンダリングされることが必要であるとの表示が返されるかどうかに基づいて、プレゼンタオブジェクトに対して呼び出される。本発明の一実施形態では、基底クラスのＯｎＲｅｎｄｅｒメソッド４７４によって、プレゼンタに対するデバイス独立のプレゼンテーション／レイアウト配置オペレーションが実行される。グラフィックサブシステムおよびグラフィックデバイスドライバ２３４を含む他のコンポーネントによって、デバイスに固有フォーマットでプレゼンタのビューのレンダリングが行われる。ＯｎＲｅｎｄｅｒメソッド４７４のカスタマイズにより派生したものには、グラフィカルドキュメント／ユーザインターフェース出力をレンダリングするためのコンピュータシステムのグラフィックス生成コンポーネントへの呼出しが含まれる。

本発明の一実施形態で、ＯｎＲｅｎｄｅｒメソッド４７４の基底クラスバージョンによって、すべての子を含むプレゼンタのコンテンツが、３つのレイアウト処理ステージでレンダリングが行われる。ＯｎＲｅｎｄｅｒＢｅｆｏｒｅＣｈｉｌｄｒｅｎステージ中に、プレゼンタオブジェクトによって、そのすべての子プレゼンタの処理の前の処理について指定されたオペレーションが呼び出される。本発明の一実施形態では、ＯｎＲｅｎｄｅｒメソッド４７４の基底クラス実装によって、カスタマイゼーションのフックが提供され、ＯｎＲｅｎｄｅｒＢｅｆｏｒｅＣｈｉｌｄｒｅｎステージ中の前処理オペレーションは指定されない。しかし、このデフォルト挙動をカスタマイズした結果例示のように置換えられ、プレゼンタのディスプレイ領域のカスタム背景が確立／描画される。

ＯｎＲｅｎｄｅｒメソッド４７４の基底クラスバージョンによって、子レンダリングステージ中に、ｃｈｉｌｄｒｅｎプロパティ４１２で識別されるプレゼンタの子プレゼンタがアクセスされる。ＯｎＲｅｎｄｅｒメソッド４７４が、子プレゼンタのそれぞれに対して呼び出される（ＯｎＵｐｄａｔｅメソッド４７０が実行される時に子によって要求される範囲で）。したがって、ＯｎＲｅｎｄｅｒメソッド４７４へのトップレベル呼出しは、ツリーのボトムに達する（すなわち、プレゼンタが子を有しなくなる）まで、子プレゼンタおよびその子に順次段階的に行われる。トップレベル呼出しが完了すると、再レンダリングを要求したツリー内のすべての子プレゼンタが再レンダリングされている。

ＯｎＲｅｎｄｅｒＡｆｔｅｒＣｈｉｌｄｒｅｎステージ中に、プレゼンタオブジェクトによって、ｃｈｉｌｄｒｅｎプロパティ４１２で識別された子プレゼンタに対するＯｎＲｅｎｄｅｒメソッド４７４の呼出しの後で実行されるオペレーションが呼び出される。ＯｎＲｅｎｄｅｒメソッド４７４の基底クラスバージョンによって、カスタマイゼーションのフックが提供され、ＯｎＲｅｎｄｅｒＡｆｔｅｒＣｈｉｌｄｒｅｎステージ中の後処理オペレーションは指定されない。しかし、カスタマイゼーションの例には、注釈、装飾などが含まれる。

プレゼンタによりその子以外に何も再レンダリングされない場合、ＯｎＲｅｎｄｅｒメソッド４７４の基底クラスバージョンを上書きする必要はない。しかし、プレゼンタ自体によって何かを描画する必要がある場合、ＯｎＲｅｎｄｅｒメソッド４７４の基底クラスを上書きして、プレゼンタに割り当てられたスペース内でグラフィカルデータをレンダリングする。置換コードには、たとえば、アプリケーション２０４ならびに／またはグラフィックサブシステムおよびグラフィックスデバイスドライバへの呼出しが含まれる。チェーニングが行われたプレゼンタは、特定のビューのプレゼンタのツリー内にある。子プレゼンタが再レンダリングを必要とする場合、そのＯｎＲｅｎｄｅｒメソッドは、メインのプレゼンタのＯｎＲｅｎｄｅｒに似た方法でプレゼンタシステムによって呼び出される。

この応用例の文脈でいうと、「ヒットテスト」とは、どのプレゼンタがグラフィカルユーザインターフェースグリッドスペースの特定のグリッドポイントの下にあるかを識別する処理を指している。たとえば、ヒットテストは、ユーザがマウスボタンの１つを選択する時、マウスポインタがどこにあるか（たとえば、どのプレゼンタの上にあるか）を突き止めるのに使用される。ＯｎＨｉｔＴｅｓｔＤｅｔａｉｌメソッド４７６によって、プレゼンタのＨｉｔＴｅｓｔＤｅｔａｉｌ構造体に保管されたデータが返される。カスタマイズされたプレゼンタクラスでは、ＯｎＨｉｔＴｅｓｔＤｅｔａｉｌメソッド４７６の基底クラス実装を上書きして、ヒットされた要素およびプレゼンタ以外のデータをプレゼンタが返せるようにするためにＨｉｔＴｅｓｔＤｅｔａｉｌ構造体に書き込み、これによって、たとえば、プレゼンタの実際にヒットされた部分（たとえば、テキストの文字位置）などのプレゼンタに関するより詳細な情報を提供する。

ＯｎＣｒｅａｔｅＶｉｅｗＲｅｓｕｌｔメソッド４７８によって、ビュー結果オブジェクト内のプレゼンタの計算された状態を記述するパラメータが公開される。ユーザは、指定されたビューのコンテキスト内の要素に関してビュー結果オブジェクトを要求する。ＯｎＣｒｅａｔｅＶｉｅｗＲｅｓｕｌｔメソッド４７８の基底クラスバージョンによって、ビュー結果オブジェクトを介して、プレゼンタの高さ、幅、および左上角位置が提供される。プレゼンタに含まれるテキストの行数など、プレゼンタの状態に関する追加／代替の情報が望まれる場合、ＯｎＣｒｅａｔｅＶｉｅｗＲｅｓｕｌｔメソッド４７８の基底クラスバージョンをオーバーライドして、ビュー結果オブジェクトを介して所望の情報を提供する。

ｈｉｔ ｔｅｓｔメソッド４８０によって、指定されたプレゼンタをルートとするサブツリーに対するヒットテストが開始される。点の座標（プレゼンタのローカル座標での）が、ｈｉｔ ｔｅｓｔメソッド４８０に渡され、その座標に関してヒットテストが実行される。ｈｉｔ ｔｅｓｔメソッド４８０によって、指定された点およびプレゼンタに関するヒットテストの結果を含むヒットテストデータが返される。この結果には、その点でヒットしたすべてのビジュアルが含まれる。ビジュアルは、プレゼンタがそれからディスプレイイメージを派生させる基底オブジェクト（たとえば行）である。ビジュアルは、グラフィカルディスプレイ出力上に実際にイメージを描画する能力を有するグラフィカルオブジェクトである。プレゼンタのＯｎＲｅｎｄｅｒ呼出しでは、複数の呼出しが、たとえばテキスト、イメージ、ビデオなどをレンダリングするために、ビジュアルのＡＰＩに対して発行される。

ＯｎＧｅｔＢｙｐａｓｓＬｉｓｔメソッド４８２によって、識別されたプレゼンタについて前に計算された子プレゼンタのリストが供給される。子プレゼンタのリストによって、レイアウト計算中の子プレゼンタのバイパスが実現される（たとえば、リストに一致するものがある場合、新しい子レイアウトを前に計算された子レイアウトプレゼンタと比較し、前に計算されたプレゼンタを再利用する）。プレゼンタによって、ｃｈｉｌｄｒｅｎプロパティ４１２集合を参照することによりその子が発見される場合、そのプレゼンタは、このメソッドをオーバーライドする必要がない。しかし、プレゼンタによって、ＧｅｔＣｈｉｌｄＰｒｏｘｙＦｏｒＥｌｅｍｅｎｔメソッド４８６（以下で説明する）が使用される場合、一般にＯｎＧｅｔＢｙｐａｓｓＬｉｓｔメソッド４８２がオーバーライドされる。

本発明を実施するレイアウトシステムの応用例で、ＧｅｔＣｈｉｌｄＰｒｏｘｙＦｏｒＥｌｅｍｅｎｔメソッド４８６が呼び出される場合、ＯｎＧｅｔＢｙｐａｓｓＬｉｓｔメソッド４８２は、ＯｎＵｐｄａｔｅメソッド４７０の前に呼び出され、プレゼンタオブジェクトによって、以前のレイアウト計算からキャッシングされた子プロキシオブジェクトを有する配列リスト（図５を参照して以下で説明する）が作成され移植される。プレゼンタオブジェクトが、再計算された子プロキシオブジェクトを保管するキャッシュを有しない場合、そのプレゼンタオブジェクトのすべての子プレゼンタが、そのプレゼンタのＯｎＵｐｄａｔｅメソッド４７０のすべての呼出しで再計算される。

ｃａｌｃｕｌａｔｅ ｂｏｕｎｄｓメソッド４８４によって、識別されたビジュアルをルートとするサブグラフの境界が計算され返される。

子プロキシオブジェクトは、上記で説明したように、特定のグラフィカル要素の、親プレゼンタと子プレゼンタとの間の仲介として働くラッパーオブジェクトである。特定のプレゼンタオブジェクトの子プレゼンタの子プロキシオブジェクトは、プレゼンタオブジェクトのｃｈｉｌｄｒｅｎプロパティ４１２内の集合として参照される。ＧｅｔＣｈｉｌｄＰｒｏｘｙＦｏｒＥｌｅｍｅｎｔメソッド４８６は、指定された要素の子プロキシオブジェクトおよびプレゼンタオブジェクトを作成する親プレゼンタオブジェクトのメソッドである。このメソッドは、指定された要素がプレゼンタを有しない場合に「ｎｕｌｌ」を返す。

ＯｎＢｅｆｏｒｅＢｙｐａｓｓメソッド４８８は、プレゼンタシステム２００が特定のプレゼンタを「バイパス」する（すなわち、プレゼンタのＯｎＵｐｄａｔｅメソッド４７０の呼出しをスキップする）ことを望む時に呼び出される。そのようなバイパスは、たとえば、プレゼンタがダーティではなく、ＯｎＵｐｄａｔｅメソッド４７０呼出しの入力プレゼンタ寸法パラメータ（ＢｏｘＳｉｚｅＩｎｆｏ）が、そのプレゼンタへの最後のＯｎＵｐｄａｔｅメソッド４７０呼出しから変更されていない時に発生する。ＯｎＢｅｆｏｒｅＢｙｐａｓｓメソッド４８８は、子プロキシオブジェクトのそれ自体のカスタム集合（ＧｅｔＣｈｉｌｄＰｒｏｘｙＦｏｒＥｌｅｍｅｎｔメソッド４８６を使用する）を有するプレゼンタが、更新がレイアウトに対して実行される時（たとえば、レイアウトの小さい部分だけが変更によって影響される時）、その子の子プロキシオブジェクトを再利用できるようにするという性能強化機構である。

ＯｎＤｉｓｃｏｎｎｅｃｔＣｈｉｌｄｒｅｎメソッド４９０によって、指定されたプレゼンタのｃｈｉｌｄｒｅｎプロパティ４１２内で参照される子プレゼンタの組からすべての子プレゼンタオブジェクトが除去される。デフォルトのｃｈｉｌｄｒｅｎプロパティ４１２が、プレゼンタ基底クラス２１６から派生したプレゼンタクラスについてオーバーライドされる場合に、ＯｎＤｉｓｃｏｎｎｅｃｔＣｈｉｌｄｒｅｎメソッド４９０も、子プレゼンタの正しく破棄されることを保証するためにオーバーライドされる。

Ｍｉｎ／Ｍａｘパスは、コンテンツに合わせて子のサイズを変更する時、区分するプレゼンタ（たとえば、ＤｏｃｋＰｒｅｓｅｎｔｅｒ）によって使用される特殊なサイズ変更パスである。子の最小幅および最大幅を知ることによって、親が、特定の幅寸法を共有する複数の子の間でスペースを聡明に分配できるようになる。ＭｉｎＭａｘＰａｓｓ関数によって提供される最小値／最大値情報がないと、区分するプレゼンタは、コンテンツに合わせて聡明にサイズを変更するため複数のパスを必要とする。ＯｎＭｉｎＷｉｄｔｈメソッド４９２は、Ｍｉｎ／Ｍａｘパスの後で呼び出される。ＯｎＭｉｎＷｉｄｔｈメソッド４９２によって、ＭａｘＷｉｄｔｈ計算の副産物であるＭｉｎＷｉｄｔｈ値が収集される。ＯｎＭｉｎＷｉｄｔｈメソッド４９２の基底クラスバージョンによって、「アイドントケア」メッセージが発行され、これによって、ＰｒｏｐｏｓｅｄＳｉｚｅ＝（０、無限大）および両方向で「ＮｏｔＦｉｘｅｄ」を用いて計算パスが呼び出される。

ｐｒｅｓｅｎｔｅｒメソッド４９４は、プレゼンタインスタンスのコンストラクタメソッドである。ｐｒｅｓｅｎｔｅｒメソッド４９４は、パラメータを有しない。ｐｒｅｓｅｎｔｅｒメソッド４９４は、プレゼンタがプレゼンタシステム２００によってインスタンス化される時に呼び出される。ｐｒｅｓｅｎｔｅｒメソッド４９４によって、プレセンタインスタンスがセットアップされて、プレゼンタの他のメソッド（たとえば、ＯｎＵｐｄａｔｅ）を呼び出せるようになる。

ＱｕｅｕｅＬａｙｏｕｔＴａｓｋメソッド４９６によって、プレゼンタオブジェクトに関して実行される指定されたレイアウトタスクが、プレゼンタシステム２００によって実行されるレイアウトタスクのキューに追加される。指定されたレイアウトタスクが、キューの前面に達する時に、プレゼンタシステム２００によって、そのプレゼンタの通知ハンドラのＯｎＬａｙｏｕｔＴａｓｋメソッド６０２（以下で説明する）が呼び出される。

ＯｎＱｕｅｒｙＶａｌｕｅメソッド４９８によって、プレゼンタについて指定された計算値に対応する値が返される。

プレゼンタ基底クラス２１６を説明したので、図５に移ると、図５には、子プロキシクラス２２２の例示的実施形態のプロパティおよびメソッドの要約が示されている。以前説明したように、本発明の一実施形態では、子プロキシオブジェクトが、親プレゼンタオブジェクトの子であるプレゼンタオブジェクトのラッパーであり、親によるアクセスを子プレゼンタオブジェクトのリソースに制限することを支援する。親プレゼンタオブジェクトと子プレゼンタオブジェクトの間のすべての通信（要求／応答）のルーティングが、子プレゼンタの子プロキシを介して行われる。子プロキシオブジェクトによって、子プレゼンタへの参照が保持され、親プレゼンタによる呼出し／要求のルーティングが子プレゼンタに対し行われる。

プレゼンタシステム２００の一実施形態では、子プロキシクラス２２２にｅｌｅｍｅｎｔ ｏｗｎｅｒプロパティ５００が含まれ、このプロパティによって、子プロキシの参照されるプレゼンタが関連するグラフィカル要素２０６内の要素が指定される。

ｔｒａｎｓｆｏｒｍプロパティ５０２によって、子プレゼンタオブジェクト（およびそれに関連するビジュアル）が、親プレゼンタオブジェクト内で位置決めされる。変換は、ビジュアルオブジェクト基底クラスの標準的なグラフィックス３×３変換行列である。変換行列がセットアップされる時、プレゼンタのグラフィカル要素に関連するビジュアルオブジェクトによって、変換行列によって指定されるオフセットにその子が配置される。

ｂｏｕｎｄｉｎｇ ｂｏｘプロパティ５０４によって、子プレゼンタのレンダリング境界が指定される。したがって、子プレゼンタのレンダリング境界を子プレゼンタのレイアウトサイズと異なるものとすることができる。

ｄｉｒｔｉｎｅｓｓプロパティ５０６によって、子プロキシのプレゼンタのダーティネス状態が指定される。プレゼンタシステム２００の一実施形態では、ダーティ状態が、ｃｌｅａｎ、ｄｉｒｔｙ ｂｙｓｔａｎｄｅｒ、またはｄｉｒｔｙのいずれかである。ｃｌｅａｎ状態は、ビューの最後の更新以降に、子プレゼンタに対する変更がないことを示す。ｄｉｒｔｙ状態は、ビューの最後の更新以降に、子プレゼンタに対する変更が行われたことを示す。ｄｉｒｔｙ ｂｙｓｔａｎｄｅｒ状態は、子プレゼンタ自体の子の少なくとも１つがダーティであるが、子プレゼンタ自体はダーティでないことを示す。このような状態により、親プレゼンタは、更新オペレーションを最適化できるようになる。

ＱｕｅｒｙＤｅｆａｕｌｔＳｉｚｅＩｎｆｏメソッド５１０によって、子プレゼンタの寸法が、子プレゼンタの親プレゼンタによって供給されるデフォルト値に初期化される。

Ｕｐｄａｔｅメソッド５２０によって、子プロキシに、子プレゼンタオブジェクトのＯｎＵｐｄａｔｅメソッド４７０を呼び出すように要求する。親プレゼンタは、子プレゼンタのレイアウトの計算を要求する時に、子プロキシのＵｐｄａｔｅメソッド５２０を呼び出す。Ｕｐｄａｔｅメソッド５２０呼出しには、２つの渡されるパラメータが含まれる。ボックスサイズ情報によって、子がその中でのレイアウトを計算しなければならないボックスの寸法が指定され、ページ割り振りがアクティブ化されている場合、親プレゼンタは、ページ記述子パラメータ（以下で説明する図１０を参照されたい）でページ情報を渡す。したがって、Ｕｐｄａｔｅメソッド５２０によって、呼出し側と子プレゼンタオブジェクトの間の、子プレゼンタオブジェクトへの要求のスクリーニング／フィルタリングを可能にするレイヤがもたらされる。Ｕｐｄａｔｅメソッド５２０によって、通常は子プレゼンタのＯｎＵｐｄａｔｅメソッドにルーティングが行われる呼出しをバイパスする方法が提供される。たとえば、子プレゼンタが変更されておらず、入力パラメータ（ボックスサイズ情報およびページ記述）が変更されない時に、Ｕｐｄａｔｅメソッド５２０呼出しを呼び出すことができる。

親プレゼンタによって子プロキシに発行されるａｔｔａｃｈメソッド５３０によって、子プロキシに関連する子プレゼンタのＯｎＲｅｎｄｅｒコマンドが呼び出される。

ｑｕｅｒｙ ｖａｌｕｅメソッド５４０によって、メソッド呼出しで識別される計算された値型（プロパティ）に対応するプレゼンタ値が提供される。ｑｕｅｒｙ ｖａｌｕｅメソッド５４０呼出しは、子プレゼンタオブジェクトの対応するＯｎＱｕｅｒｙＶａｌｕｅメソッド４９８に委譲される。

ｑｕｅｒｙ ｌａｙｏｕｔ ｓｉｚｅメソッド５５０によって、計算されたｌａｙｏｕｔ ｓｉｚｅパラメータが提供される。ｑｕｅｒｙ ｌａｙｏｕｔ ｓｉｚｅメソッド５５０呼出しは、子プレゼンタオブジェクトの対応するＯｎＱｕｅｒｙＶａｌｕｅメソッド４９６に委譲される。ｃｏｍｐｕｔｅ ＭｉｎＭａｘメソッド５６０によって、子プレゼンタの最小幅および最大幅が提供される。

図６を参照すると、プレゼンタシステム２００に関連する基底クラスの組に、通知ハンドラ基底クラスが含まれる。上記で説明したように、通知ハンドラオブジェクトによって、特定のビューに関連するプレゼンタに潜在的に影響する変更に関するすべての通知が受け取られ、ダーティネス情報が蓄積され、関連するプレゼンタオブジェクトが更新を必要とするかどうかの判定が行われる。通知ハンドラ基底クラスの両方のメソッドが、パラメータとして、通知ハンドラに関連するグラフィカル要素（たとえばグラフィカル要素２０６）の要素からの関連情報を提供するメソッドを含むオブジェクトを受け取る。

通知ハンドラ基底クラスには、特定の関連するプレゼンタオブジェクトのダーティネスの通知を提供するＯｎＮｏｔｉｆｙメソッド６００が含まれる。ＯｎＮｏｔｉｆｙメソッド６００には、通知の受け取りに応答して実行される追加のカスタマイズされた派生通知タスク（ｄｉｒｔｉｎｅｓｓプロパティ値を提供するデフォルトアクションをオーバーライドすることによる）が潜在的に含まれる。ＯｎＮｏｔｉｆｙメソッド６００は、入力パラメータとして、通知をもたらす変更に関する情報を受け取る。ＯｎＮｏｔｉｆｙメソッドは、通知ハンドラがそれ自体で変更を処理できるか否か（または、ビューのプレゼンタツリー内の上位プレゼンタの通知ハンドラに通知する必要があるかどうか）を示すブール値を返す。このメソッドは、プレゼンタが「ｃｌｅａｎ」、「ｄｉｒｔｙ」、または「ｄｉｒｔｙ ｂｙｓｔａｎｄｅｒ」のどれであるかを示すダーティネス値も返す。

ＯｎＬａｙＯｕｔＴａｓｋメソッド６０２によって、ＱｕｅｕｅＬａｙｏｕｔＴａｓｋ４９６を介して関連するプレゼンタによって以前キューに入れられたすべてのタスクが実行される。

図７を参照すると、プレゼンタシステム２００に関連する基底クラスの組に、さらに、通知ハンドラサイトクラスが含まれる。通知ハンドラサイトクラスは、通知ハンドラオブジェクトに渡されるサイトオブジェクトであり、この通知ハンドラオブジェクトによりプレゼンタシステム２００によってサポートされる通知サービスの呼び出しが可能となる。

通知ハンドラサイトクラスには、通知ハンドラサイトオブジェクトに関連するグラフィカル要素オブジェクトを指定するｅｌｅｍｅｎｔ ｏｗｎｅｒプロパティ７００が含まれる。

ｒｅｇｉｓｔｅｒ ａｔｏｍメソッド７０２によって、通知ハンドラのｌａｙｏｕｔ ｃｏｎｔｅｘｔ４４４内で提供されるストリング名が登録される。ｒｅｇｉｓｔｅｒ ａｔｏｍメソッド７０２の機能性は、プレゼンタ基底クラスに関して上記で説明したｒｅｇｉｓｔｅｒ ａｔｏｍメソッド４７１に類似する。したがって、ｒｅｇｉｓｔｅｒ ａｔｏｍメソッド７０２は、通知ハンドラによる要求を他のオブジェクト（たとえば、プレゼンタオブジェクト）に通信する手段となる。

ｃｒｅａｔｅ ｎｏｔｉｆｉｃａｔｉｏｎメソッド７０４によって、新しいプレゼンタ通知オブジェクトが作成され、渡されたパラメータに基づいてその諸フィールドが初期化される。渡されるパラメータには、アトム型の識別（プレゼンタ通知オブジェクト型を示す）および通知データが含まれる。

ｎｏｔｉｆｙ ｄｅｓｃｅｎｄｅｎｔｓメソッド７０６によって、通知ハンドラサイトに関連するプレゼンタの下位オブジェクトに関連する通知ハンドラのＯｎＮｏｔｉｆｙメソッド６００が呼び出されて、指定されたプレゼンタ通知が渡される。ｎｏｔｉｆｙ ｄｅｓｃｅｎｄｅｎｔｓメソッド７０６によって、親プレゼンタに対するすべての変更（たとえば、サイズ変更）に関する下位プレゼンタへの通知の機能が実行される。同様に、ｎｏｔｉｆｙ ａｎｃｅｓｔｏｒｓメソッド７０８によって、通知ハンドラサイトに関連するプレゼンタの上位オブジェクトに関連する通知ハンドラのＯｎＮｏｔｉｆｙメソッド６００が呼び出されて、指定されたプレゼンタ通知が渡される。上位オブジェクトは、バッキングストア２０８内のグラフィカル要素ツリー（図３を参照されたい）を横切ること（ｔｒａｖｅｒｓｉｎｇ）によって判定される。バッキングストア内で表されるグラフィカル要素に、グラフィカル要素の親（直接の上位オブジェクト）を指定するプロパティが含まれる。ｎｏｔｉｆｙ ａｌｌメソッド７１０によって、ビューによって所有されるプレゼンタツリー内のすべてのプレゼンタの通知ハンドラオブジェクトのＯｎＮｏｔｉｆｙメソッド６００が呼び出されて、指定された通知が渡される。最後に、ｎｏｔｉｆｙ ｓｅｌｆメソッド７１２によって、プレゼンタがそれ自体をダーティとしてマークするためにＯｎＮｏｔｉｆｙメソッド６００を呼び出す手段が提供される。

図８に移ると、例示的なビューオブジェクトクラスが示されているが、ビュー２０２はこれからインスタンス化される。ビューオブジェクトは、プレゼンタシステムのインスタンス（たとえば、プレゼンタシステム２００）を所有し、作成されるプレゼンタシステムインスタンス内で作成されるすべてのビジュアルのビジュアルルートである。ビューオブジェクトによって、ビュー内のプレゼンタに対するすべての計算が初期設定される。ｖｉｅｗメソッド８００は、新しいビューオブジェクトの作成に使用されるコンストラクタメソッドである。ビューは、渡されるパラメータとして、ビューのルートグラフィカル要素である要素への参照を受け取る。ＲｏｏｔＥｌｅｍｅｎｔプロパティ８０２によって、ビューのルートグラフィカル要素（上記で述べたｖｉｅｗメソッド８００を介して確立される）への参照が返される。

ＤｏＬａｙｏｕｔメソッド８０４によって、ビューの新しいプレゼンタツリーが作成され、新しいツリーへの参照が返される。ＤｏＬａｙｏｕｔメソッド８０４は、入力パラメータとして、ビュー長方形の提案される高さおよび幅、および提案された寸法をＤｏＬａｙｏｕｔメソッド８０４実行中に変更できるかどうかを確立する２つのブール値（ｆｉｘｅｄｗｉｄｔｈおよびｆｉｘｅｄｈｅｉｇｈｔ）を受け取る。

ＶｉｅｗＳｉｚｅプロパティ８０６によって、ビューの寸法がセットされる。ＶｉｅｗＳｉｚｅプロパティ８０６は、書き込み専用プロパティであるが、ビューオブジェクトがウィンドウ内でホスティングが行われる時に使用され、ＶｉｅｗＳｉｚｅプロパティ８０６によって、レイアウトオペレーションがそこから実行される初期のサイズが示される。

ＧｅｔＶｉｅｗＲｅｓｕｌｔメソッド８０８は、入力としてグラフィカル要素参照を受け取り、ＧｅｔＶｉｅｗＲｅｓｕｌｔメソッド８０８は、グラフィカル要素の結果のビューを返す。ｎｕｌｌの値は、グラフィカル要素が、ビューのグラフィカル要素の組の中で見つからない場合に返される。

ＨｉｔＴｅｓｔメソッド８１０によって、ビューの座標系内での渡された点のヒットテストが実行される。ＨｉｔＴｅｓｔメソッド８１０は、最初の非透明ヒットテストターゲットを返す。グラフィカル要素にヒットしない場合、このメソッドは「ｆａｌｓｅ」を返す。

ＣｒｅａｔｅＰａｇｅメソッド８１２は、入力としてパラメータＢｏｘＳｉｚｅＩｎｆｏ（以下で説明する図９を参照されたい）およびＰａｇｅＤｅｓｃｒｉｐｔｏｒ（以下で説明する図１０を参照されたい）を受け取る。ＣｒｅａｔｅＰａｇｅメソッド８１２は、入力パラメータに基づいて新しいページを作成し、そのページのルートグラフィカル要素に対応する子プロキシオブジェクトを返す。

図９に移ると、例示的なＢｏｘＳｉｚｅＩｎｆｏ構造体が示されている。ＢｏｘＳｉｚｅＩｎｆｏ構造体によって、ビュー内のプレゼンタおよびその子プレゼンタの寸法の組ならびに受け取る側がこれらの寸法をどのように使うかが指定される。ｐｒｏｐｏｓｅｄ ｓｉｚｅプロパティ９００によって、ビュー内の子プレゼンタの提案されるサイズが示される。当初、ｐｒｏｐｏｓｅｄ ｓｉｚｅプロパティ９００の値が、バッキングストア内の子グラフィカル要素のプロパティから与えられる。この値は、子に渡す前に、親プレゼンタによって修正することができる。ｐａｒｅｎｔ ｓｉｚｅプロパティ９０２は、親プレゼンタの推奨されるサイズである。ｐａｒｅｎｔ ｓｉｚｅプロパティ９０２は、たとえば、親の値のパーセント値から子プレゼンタの寸法を計算するのに使用される。ＢｏｘＳｉｚｅＩｎｆｏ構造体には、２つのブール値プロパティ、ＦｉｘｅｄＷｉｄｔｈ９０４およびＦｉｘｅｄＨｅｉｇｈｔ９０６も含まれ、これによって、受取り側のプレゼンタに、供給される寸法が負荷された（固定された）値であるか否か、または寸法値が単に推奨された高さまたは幅であるかどうかが指示される。

図１０に移ると、例示的なｐａｇｅ ｄｅｓｃｒｉｐｔｏｒ構造体が示されている。ｐａｇｅ ｄｅｓｃｒｉｐｔｏｒには、ＰａｇｅＳｉｚｅプロパティ１０００が含まれる。ＰａｇｅＳｉｚｅプロパティ１０００は、ページのサイズを指定する読取専用のプロパティである。これは、ｐａｇｅ ｄｅｓｃｒｉｐｔｏｒ構造体が作成される時に初期化される。ｂｒｅａｋ ｒｅｃｏｒｄプロパティ１００２は、次のページにある現在のプレゼンタの最初の文字（ページ割り振りされつつあるビューのルートであるグラフィカル要素に関する）を識別する文字開始位置（ｃｈａｒａｃｔｅｒ ｐｏｓｉｔｉｏｎ ｓｔａｒｔ）、前のページを無効化することができる文字数（ｎｕｍｂｅｒ ｏｆ ｃｈａｒａｃｔｅｒｓ）（ｃｈａｒａｃｔｅｒ ｐｏｓｉｔｉｏｎ ｓｔａｒｔから後ろに数える）、およびブレークレコード（ページ割り振りされるグラフィカル要素内の特定の文字範囲を含む）が、バッキングストアに対する変更によって無効化されるかどうかを示すＩｓＤｉｒｔｙ ブール値を含む構造体である。

ｐａｇｅ ｄｅｓｃｒｉｐｔｏｒ構造体には、ＡｖａｉｌａｂｌｅＳｉｚｅプロパティ１００４も含まれる。プレゼンタのＯｎＵｐｄａｔｅメソッドを開始する時、ページ全体がプレゼンタから使用可能ではない場合がある。ＡｖａｉｌａｂｌｅＳｉｚｅプロパティ１００４によって、プレゼンタに関するページの残りのスペースが示される。ＡｖａｉｌａｂｌｅＳｉｚｅプロパティ１００４は、ページサイズの値に初期化される。

図１１に移ると、ビュー２０２（図２を参照されたい）によって作成されるプレゼンタシステム２００のプレゼンテーションエンジン２１２によって実行されるメソッドの組が識別されている。プレゼンテーションエンジン２１２のｃｏｎｓｔｒｕｃｔｏｒメソッド１１００によって、（グラフィカル要素２０６ツリーによって提供される）ビューのルートグラフィカル要素への参照を含むビュー２０２がアクセスされる。ＤｏＬａｙｏｕｔメソッド１１０２は、渡されるパラメータとしてビュー２０２の寸法を表すｗｉｄｔｈおよびｈｅｉｇｈｔを受け取り、これに応答して、グラフィカル要素２０６のコンテンツに関するレイアウト処理の実行を開始する。ＵｐｄａｔｅＬａｙｏｕｔメソッド１１０４は、ＤｏＬａｙｏｕｔを実行した後に少なくとも１回実行されるが、これによって、ビュー２０２の以前に計算されたレイアウトに対する増分的変更の適用が開始される。ＣｒｅａｔｅＰａｇｅメソッド１１０６は、入力パラメータとして、レイアウトされるページの寸法を含むボックスサイズ情報（ＢｏｘＳｉｚｅＩｎｆｏ）と、特定のページを開始する方法に関する情報を含むｐａｇｅ ｄｅｓｃｒｉｐｔｏｒを受け取る。ビュー２０２のグラフィカル要素２０６のルートの下のすべてのコンテンツをレイアウトするのではなく、ＣｒｅａｔｅＰａｇｅメソッド１１０６では、関心のある１つのページだけがレイアウトされる。

例示的なレイアウト処理アーキテクチャを図１から１１を参照して説明した。例示的なアーキテクチャには、要素データ状態（グラフィカル要素オブジェクト）にリンクされた別々のビュー状態（プレゼンタオブジェクト）が含まれる。例示的なアーキテクチャにはプレゼンタシステム２００が含まれ、これにより新しいレイアウト／プレゼンテーション機能性を実施する新しいプレゼンタオブジェクトクラスがそこから派生されるプレゼンタ基底クラス２１６を介してビューレイアウト／プレゼンテーション機能性の拡張が実現される。本明細書で開示されるシステムおよびアーキテクチャには、要素をそれに対応するプレゼンタオブジェクトにリンクして、変更に応答しビューの再計算部分を選択的に呼び出す通知機構も含まれる。この例のオブジェクト基底クラスは、本発明を実施する拡張可能なアーキテクチャを実行する多数の潜在的な代替の形を示すものであって、本発明の範囲を制限するものとみなしてはならない。

本発明を実施する例示的なプレゼンテーション／レイアウト処理アーキテクチャを構成するコンポーネントの組を説明したので、図１２に移ると、図１２には、グラフィカルに表示される要素に対する変更の処理の全般的な流れが示されている。まず、１２００で、バッキングストア２０８を変更する。たとえば、アプリケーション２０４によって、そのアプリケーションのグラフィカルユーザインターフェースの表示されるコンポーネントの１つまたは複数の状況および／またはコンテンツの変更をもたらすオペレーションが実行される。それに応答して、ステップ１２０２で、バッキングストア内のグラフィカル要素の変更から生じる変更通知が、プレゼンタシステム２００のプレゼンテーションエンジン２１２によって受け取られる。

背景として、ステップ１２０４を参照すると、プレゼンタシステム２００によって、要素とプレゼンタとの間の関連が、要素−プレゼンタ情報（ＥＰＩ）内で保持される。プレゼンタが、グラフィカル要素について作成される時、必ずそのプレゼンタへの参照が要素側で作成され、プレゼンタシステムにより保持されるＥＰＩに保管される。グラフィカル要素が、複数のプレゼンタを有する場合、グラフィカル要素のＥＰＩ内に複数（プレゼンタごとに１つ）の参照がある。グラフィカル要素のプロパティが変更される時、下記のステップが行われる。

（ａ）バッキングストア２０８によって、グラフィカル要素に関する変更が通知される。
（ｂ）バッキングストア２０８によって、プロパティの１つに対する変更を経験したグラフィカル要素への参照と共に、変更がプレゼンテーションエンジン２１２に通知される。
（ｃ）プレゼンテーションエンジン２１２によって、変更されたグラフィカル要素のＥＰＩが調査（ｗａｌｋ）され、そのグラフィカル要素のために作成されたプレゼンタが判定される。
（ｄ）プレゼンタが判定されると、プレゼンテーションエンジン２１２によって、プレゼンタの対応する通知ハンドラへの参照が（プレゼンタのｎｏｔｉｆｉｃａｔｉｏｎ ｈａｎｄｌｅｒプロパティ４４６を介して）入手される。

したがって、上記を考慮して、ステップ１２０４で、プレゼンタシステム２００のプレゼンテーションエンジン２１２によって、変更通知が適用されるプレゼンタの同一性が判定される。上記で説明したように、プレゼンタシステムによって、ＥＰＩ内の要素についてインスタンス化されたプレゼンタのリストが保持される。変更通知が適用されるプレゼンタを判定した後に（この例では、要素に関して単一のプレゼンタだけが存在すると仮定する）、プレゼンタシステムのプレゼンテーションエンジン２１２によって、識別されたプレゼンタのｎｏｔｉｆｉｃａｔｉｏｎ ｈａｎｄｌｅｒプロパティ４４６を介して、プレゼンタの通知ハンドラへの参照が入手される。

その後、ステップ１２０６中に、プレゼンタシステム２００のプレゼンテーションエンジン２１２によって、ステップ１２０４で入手した参照を使用し、通知ハンドラに変更通知が転送される。本発明の一実施形態では、ステップ１２０６は、特定の通知ハンドラオブジェクトのＯｎＮｏｔｉｆｙメソッド６００を呼び出すことによって実行される。

プレゼンタシステムから変更通知を受け取った後に、ステップ１２０８中に（たとえば、ＯｎＮｏｔｉｆｙメソッド６００の実行中に）、通知ハンドラによって、バッキングストア２０８内のグラフィカル要素に対するステップ１２００中の変更に応答してプレゼンタによって要求されたアクションがある場合、そのアクションが判定される。本発明の一実施形態では、通知ハンドラによって、受け取られた変更通知を考慮して、対応するプレゼンタのどの部分が（存在する場合に）更新を必要とするかが判定される。そのような部分には、たとえば、プレゼンタの子およびプレゼンタ自体が含まれる。

その後、ステップ１２１０中に、通知ハンドラ（たとえば、ＯｎＮｏｔｉｆｙメソッド６００）によって、結果が返され、この結果によって、対応するプレゼンタが、ステップ１２０２中に、プレゼンタシステム２００によって受け取られた変更通知を考慮してアクションを判定し、実行できるようになる。本発明の一実施形態では、返される結果の形が、通知ハンドラ／プレゼンタ固有である。いくつかの場合に、返される結果によって、プレゼンタが単に「ダーティ」としてラベルを付けられ、これによって、対応するプレゼンタの完全な再計算が呼び出される。他の場合に、プレゼンタのビュー再計算機能の一部だけを選択的に呼び出す情報が提供される。

本発明の一実施形態では、プレゼンタシステム２００のプレゼンテーションエンジン２１２によって、ステップ１２１０中にプレゼンタに通知ハンドラから返された結果が受け取られる。その後、ステップ１２１２で、バッキングストアに対する変更があったが、プレゼンタの再計算が必要ではなかった場合、制御は判断ブロック１２１６に進む。しかし、ステップ１２１２で、返された結果から、プレゼンタが再計算が必要であると示される場合、制御はステップ１２１４に移り、ここで、プレゼンタシステム２００によって、再計算を必要とする「ダーティ」プレゼンタの組にプレゼンタが追加される。本発明の例示的な実施形態では、プレゼンタシステムによって、対応するプレゼンタのｄｉｒｔｉｎｅｓｓプロパティ４５０が設定され（再計算が必要なプレゼンタであることを示す）、再計算が必要なプレゼンタの組にプレゼンタが追加される。プレゼンタによって、ｄｉｒｔｉｎｅｓｓプロパティ４５０の設定に至った変更の範囲を記述する情報も指定される。その後、制御はステップ１２１６に移る。

ステップ１２１６で、現在問題の通知ハンドラに関連するプレゼンタについて親プレゼンタが存在しない場合、制御は終了１２１８に移る。親プレゼンタが実際に存在する場合、制御はステップ１２１６からステップ１２２０に移り、ステップ１２８０に戻る破線によって示されるように、親プレゼンタの通知ハンドラに関する（に渡される）通知が作成される（親の通知ハンドラによる通知の処理をもたらす）。

したがって、図１２に示されたステップの組によって、プレゼンタシステム２００が、ドキュメント／ユーザインターフェースのレイアウトが最後に計算されてから後の、バッキングストア２０８への変更の結果として「ダーティ」にされたプレゼンタのリストを蓄積できるようになる。

図１３に移ると、フローチャートによって、特定のビューのプレゼンタに対する変更に従うドキュメント／ユーザインターフェースの再計算／再レンダリングの例示的な処理が示される（上記で説明した図１２を参照されたい）。本発明の一実施形態では、アプリケーション２０４によって、ビュー２０２に対する更新が制御され、期間の満了、ドキュメント印刷要求、またはグラフィカルユーザインターフェースの状況の変更などのイベントに応答して、図１３に要約されたものなどのビュー更新手順が呼び出される。

まず、ステップ１３００中に、プレゼンタシステム２００、具体的にはプレゼンテーションエンジン２１２によって、ＤｏＬａｙｏｕｔメソッド１１０２（上記でプレゼンテーションエンジン２１２ＡＰＩ記述に関して説明した）への呼出しが受け取られる。アプリケーション２０４によるＤｏＬａｙｏｕｔメソッド１１０２呼出しの受け取りに応答して、プレゼンタシステム２００により、ビュー２０２に含まれるプレゼンタオブジェクトが再計算されて、最後のＤｏＬａｙｏｕｔメソッド１１０２呼出し以降のバッキングストア２０８内の要素に対する変更に対応する。

ビューのプレゼンタが階層的に配置される（図３を参照されたい）本発明の一実施形態では、プレゼンタシステム２００によって、当初、ステップ１３０２で、ビューのルートプレゼンタが判定される。本発明の一実施形態では、ルートプレゼンタが、ビュー（たとえばビュー２０２ａ）、したがってプレゼンタシステム（たとえばプレゼンタシステム２００ａ）に委ねられるルート要素に関するｐｒｅｓｅｎｔｅｒプロパティによって識別される。ルートプレゼンタを判定した後に、制御はステップ１３０４に移り、プレゼンタシステム２００によって、ビューのプレゼンタのツリーが横切られ、各ダーティプレゼンタが再計算される。

ステップ１３０４中に、プレゼンタシステム２００によって、ビュー内の各ダーティプレゼンタのＯｎＵｐｄａｔｅメソッド４７０が呼び出される。呼び出されるＯｎＵｐｄａｔｅメソッド４７０は、プレゼンタがその中でレイアウトを再計算する長方形の高さおよび幅を渡される。レイアウトを再計算した後に、プレゼンタは、その結果をキャッシングする。したがって、ステップ１３０４の完了時に、前にダーティであったプレゼンタが、再計算され、その結果を後続の再レンダリング中に容易にアクセスするためキャッシングされる。ダーティビットが、呼び出されたプレゼンタのそれぞれでクリアされる。例示的なＯｎＵｐｄａｔｅメソッド４７０呼出し中に実行されるステップの組を、以下で図１４を参照して詳細に説明する。

ステップ１３０４中にダーティプレゼンタをクリーンにする複数の方法がある。しかし、本発明の一実施形態では、プレゼンタシステム２００、具体的にはプレゼンテーションエンジン２１２のＵｐｄａｔｅＬａｙｏｕｔメソッド１１０４によって、ステップ１３０４を完了する際の役割を単純にするために、ビュー内のプレゼンタの間の階層関係が活用される。具体的に言うと、ＯｎＵｐｄａｔｅメソッド４７０の実行中に、呼び出されるプレゼンタのそれぞれによって、呼び出されるプレゼンタのすべての子のＯｎＵｐｄａｔｅメソッド４７０が反復して呼び出される（または、その代わりに、呼び出すようにプレゼンタシステム２００に要求する）。したがって、プレゼンタシステム２００によって、ルートプレゼンタ（たとえば図３のプレゼンタＰ１）のＯｎＵｐｄａｔｅメソッド４７０でプレゼンタツリーを横切ることが開始され、ＯｎＵｐｄａｔｅメソッド４７０の呼出しがダーティプレゼンタの再計算のために階層プレゼンタツリーの枝をトラバースする際の、子プレゼンタへの後続の呼出しがサポートされる。子プレゼンタのＯｎＵｐｄａｔｅメソッド４７０への反復的呼出しによって、ビュー内のすべてのプレゼンタが横切られ、プレゼンタがダーティである場合に再計算されることが保証される。

完了時に、ステップ１３０４中に呼び出される各ＯｎＵｐｄａｔｅメソッド４７０によって、ｄｉｒｔｉｎｅｓｓプロパティ４５０がリセットされ、再計算されたまたは「クリーンにされた」ことが示される。各ＯｎＵｐｄａｔｅメソッド４７０によって、プレゼンタが再レンダリング（すなわち再描画）を必要とするかどうかを示す値も、呼出し側に返される。本発明の一実施形態では、返される値はブール値である。「ｔｒｕｅ」の場合、再レンダリングが必要である。「ｆａｌｓｅ」が返される場合には、再レンダリングは不要である。ステップ１３０４中のビューのダーティプレゼンタのそれぞれの処理の後に、制御はレンダリングステップ１３０６に移り、再レンダリングが必要なプレゼンタのリストで識別されるプレゼンタが処理される。

ステップ１３０６中に、プレゼンタシステム２００によって、再レンダリングが必要なプレゼンタのリストで識別される各プレゼンタのＯｎＲｅｎｄｅｒメソッド４７４が呼び出される。ＯｎＲｅｎｄｅｒメソッド４７４の例示的な実施形態のオペレーションを図１４を参照して説明する。ＯｎＲｅｎｄｅｒメソッド４７４の基底クラスの実装では、プレゼンタは何も描画せず、その代わりに、その子および／またはチェーニングが行われたプレゼンタのＯｎＲｅｎｄｅｒメソッド４７４を反復して呼び出し、割り当てられたスペース（たとえば長方形）を塗り潰す。ＯｎＲｅｎｄｅｒメソッド４７４のカスタマイズされたバージョンでは、アプリケーション２０４および／またはグラフィックサブシステムおよびグラフィックデバイスドライバ２３４のＡＰＩへの呼出しによってビットマップをレンダリングする。ステップ１３０６中に再レンダリングを要求したすべてのプレゼンタの処理の後に、制御は終了１３０８に移り、特定のビューのプレゼンテーションエンジンのＤｏＬａｙｏｕｔメソッド１１０２の呼出し側に戻る。

図１４に移ると、ビューのプレゼンタを再計算するために実行されるＯｎＵｐｄａｔｅメソッド４７０のステップがフローチャートに要約されている。ＯｎＵｐｄａｔｅメソッド４７０によって、すべての子プレゼンタを含むプレゼンタの新しいレイアウトが計算され、再レンダリングステージ中のアクセスのために結果がキャッシングされる。以下で示す例では、各プレゼンタへのＯｎＵｐｄａｔｅメソッド４７０呼出しによって、制限を指定する寸法の組が、プレゼンタのレイアウトによって占めることができるビュースペース（たとえば、長方形に）渡される。寸法の組によって、たとえば、高さおよび幅ならびにこれらの値をＯｎＵｐｄａｔｅメソッド４７０呼出しの実行中に修正できるかどうかが指定される。しかし、本発明では、ビュースペース寸法を含むレイアウトに影響するさまざまな渡されるパラメータのいずれか１つまたは複数に基づくプレゼンタの再計算が企図されている。

ステップ１４００中に、プレゼンタによって、更新を実行するために子プレゼンタを呼び出す（子プロキシオブジェクトを介して）前に、渡されたパラメータから生じるすべての必要なサイズ変更オペレーションが実行される。そのような作業の内容は、特定のプレゼンタ型の設計に依存する。その後、プレゼンタによって、プレゼンタシステム２００を呼び出して、現在のプレゼンタのすべての子プレゼンタを突き止め、更新する。前処理ステージ中に、プレゼンタによって、潜在的に、新しいページ／列を作成する必要があるか否かが検出され、ビューの新しいページ／列を処理する新しい子プロキシ／プレゼンタが作成される。

次に、ステップ１４０２中に、現在の親プレゼンタのＯｎＵｐｄａｔｅメソッド４７０によって、レイアウトを更新するために次に呼び出される子プレゼンタが判定される。このステップは、少なくとも最初のインスタンスで、親プレゼンタが子要素の存在を判定し、対応する子プロキシ／プレゼンタを作成することが必要であることに留意されたい。後の反復では、親プレゼンタが、ｃｈｉｌｄｒｅｎフィールド４１２で識別されるキャッシングされた子プロキシを使用して、次の残りの（未処理の）子プロキシ／プレゼンタ、すなわち現在の親プレゼンタのＯｎＵｐｄａｔｅメソッドの現在の反復中にまだ呼び出されていない子プレゼンタを識別することができる。

親プレゼンタによって、バッキングストアからの応答が受け取られるか、ｃｈｉｌｄｒｅｎプロパティ４１２から、処理すべき子プレゼンタが残っているかどうかが親プレゼンタ自体によって判定され、ステップ１４０４で、更新すべき未処理の子が残っていない場合、制御はステップ１４２０（以下で説明する）に移る。これと異なり、プレゼンタが、まだ更新されていないｃｈｉｌｄｒｅｎプロパティ４１２内に未処理の子プレゼンタを有する場合、制御はステップ１４０６に移る。

ステップ１４０６で、プレゼンタによって、親プレゼンタと現在問題の子プレゼンタとの間にはさまれた返された子プロキシのＵｐｄａｔｅメソッド５２０が呼び出されて、子プロキシが関連する子プレゼンタの高さおよび幅が入手される。この子プレゼンタは、特定のグラフィカル要素（そのｅｌｅｍｅｎｔ ｏｗｎｅｒフィールド４４２で指定される）に関連する。

ステップ１４１０で、子プロキシによって、その子プロキシが関連する子プレゼンタのＯｎＵｐｄａｔｅメソッド４７０が呼び出される。ＯｎＵｐｄａｔｅメソッド４７０によって、子プレゼンタの更新された高さおよび幅（したがって再レンダリングが必要であるかどうか）が計算される。ステップ１４１０中に、呼び出される子プレゼンタが、ステップ１４０２で子を有しないと判定し、その呼出し元の親プレゼンタに（その子プロキシを介して）返されるまで、ＯｎＵｐｄａｔｅメソッド４７０が子プレゼンタによって再帰的に呼び出されることに留意されたい。子プレゼンタのＯｎＵｐｄａｔｅメソッド４７０を呼び出した後に、制御はステップ１４１４に移る。

したがって、ステップ１４１４で、呼出し側の親プレゼンタ（ステップ１４０６から）によって、識別された子プロキシへのＵｐｄａｔｅメソッド５２０呼出しに対する応答が受け取られる。応答には、返されるパラメータとして、子プレゼンタの高さおよび幅が含まれる。応答には、呼び出された子プレゼンタが再レンダリングを必要とするかどうかも含まれる。次に、ステップ１４１６で、親プレゼンタによって、配置アルゴリズム／ポリシに基づいて、親プレゼンタの割り当てられたレイアウトスペース内で、呼び出された子プレゼンタが位置決めされる。本発明の一実施形態では、ステップ１４１６中に、親プレゼンタによって、ステップ１４１４中にプレゼンタにより受け取られた子プレゼンタのｈｅｉｇｈｔパラメータおよびｗｉｄｔｈパラメータに基づきレイアウト内で子プレゼンタが位置決めされる。

制御は、ステップ１４０２に戻り、親プレゼンタのＯｎＵｐｄａｔｅメソッド４７０が継続されて、残りの子プレゼンタが更新される（子プロキシラッパーオブジェクトを介して）。

ステップ１４０４で、処理／更新すべき子（要素またはプロキシ／プレゼンタ）が残っていない場合、制御はステップ１４２０に移る。ステップ１４２０では、呼び出されたプレゼンタのＯｎＵｐｄａｔｅメソッド４７０によって、プレゼンタのレイアウトを調整するための子プレゼンタのＯｎＵｐｄａｔｅメソッド４７０への潜在的なさらなる呼出しを含むカスタマイズされたレイアウト機能が実行される。

ステップ１４２２で、または潜在的に、新しい情報がＯｎＵｐｄａｔｅメソッド４７０によって導出されるすべての点で、レイアウト処理の結果が、グラフィカルビュー処理の再レンダリングステージ中の後の使用のためにキャッシングされる。

更新処理が、呼び出されるプレゼンタのすべての子を含むプレゼンタについて完了した後に、ステップ１４２４で、プレゼンタによって、その呼出し側（プレゼンタシステム２００）に、寸法およびプレゼンタが再レンダリングを必要とするかどうかを示す値が返される。

当業者は、新しい例示的なプラットフォームおよび例示的な方法が、グラフィカルユーザインターフェースディスプレイまたはプリンタなどのグラフィカル出力デバイスを含むコンピューティング環境内でのグラフィカルドキュメント／ユーザインターフェース出力のレイアウト／プレゼンテーション処理の管理に関して説明されたことを理解するであろう。本発明を適用できる多数の可能な環境およびソフトウェアユーティリティの設計および実行の柔軟性に鑑みて、本明細書に記載の実施形態が、例示であることを意図され、本発明の範囲を制限するものと解釈してはならないことを認識されたい。本発明が適用される技術の技量を有する者は、本発明の趣旨から逸脱せずに、示された実施形態を配置および詳細において修正できることを諒解するであろう。したがって、本明細書に記載の発明では、そのような実施形態のすべてが、請求項およびその等価の範囲に含まれるものとして企図されている。

本発明の実施形態を実行する例示的なコンピュータシステムを示すブロック図である。 本発明のコンピュータシステム実施形態でグラフィカルレイアウト保持を実行するプレゼンタシステムを含むレイアウト管理アーキテクチャの主要なコンポーネントを示す高水準概略図である。 本発明を実施するシステムでグラフィカルドキュメント／ユーザインターフェースを定義するグラフィカル要素とプレゼンタの間の関係を示す概略図である。 本発明を使用するシステムでの、カスタマイズされたプレゼンタオブジェクトクラスが特定のレイアウト／レンダリングタスクを実行するためにそこから派生されるプレゼンタ基底クラスの構造を要約した図である。 本発明を使用するシステムでの、カスタマイズされたプレゼンタオブジェクトクラスが特定のレイアウト／レンダリングタスクを実行するためにそこから派生されるプレゼンタ基底クラスの構造を要約した図である。 子プロキシクラスの構造を要約した図である。 通知ハンドラクラスインターフェースの構造を要約した図である。 通知ハンドラサイトクラスの構造を要約した図である。 ビュークラスの構造を要約した図である。 ＢｏｘＳｉｚｅＩｎｆｏ構造体の諸部分を要約した図である。 ｐａｇｅ ｄｉｓｃｒｉｐｔｏｒ構造体の諸部分を要約した図である。 プレゼンテーションエンジンクラスの構造を要約した図である。 グラフィカル要素に対する変更の通知ハンドラベースの処理の例示的なステップを要約したフローチャートである。 本発明の実施形態による、プレゼンタの組を含むビューの再計算およびレンダリングの例示的なステップを要約したフローチャートである。 関係するグラフィカル要素に対する変更に応答する、プレゼンタ（および関連する影響される子）に対する更新を実行するステップを例示的に示すフローチャートである。

Claims (50)

1. コンピューティングシステムで実行されるプログラムにより出力されるグラフィカル表示を配置および保持するグラフィカル出力レイアウト管理システムであって、
   プログラムの表示可能なコンテンツを表すデータを含むグラフィカル要素の表示状態を定義するプレゼンタであって、該プレゼンタの特定の型のプレゼンタは、対応するグラフィカル要素のレイアウト記述を保持するプレゼンタと、
   ビューに含まれるグラフィカル要素に関連するプレゼンタの組に従って前記ビューのレイアウトを準備するメソッドを有するプレゼンタホストインターフェースを含むプレゼンタシステムと、
   前記グラフィカル要素を保持し、潜在的な複数のビューに関連付けられるバッキングストアと
   を備え、
   前記プレゼンタシステムは、更新が要求され、前記バッキングストアに保持されたグラフィカル要素に関する変更通知を受信すると、前記プレゼンタのオブジェクトのいずれの部分がダーティであるかを判定することを特徴とするグラフィカル出力レイアウト管理システム。
2. 前記プレゼンタシステムは、プレゼンタ基底クラスをさらに含み、前記プレゼンタの組は、前記プレゼンタ基底クラスから派生されるプレゼンタクラスからインスタンス化されることを特徴とする請求項１に記載のグラフィカル出力レイアウト管理システム。
3. 前記プレゼンタは、前記プレゼンタのレイアウトプロパティを計算する更新メソッドを含むことを特徴とする請求項２に記載のグラフィカル出力レイアウト管理システム。
4. 前記プレゼンタは、前記コンピュータシステムのグラフィカル出力サブシステムに発行される命令を生成するレンダメソッドを含むことを特徴とする請求項３に記載のグラフィカル出力レイアウト管理システム。
5. 前記プレゼンタクラスは、事前定義のプレゼンタクラスおよび外部プレゼンタクラスを含むことを特徴とする請求項２に記載のグラフィカル出力レイアウト管理システム。
6. 前記プレゼンタの各々は、前記プレゼンタ上で指定されるレイアウトパラメータ値に基づいて対応するグラフィカル要素のレイアウト状態を計算することを特徴とする請求項１に記載のグラフィカル出力レイアウト管理システム。
7. 通知ハンドラの組であって、各通知ハンドラは、前記ビュー内のプレゼンタの組の特定の１つに関連する通知ハンドラの組をさらに備え、前記通知ハンドラは、グラフィカル要素に対する変更を処理して対応するプレゼンタを更新するか否かを判定することを特徴とする請求項１に記載のグラフィカル出力レイアウト管理システム。
8. 前記プレゼンタの各々は、関連するグラフィカル要素に関する前記特定のプレゼンタに変更通知を提供する通知ハンドラの型を指定することを特徴とする請求項７に記載のグラフィカル出力レイアウト管理システム。
9. 前記プレゼンタシステムは、対応するグラフィカル要素に対する変更に基づき更新を必要とするプレゼンタを前記通知ハンドラを介して登録することを特徴とする請求項７に記載のグラフィカル出力レイアウト管理システム。
10. 前記グラフィカル要素のグラフィカル要素インスタンスは、複数のプレゼンタに関連付けられることを特徴とする請求項１に記載のグラフィカル出力レイアウト管理システム。
11. 前記グラフィカル要素インスタンスが関連付けられる前記複数のプレゼンタは、同一の型を有することを特徴とする請求項１０に記載のグラフィカル出力レイアウト管理システム。
12. 前記複数のプレゼンタは、同一ビュー内の別個の列に対応することを特徴とする請求項１１に記載のグラフィカル出力レイアウト管理システム。
13. 前記複数のプレゼンタは、単一のグラフィカル要素のドキュメントビュー内の別個のページに対応することを特徴とする請求項１１に記載のグラフィカル出力レイアウト管理システム。
14. 前記グラフィカル要素インスタンスが関連付けられる前記複数のプレゼンタの第１プレゼンタおよび第２プレゼンタは、第１および第２の別個のビューにそれぞれ関連付けられることを特徴とする請求項１０に記載のグラフィカル出力レイアウト管理システム。
15. 前記第１および第２の別個のビューは、第１および第２のプレゼンタシステムによってそれぞれホスティングが行われることを特徴とする請求項１４に記載のグラフィカル出力レイアウト管理システム。
16. 前記ビューは、グラフィカルディスプレイスペース内の長方形領域に対応することを特徴とする請求項１に記載のグラフィカル出力レイアウト管理システム。
17. 前記グラフィカル要素インスタンスが関連付けられる前記複数のプレゼンタは、異なる型を有することを特徴とする請求項１０に記載のグラフィカル出力レイアウト管理システム。
18. 前記複数のプレゼンタの１つは、主プレゼンタに対する装飾プレゼンタを含むことを特徴とする請求項１７に記載のグラフィカル出力レイアウト管理システム。
19. ビュー内のプレゼンタは、階層的に配置されて、子プレゼンタが対応する親プレゼンタによって指定される領域内に含まれるようにすることを特徴とする請求項１に記載のグラフィカル出力レイアウト管理システム。
20. グラフィカル要素の表示状態を定義するプレゼンタを介して、プログラムの表示可能なコンテンツを表すデータを含むグラフィカル要素を提供する前記プログラムに代わって、レイアウトを処理するグラフィカル出力レイアウト管理システム内に組み込まれるプレゼンタシステムであって、前記プレゼンタが対応するグラフィカル要素のレイアウト記述を保持し、前記プレゼンタシステムがビュー内のグラフィカル要素に関連付けられる前記プレゼンタのホスティングおよび配置を行い、
    前記プレゼンタをインスタンス化するプレゼンタクラスを派生するプレゼンタ基底クラスと、
    前記ビュー内のグラフィカル要素に関連付けられるプレゼンタの組において実行されるレイアウトを準備するメソッドを、少なくとも１つ含むメソッドの組を含むプレゼンタホストインターフェースと
    を備え、
    更新が要求され、および前記グラフィカル要素を保持し、潜在的な複数のビューに関連付けられるバッキングストアに保持されたグラフィカル要素に関する変更通知を受信すると、前記プレゼンタのオブジェクトのいずれの部分がダーティであるかを判定することを特徴とするプレゼンタシステム。
21. 前記プレゼンタ基底クラスは、プレゼンタのレイアウトプロパティを計算する派生されたプレゼンタクラスによってオーバーライドされるカスタマイズ可能な更新メソッドを指定することを特徴とする請求項２０に記載のプレゼンタシステム。
22. 前記プレゼンタ基底クラスは、前記コンピュータシステムのグラフィカル出力サブシステムに発行される命令を生成する派生されたプレゼンタクラスによってオーバーライドされるカスタマイズ可能なレンダメソッドを指定することを特徴とする請求項２１に記載のプレゼンタシステム。
23. 前記プレゼンタシステムは、事前定義のプレゼンタクラスおよび外部プレゼンタクラスを含むプレゼンタクラスの組をサポートすることを特徴とする請求項２０に記載のプレゼンタシステム。
24. 前記プレゼンタ基底クラスは、関連するプレゼンタ上で指定されるレイアウトパラメータ値に基づいてグラフィカル要素のレイアウト状態を計算するメソッドを指定することを特徴とする請求項２０に記載のプレゼンタシステム。
25. 通知ハンドラクラスを派生する通知ハンドラ基底クラスをさらに備え、各通知ハンドラはビュー内の特定のプレゼンタに関連付けられる通知ハンドラクラスからインスタンス化され、前記通知ハンドラはグラフィカル要素に対する変更を処理して、対応するプレゼンタを更新するか否かを判定することを特徴とする請求項２０に記載のプレゼンタシステム。
26. 前記基底プレゼンタクラスは、関連付けられるグラフィカル要素に関する前記特定のプレゼンタに変更通知を提供する通知ハンドラの型を指定するプレゼンタのプレースホルダを含むことを特徴とする請求項２５に記載のプレゼンタシステム。
27. 前記プレゼンタシステムは、対応するグラフィカル要素に対する変更に基づいて更新の必要なプレゼンタを通知ハンドラを介して登録することを特徴とする請求項２５に記載のプレゼンタシステム。
28. 前記プレゼンタシステムは、ルートグラフィカル要素により特徴付けられるビュー、および前記ルートグラフィカル要素とその子グラフィカル要素とが内部に表示される割り当てられた領域に関連付けられることを特徴とする請求項２０に記載のプレゼンタシステム。
29. 前記ビューは、グラフィカル表示スペース内の長方形領域に対応することを特徴とする請求項２８に記載のプレゼンタシステム。
30. 前記プレゼンタホストインターフェースは、グラフィカル要素の組を含むビューのディスプレイをレイアウトするために前記プレゼンタシステムを初期化するコンストラクタを含むことを特徴とする請求項２０に記載のプレゼンタシステム。
31. 前記ビューは、少なくとも部分的に、前記コンストラクタに渡されるルートグラフィカル要素によって指定されることを特徴とする請求項３０に記載のプレゼンタシステム。
32. 前記プレゼンタシステムは、複数のプレゼンタのチェーニングをサポートして、第１プレゼンタがグラフィカル要素に関連付けられる第２プレゼンタの装飾を提供するようにすることを特徴とする請求項２０に記載のプレゼンタシステム。
33. 前記プレゼンタ基底クラスは、子プレゼンタを指定するプレースホルダであって、ビュー内のプレゼンタの階層ツリー構造の作成をサポートして、子プレゼンタが対応する親プレゼンタによって指定される領域内に含まれるようにするプレースホルダを含むことを特徴とする請求項２０に記載のプレゼンタシステム。
34. グラフィカル要素の表示状態を定義するプレゼンタを介して、プログラムの表示可能なコンテンツを表すデータを含むグラフィカル要素を提供する前記プログラムに代わってレイアウトを処理する方法であって、前記プレゼンタは対応するグラフィカル要素のレイアウト記述を保持し、プレゼンタシステムはビュー内のグラフィカル要素に関連付けられる前記プレゼンタのホスティングおよび配置を行い、
    プレゼンタ基底クラス、およびビュー内のグラフィカル要素に関連付けられるプレゼンタの組で実行されるレイアウトを作成するメソッドを有するプレゼンタホストインターフェースを含む前記プレゼンタシステムを提供するステップと、
    前記プレゼンタホストインターフェースによって、ビュー内のグラフィカル要素の組のレイアウトを生成するために要求を受け取るステップと、
    前記グラフィカル要素の組について、前記プレゼンタ基底クラスから派生されたプレゼンタクラスの組から対応するプレゼンタをインスタンス化し、各インスタンス化されたプレゼンタのメソッドを呼び出して前記プレゼンタに対応するグラフィカル要素のレイアウト状態を計算するステップと、
    更新が要求され、および前記グラフィカル要素を保持し、潜在的な複数のビューに関連付けられるバッキングストアに保持されたグラフィカル要素に関する変更通知を受信すると、前記プレゼンタのオブジェクトのいずれの部分がダーティであるかを判定するステップと
    を備えたことを特徴とする方法。
35. 対応するグラフィカル要素に対する変更に基づいてレイアウトに対する増分的更新を実行する通知ハンドラの組のインターフェースを指定する通知ハンドラ基底クラスを提供するステップ
    をさらに備えたことを特徴とする請求項３４に記載の方法。
36. 階層ツリーの形でビューの前記プレゼンタを編成するステップをさらに含むことを特徴とする請求項３４に記載の方法。
37. 前記プレゼンタシステムのインスタンスは、ビューのレイアウトを作成する呼び出しに応答して作成され、ビューごとに、別個のプレゼンタシステムおよび対応するプレゼンタが作成されることを特徴とする請求項３４に記載の方法。
38. 前記プレゼンタ基底クラスは、特定のグラフィカル要素に関連するプレゼンタインスタンスのレイアウトプロパティを計算する更新メソッドを指定することを特徴とする請求項３４に記載の方法。
39. 前記プレゼンタ基底クラスは、グラフィカル出力サブシステムに発行される命令を生成するレンダメソッドを指定することを特徴とする請求項３４に記載の方法。
40. 前記プレゼンタシステムは、事前定義のプレゼンタクラスおよび外部プレゼンタクラスの派生をサポートすることを特徴とする請求項３４に記載の方法。
41. 前記プレゼンタクラスは、グラフィカル要素コンテンツの異なるタイプをレイアウトする異なる型のプレゼンタに対応することを特徴とする請求項３４に記載の方法。
42. 前記ビュー内のプレゼンタは、階層的に配置されて、子プレゼンタが対応する親プレゼンタによって指定される領域内に含まれるようにすることを特徴とする請求項３４に記載の方法。
43. グラフィカル要素の表示状態を定義するプレゼンタであって、対応するグラフィカル要素のレイアウト記述を保持し、プレゼンタシステムは、ビュー内のグラフィカル要素に関連する前記プレゼンタのホスティングおよび配置を行うプレゼンタを介して、プログラムの表示可能なコンテンツを表すデータを含む前記グラフィカル要素を提供する前記プログラムに代わって、レイアウトの処理を実行するコンピュータ実行可能命令を含むコンピュータ読取可能な媒体であって、前記コンピュータ実行可能命令は、
    プレゼンタ基底クラスと、ビュー内のグラフィカル要素に関連付けられるプレゼンタの組で実行されるレイアウトを作成するメソッドを含むプレゼンタホストインターフェースとを含む前記プレゼンタシステムを提供するステップと、
    前記プレゼンタホストインターフェースによって、ビュー内のグラフィカル要素の組のレイアウトを生成する要求を受け取るステップと、
    前記グラフィカル要素の組について、前記プレゼンタ基底クラスから派生されたプレゼンタクラスの組から対応するプレゼンタをインスタンス化し、各インスタンス化されたプレゼンタのメソッドを呼び出して前記プレゼンタに対応するグラフィカル要素のレイアウト状態を計算するステップと、
    更新が要求され、および前記グラフィカル要素を保持し、潜在的な複数のビューに関連付けられるバッキングストアに保持されたグラフィカル要素に関する変更通知を受信すると、前記プレゼンタのオブジェクトのいずれの部分がダーティであるかを判定するステップと
    を備えた方法の実行を促進することを特徴とするコンピュータ読取可能な媒体。
44. 階層ツリーの形で前記ビューのプレゼンタを編成するコンピュータ実行可能命令をさらに備えたことを特徴とする請求項４３に記載のコンピュータ読取可能な媒体。
45. 前記コンピュータ実行可能命令は、ビューのレイアウトを作成する呼出しに応答して前記プレゼンタシステムのインスタンスを作成し、ビューごとに別個のプレゼンタシステムおよび対応するプレゼンタを作成するステップを実行することを特徴とする請求項４３に記載のコンピュータ読取可能な媒体。
46. 前記プレゼンタ基底クラスは、特定のグラフィカル要素に関連付けられるプレゼンタインスタンスのレイアウトプロパティを計算する更新メソッドを指定することを特徴とする請求項４３に記載のコンピュータ読取可能な媒体。
47. 前記プレゼンタ基底クラスは、グラフィカル出力サブシステムに発行される命令を生成するレンダメソッドを指定することを特徴とする請求項４３に記載のコンピュータ読取可能な媒体。
48. 前記プレゼンタシステムは、事前定義のプレゼンタクラスおよび外部プレゼンタクラスの派生をサポートすることを特徴とする請求項４３に記載のコンピュータ読取可能な媒体。
49. 前記プレゼンタクラスは、異なる種類のグラフィカル要素コンテンツをレイアウトする異なる型のプレゼンタに対応することを特徴とする請求項４３に記載のコンピュータ読取可能な媒体。
50. 前記プレゼンタ基底クラスは、子プレゼンタのプレースホルダを指定して子プレゼンタが対応する親プレゼンタによって指定される領域内に含まれるようにし、ビュー内のプレゼンタの階層的レイアウトを実現することを特徴とする請求項４３に記載のコンピュータ読取可能な媒体。

Images