ユーザインターフェースプロパティをデータにより制御するためのプログラムを格納した記録媒体およびシステム
【課題】ユーザインターフェース（ＵＩ）プロパティをデータとともに制御する命令を格納したコンピュータ可読記録媒体を提供する。
【解決手段】アプリケーションを備えたコンピューティングデバイスは、独立したパーツと、ロジック部分と、ＵＩ部分に分けられる。ロジック部分では、アプリケーション内のデータバリューを操作する。ＵＩ部分は、ＵＩプロパティの表示を受け持つ。バインディング仕様により、ＵＯプロパティとデータバリューとの間の関係を記述する。バインディング仕様は、データバリューに変更が生じたときに通知される方法と、変更をＵＩプロパティに反映するようにＵＯ部分を指令する方法を決定するために、システムレベルコードにより使用される。バインディング仕様は、ソースデータ項目、ソースデータ項目内のデータバリューへのパス、ターゲットＵＩエレメント、およびターゲットＵＩエレメントのＵＯプロパティを識別する。
【解決手段】アプリケーションを備えたコンピューティングデバイスは、独立したパーツと、ロジック部分と、ＵＩ部分に分けられる。ロジック部分では、アプリケーション内のデータバリューを操作する。ＵＩ部分は、ＵＩプロパティの表示を受け持つ。バインディング仕様により、ＵＯプロパティとデータバリューとの間の関係を記述する。バインディング仕様は、データバリューに変更が生じたときに通知される方法と、変更をＵＩプロパティに反映するようにＵＯ部分を指令する方法を決定するために、システムレベルコードにより使用される。バインディング仕様は、ソースデータ項目、ソースデータ項目内のデータバリューへのパス、ターゲットＵＩエレメント、およびターゲットＵＩエレメントのＵＯプロパティを識別する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザインターフェースプロパティをデータにより制御するためのプログラムを格納した記録媒体およびシステムに関する。
【背景技術】
【０００２】
ユーザに情報がどのように提示されるかにより、ユーザが情報をどの程度理解し把握できるかが決まる。コンピュータの表示装置では、色、フォントのスタイルなどを使用することにより、情報に強調(emphasis)を加えるのが標準的慣例となっている。このような強調を加えると、ユーザは情報の重要性を容易に把握することができる。情報（ユーザインターフェース）の表示を処理するコードおよび情報に対しアプリケーションのロジックを実行するコードは、通常、密接に結びついている。例えば、ロジックは、ユーザインターフェースのプロパティ（例えば、色、フォント、位置、サイズ）に直接データを割り当てる。したがって、ユーザインターフェースに変更があれば、ロジックも変わらなければならない。例えば、テキストボックス(text box)の場合、ユーザインターフェースコード(user interface code)はリッスン(listen)してテキストが変更(change)されたかどうかを判定(determine)し、変更(a change)があった場合、ユーザインターフェースコードは変更されたテキスト(changed text)が有効かどうかを確認(validate)し、その後、変更されたテキスト(changed text)を表示(display)する。ユーザインターフェースとロジックがこのように密接に結びついているという性質(nature)のため、コードは非常に脆弱(fragile)なものとなる。この脆弱なコード(fragile code)のメンテナンス(maintaining)は、非常にコストがかかり、時間も要する。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
本発明は、ユーザインターフェースプロパティをデータにより制御するプログラムを格納した記録媒体およびシステムを提供する。
【課題を解決するための手段】
【０００４】
本発明は、データをユーザインターフェースに関連付けるメカニズムを用意することにより、ユーザインターフェースとデータをそのアプリケーションロジック(application logic)とともに分離(decouple)する。本発明により、アプリケーションロジックを書くユーザインターフェース設計者(user interface designers)およびアプリケーション作成者(application authors)は独立に作業することができる。設計者(designers)も作成者(authors)も、互いに相手のコード(other's code)を理解する必要がないか、あるいは相手のコード開発(other's code development)に影響を与える(impact)こともない。本発明では、さらに、ユーザインターフェースへの変更をまったく簡単に行うことができる。例えば、新しい、よりユーザに訴える力のあるユーザインターフェースプラットフォーム(user interface platform)が使用可能になった場合、またはユーザインターフェース設計者がアプリケーションの外観(look of the application)を変更したくなった場合でも、設計者はアプリケーションロジック(application logic)を変更(change)する必要はない。さらに、データをユーザインターフェースに関連付けるメカニズムは、動的(dynamic)である。これにより、データの変更を自動的にプレゼンテーションに反映させることができる。さらに、ユーザインターフェースを介してユーザが行った入力により自動的にデータをアップデートすることができる。本発明を使用すると、ユーザインターフェースのデータ表示態様(data display aspect)（例えば、テキスト）だけでなく視覚的態様(visual aspect)（例えば、背景、フォントサイズなど）の関連付け(association)を行えるので、データの記述的な、視覚的効果の高い、柔軟性の高いプレゼンテーションが可能になる。例えば、株価が上昇しているときに、負数は赤色で表示されるか、または矢印は上方向を指すように表示できる。
【０００５】
したがって、本発明によれば、アプリケーション(an application)は、独立したパーツ(independent parts)と、ロジック部分(a logic portion)と、ＵＩ部分(UI portion)とに分けられる。ロジック部分では、アプリケーション内のデータバリュー(data values)を操作(manipulate)する。ＵＩ部分は、データのプレゼンテーション(presentation of the data)を受け持つ。バインディング仕様(binding specification)により、ＵＩプロパティ(UI property)とデータバリュー(data value)との間の関係を記述(describe)する。バインディング仕様は、データバリューに変更(a change)が生じたときに通知される方法と、その変更をＵＩプロパティに反映(reflect)するようにＵＩ部分を指令する方法を決定するために、システムレベルコード(system level code)により使用される。バインディング仕様は、ソースデータ項目(source data item)、ソースデータ項目内のデータバリューへのパス(a path to the data value)、ターゲットＵＩエレメント(target UI element)、およびターゲットＵＩエレメントのＵＩプロパティ(UI property on the target element)を識別(identify)する。バインディング(binding)は、コードまたはマークアップ言語(markup language)を使用して特定(specify)される。
【図面の簡単な説明】
【０００６】
【図１】本発明の実施例で使用できるコンピューティングデバイスの一例を示す図である。
【図２】本発明にしたがってユーザインターフェースプロパティをデータで制御するための一実施形態を例示した機能ブロック図である。
【図３】本発明の一実施形態によりユーザインターフェースプロパティをデータバリューにとバインドするプロセスを例示した論理流れ図である。
【図４】本発明にしたがってユーザインターフェースプロパティをデータと関連付ける複数の構文例を例示した図である。
【発明を実施するための形態】
【０００７】
本発明は、ユーザインターフェースをデータにより制御するシステムおよび方法を対象とする。本発明は、データをユーザインターフェースに関連付けるメカニズムを用意することにより、ユーザインターフェースとアプリケーションロジックとを分離する。後に詳述するが、関連するロジックとともに、ユーザインターフェースとデータとの間で行われるこのような分離により、さまざまな開発者グループは、他のグループのコード開発に影響を与えることなく、ユーザインターフェースおよびロジックの両方を取り扱うことができる。さらに、後に詳述するが、本発明は、データソースからユーザインターフェースへ、ユーザインターフェースからデータソースへデータを自動的に転送するシステムをおよびメカニズムを実現する。以下の説明全体を通して、「データバインディング(databinding)」という用語は、データバリュー(data value)をＵＩプロパティに関連付け、データバリューを転送(transfer)しアップデート(update)するなどのプロセスを指す。
【０００８】
コンピューティング環境
図１は、本発明を実施する際に使用することが可能なコンピューティングデバイスの一例を示す。図１を参照すると、非常に基本的な構成では、コンピューティングデバイス１００は、少なくとも１つの処理ユニット１０２およびシステムメモリ１０４を備えるのがふつうである。コンピューティングデバイス１００の正確な構成と種類に応じて、システムメモリ１０４は揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）、またはこれら２つの何らかの組み合わせとすることができる。システムメモリ１０４は、通常、オペレーティングシステム１０５、１つまたは複数のプログラムモジュール１０６を格納し、プログラムデータ１０７を含むこともある。プログラムモジュール１０６の例としては、ブラウザアプリケーション、財務管理アプリケーション、ワードプロセッサなどがある。基本構成は、図１において点線１０８内のコンポーネントにより示されている。
【０００９】
コンピューティングデバイス１００は、さらに特徴または機能を追加することもできる。例えば、コンピューティングデバイス１００は、磁気ディスク、光ディスク、またはテープなどの追加データ記憶デバイス（取り外し可能および／または取り外し不可能）を備えることもできる。このような追加ストレージ(additional storage)は、図１では、取り外し可能ストレージ１０９および取り外し不可能ストレージ１１０により例示されている。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造体、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実施される揮発性および不揮発性、取り外し可能および取り外し不可能媒体を含むことができる。システムメモリ１０４、取り外し可能ストレージ１０９、および取り外し不可能ストレージ１１０は、コンピュータ記憶媒体のすべての例である。コンピュータ記憶媒体としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）またはその他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたはその他の磁気記憶デバイス、または目的の情報を格納するために使用されることができコンピューティングデバイス１００によりアクセスされることが可能なその他の媒体がある。このような任意のコンピュータ記憶媒体をデバイス１００の一部とすることができる。さらにコンピューティングデバイス１００は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイスなどの入力デバイス１１２を備えることもできる。表示装置、スピーカー、プリンタなどの出力デバイス１１４を備えることもできる。これらのデバイスは、当業ではよく知られているため、本明細書でさらに詳しい説明をする必要はない。
【００１０】
また、コンピューティングデバイス１００は、デバイスがネットワークなどで他のデバイス１１８と通信するために使用する通信接続(communication connection)１１６も含むことができる。通信接続１１６は、通信媒体の一例である。通信媒体は、通常、搬送波またはその他のトランスポートメカニズムなどの変調データ信号を介して、コンピュータ可読命令、データ構造体、プログラムモジュール、またはその他のデータによって実現されることができ、情報配信媒体を含む。「変調データ信号(modulated data signal)」という用語は、信号内の情報を符号化する方法によりその特性のうち１つまたは複数が設定または変更された信号を意味する。例えば、通信媒体としては、有線ネットワークまたは直接配線接続などの有線媒体、および音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体がある。本明細書で使用されているコンピュータ可読媒体という用語は、記憶媒体と通信媒体の両方を含む。
【００１１】
実施例
図２は、本発明によりユーザインターフェースプロパティをデータにより制御するシステム２００の一実施形態を例示する機能ブロック図である。システム２００は、アプリケーション２０２、プラットフォーム２２０、およびデータソース２３０を含む。アプリケーション２０２は、図１に示されているコンピューティングデバイス１００上の複数のアプリケーション１０６のうちの１つとすることができる。アプリケーション２０２は、データバリュー（例えば、ソースデータバリュー(source data value)２３８）を操作するためのコード（これ以降、ロジック２０４と呼ぶ）を含む。一般に、ロジック２０４はデータバリューに対し検証(validation)を実行し、データバリューをアップデートする。データバリュー（例えば、データバリュー２３８）は、データ項目（例えば、データ項目２３２）のプロパティ（つまり、データソースプロパティ）の内容を表す。データ項目２３２は、データソース（例えば、データソース２３０）内に配置されている。それぞれのデータソース２３０は、複数のデータ項目を含むことができ、それぞれのデータ項目は、１つまたは複数のプロパティを備え、ソースデータバリューがそのプロパティに格納される。ロジック２０３は、複数のデータソースからのデータバリューを操作することができる。データソースは、ＸＭＬドキュメント、オブジェクト、データセットなどを含むことができる。後で詳述するが、データ項目のそれぞれのプロパティは、ユーザインターフェース（ＵＩ）を制御するために使用されることが可能である。
【００１２】
アプリケーション２０２はさらに、情報を表示するためのコード（これ以降ユーザインターフェース２０６と呼ぶ）も含む。ユーザインターフェース２０６は、複数のユーザインターフェースエレメント（例えば、ユーザインターフェースエレメント２０８）を含む。それぞれのユーザインターフェースエレメント２０８は、表示されるテキスト、色、フォント、位置、サイズなどの１つまたは複数のプロパティ（例えば、ＵＩプロパティ２１０および２１２）を含む。次に、後で詳述するが、これらのＵＩプロパティ２１０および２１２は、本発明により、データバリュー２３８および２４２の１つまたは複数に関連付けられる。一般に、関連付けは、プラットフォーム２２０内のバインディングエンジン(binding engine)２２４を介して実行される。プラットフォーム２２０は、オペレーティングシステム、仮想エンジンなどのシステムレイヤのサービスを表す。プラットフォーム２２０は、さらに、データバリュー２３４および２４２に関係する階層情報を保持し、関連付けられているプロパティをデータバリューでアップデートする役割を持つプロパティエンジン２２２を備える。バインディングエンジン２２４およびプロパティエンジン２２２は別々のコンポーネントとして示されているとしても、当業者であれば、それぞれに備えられている機能は、本発明から逸脱することなく、１つのコンポーネント内に収められることを理解するであろう。
【００１３】
データバリュー２３８および２４２とそのＵＩプロパティ２１０および２１２との関連付け（つまり、バインディング）は、図２において、データバリューからＵＩプロパティへの点線で表されている（これ以降バインディング２２６および２２８と呼ぶ）。以下の説明では、「データバリュー」という用語は「ソースデータバリュー」という用語に言い換えられることができる。同様、ＵＩプロパティという用語は、「ターゲットプロパティ」という用語に言い換えられることもできる。これらのバインディング２２６および２２８を使用すると、動的プロパティ（つまり、ターゲットプロパティ）は任意のオブジェクトのプロパティなどのデータバリュー（つまり、ソースデータバリュー）から自動的に設定されるようにできる。これらのバインディングは動的であり、ソースデータバリューの変更を反映するようにバインドされたターゲットプロパティは自動的にアップデートされる。
【００１４】
この自動的にアップデート機能を実現するために、本発明では、さらに、通知メカニズム(notification mechanism)を用意している（例えば、図２において、ノーティファイヤ(notifier)２３６および２４０とノーティファイヤからプラットフォーム２２０までの矢印で表されている）。各データ項目２３２および２３４にはそれぞれ、対応するノーティファイヤ２３６および２４０がある。通知メカニズムは、ソースデータバリューが変更されたこと、およびデータバリューはターゲットプロパティ（つまり、ＵＩプロパティ）に伝搬されることが可能であることをシステムに通知する役割を持つ。
【００１５】
マークアップ、コードなどを通じてバインディング２２６および２２８が作成されると、バインディングエンジン２２４はバインディングに関連付けられているバインディングオブジェクト（例えば、バインディングオブジェクト２５０および２５２）を作成する。例えば、バインディングオブジェクト２５２は、バインディングエンジン２２４内のバインディング２２８を表すことができる。それぞれのバインディングオブジェクトは、複数のプロパティを含む（例えば、バインディングプロパティ２６０〜２７２）。これらのバインディングプロパティ２６０〜２７２は、プログラムによる設定が可能である。以下の説明では、これらのプロパティのそれぞれについて説明し、図４に、それらプロパティのいくつかを特定(specify)するバインディングをアクティブにするコード例を示す。
【００１６】
バインディングプロパティの１つ(one of the binding properties)（これ以降、パス(path)２６０と呼ぶ）は、（ソースオブジェクトを介して）ソースデータバリューを特定する方法を識別する。パス２６０は、ソースオブジェクト上のプロパティ、サブプロパティ、またはインデクサ(indexer)、ＡＤＯ(ActiveX Data Objects)内の列、ＸＭＬ上のＸＰａｔｈなどを参照することができる。それとは別に、パスによりリフレクションまたはＡＤＯパスを参照することもできる。
【００１７】
バインディングプロパティのもう１つ（これ以降、バインドタイプ(bindtype)２６２と呼ぶ）により、バインディング２２６および２２８の型を定義する。一実施形態では、バインドタイプは、単方向(oneWay)の、双方向(twoWay)の、および一度だけ(oneTime)の、ものを含む。図のように、バインディング２２６は、双方向バインディング(twoWay binding)を表し、バインディング２２８は、単方向バインディング(oneWay binding)を表す。これらのバインディングタイプの１つはデフォルトとして設定される。一実施形態では、双方向バインディングが、デフォルトバインディングタイプとして設定されている。
【００１８】
バインドタイプ２６２が単方向(oneWay)として指定されている場合、これは、バインディングエンジン２２４に、関連するソースデータバリューに変更が生じる毎にターゲットプロパティ（例えば、ＵＩプロパティ２１０）をアップデートするよう通知する。ＯｎｅＷａｙバインドタイプは、データバリューを、テキスト色、テキスト背景色などの編集不可能なＵＩプロパティにバインドする場合に使用される。単方向バインドタイプを使用すると、後述するように、双方向バインドタイプのオーバーヘッドを避ける(avoid)ことができる。このようにオーバーヘッドの減少は、レイアウト内容に関するＵＩプロパティの変更をリッスン(listen)している場合に最も顕著である。これらのＵＩプロパティに対して、ＵＩプロパティの子のそれぞれの動的プロパティは、ＵＩプロパティ変更に関してリッスンされなければならない。単方向バインドタイプもまた、ＵＩプロパティの変更が単に他の表示の詳細を示すためだけであれば、有用であると思われる。
【００１９】
バインドタイプ２６２が双方向として指定されている場合、これは、バインディングエンジン２２４に、ソースデータバリューに変更が生じる毎にターゲットプロパティをアップデートし、またその逆を行うよう通知する。双方向バインディングは、ユーザが編集ボックスで行った変更がソースデータバリューに伝搬される必要がある場合にデータを編集ボックスにバインドするときに特に有用である。双方向バインディングの別のシナリオは、他のアプリケーションがソースデータフィールドを受け持ち、変更が編集ボックスの中に反映される場合である。
【００２０】
バインドタイプ２６２が一度だけのものとして指定されている場合、これは、バインディングエンジン２２４に、関連するソースデータバリューが変更された場合でも、ターゲットプロパティを１回アップデートしてからそのまま終了するよう通知する。一度だけのバインドタイプ(oneTime bindtype)は、一部のターゲットプロパティがソースフィールドからの何らかのバリューで初期化される必要があり、データコンテキストがあらかじめ知られていない場合に使用される。さらに、一度だけのバインドタイプは、ソースデータバリューを変更せずに読み取り専用で使用する場合に有用である。データソースが本発明のプロパティ通知メカニズムをサポートしていない場合（例えば、ＩＰｒｏｐｅｒｔｙＣｈａｎｇｅインターフェース）、単方向として指定されているターゲットプロパティは、バインディングがバインドタイプとして一度だけを指定している場合と同様にアップデートされる。
【００２１】
バインディングプロパティのもう１つ（これ以降、アップデートタイプ２６４と呼ぶ）により、バインドタイプ２６２が双方向を指定する場合に対するアップデートの種類を定義する。通常、双方向バインディングは、ターゲットプロパティの変更をリッスンし、その変更をソースデータバリューに伝搬させて返す。このプロセスは、ソースをアップデートすると言われる。通常、ターゲットプロパティが変更されると必ずアップデートすることが望ましい。しかし、状況によっては、キーを押す毎にアップデートするのでは無駄なサイクルが発生し、ユーザには入力エラーなどを訂正するチャンスがない。アップデートタイプ(updatetype)２６４では、ユーザはアップデートを実行する時期を特定することができる。一実施形態では、アップデートタイプ２６４により、Ｉｍｍｅｄｉａｔｅ、ＯｎＬｏｓｔＦｏｃｕｓ、およびＥｘｐｌｉｃｉｔを特定(specify)することができる。Ｉｍｍｅｄｉａｔｅを特定すると、バインディングエンジンは、ターゲットプロパティが変更される毎に、ソースデータバリューをアップデートする。ＯｎＬｏｓｔＦｏｃｕｓを特定すると、バインディングエンジンは、ターゲットエレメントがキーボードのフォーカスを失った後、ソースデータバリューをアップデートする。Ｅｘｐｌｉｃｉｔを特定すると、バインディングエンジンは、アプリケーションがアップデートを明示的に要求した場合のみ、ソースデータバリューをアップデートする。通常、この明示的な要求はメソッドを介して実行される。このメソッドはアップデートタイプ２６４の設定のため呼び出されることが可能であっても、このメソッドは、アップデートタイプがＥｘｐｌｉｃｉｔに設定されている場合に使用される。方法例を１つ以下に示す。
Binding.GetBinding(myElement, myProperty).Update();
【００２２】
バインディングプロパティのもう１つ（これ以降、ソース(source)２６６と呼ぶ）により、バインディングに対するソースデータ項目を識別する。簡単にいうと、図４に示され、それに関して説明されているように、ソース２６６は、プログラムにより、またはマークアップを使用して、設定されることが可能である。プログラムに関しては、開発者は、バインディングでソースデータ項目として使用しなければならないオブジェクトへのｏｂｊｅｃｔｒｅｆを用意する。簡単にいうと、図４に関して詳細に説明していうように、マークアップでは、ソースプロパティを設定するさまざまな方法がある。
【００２３】
バインディングプロパティのもう１つ（これ以降、トランスフォーマ(transformer)２６８と呼ぶ）は、クラス参照(class reference)を受け入れる。クラス参照は、＜Ｎａｍｅｓｐａｃｅ＞．＜Ｃｌａｓｓ＞，＜Ａｓｓｅｍｂｌｙ＞を使用して特定されることが可能である。特定されているクラス参照は、バインディングエンジン２２４により呼び出され、ソースデータバリューをターゲットプロパティによって受け入れられる形式にトランスフォームする。クラス参照内のメソッドはこのトランスフォームを呼び出すが、図２にトランスフォーム２４４として表されている。クラス参照では、さらに、ターゲットプロパティをソースデータバリューにより受け入れられる形式にトランスフォームする逆トランスフォーム(inverse transform)（図に示されていない）も特定することができる。トランスフォーム２４４は、ＵＩの意味を供給するか、またはカスタムタイプのコンバータとすることができる。
【００２４】
バインディングプロパティのもう１つ（これ以降カルチャー２７０と呼ぶ）は、ソースデータバリューをトランスフォームする前／後にソースデータバリューが処理されるべき方法を定義する。カルチャー２７０は、トランスフォーマ２６８とともに動作し、開発者はいソースデータバリューをトランスフォームする規則を特定することができる。例えば、カルチャーでは、数バリュー、日付などに対する特定の形式を特定することができる。一実施形態では、カルチャー２７０は、ＣｕｌｔｕｒｅＩｎｆｏ型のバリューを受け入れる。開発者は、トランスフォームを実行する際にカルチャー２７０により特定された規則を使用するオプションを用意する。
【００２５】
バインディングプロパティのもう１つ（これ以降、バインドフラグ２７２と呼ぶ）は、イベントを受信し、データの転送を通知するイベントを受信するメカニズムを備える。データバインディングの上述の方法は非同期であるが、バインドフラグ２７２では、開発者はいつターゲットが新しいバリューでアップデートされているかを知ることができる。このメカニズムを使用するために、バインドフラグ２７２は「ＮｏｔｉｆｙＯｎＴｒａｎｓｆｅｒ」に設定される。その後、いつもの方法を使用しイベントに関してハンドラを登録する。このようなメカニズムの一使用例を以下に示す。
Public static void main()
{
//ハンドラを追加する
elem.AddAttachedHandler(Binding.DataTranferEvent,
new DataTranferEventHandler(OnDataTransfer),
RoutedEventArgs.EventStage.Direct);
//イベントハンドラ
private static void OnDataTransfer(Element e, DataTransferEventArgs args)
{
DynamicProperty DP=args.DP;
v=e.GetValue(DP);
DoSomething(v);
}
source.field="new value";
}.
【００２６】
上記のコード例に示されているように、ＯｎＤａｔａＴｒａｎｓｆｅｒイベントが発生すると、開発者は動的プロパティがアップデートされていることが通知される。したがって、開発者は、さらに処理を進めるためターゲットバリューを使用することが可能である。
【００２７】
図３は、本発明の一実施形態によるバインディングメカニズムを例示する論理流れ図である。概して、バインディングメカニズムは、バインディングをセットアップするアクションを実行し（ブロック３０２〜３０６）、その後、バインディングで特定されているようにターゲットプロパティまたはソースデータバリューの変更に関係するアクションを実行する（ブロック３１０〜３３８）。処理は、ブロック３０２に続く。
【００２８】
ブロック３０２において、作成時に特定された引数(argument)に基づいてバインディングオブジェクトが作成される。簡単に言うと、バインディングオブジェクト２５２に対する各プロパティ（つまり、図２に示されているプロパティ２６０〜２７２）は、作成時に引数として特定されることが可能である。バインディングは、マークアップを通じて、プログラムで、および類似の方法で作成されることが可能である。図４は、バインディングを作成し、プロパティ２６０〜２７２を特定する構文例を示している。それぞれの作成方法で、ソースデータ項目、ソースデータ項目内のデータバリューへのパス、ターゲットＵＩエレメント、およびおＵＩエレメント上のターゲット動的プロパティを特定する。現在の流れ図には示されていないが、バインディングオブジェクトのプロパティも、アプリケーションプログラミングインターフェース（ＡＰＩ）を使用するなどして、実行時に動的に修正されることが可能である。処理はステップ３０６に進む。
【００２９】
ブロック３０４において、バインディングがアクティブにされる。一実施形態では、バインディングは、バインディングエンジンがソースオブジェクトを存在させる、ターゲットエレメントを表示できる状態にするなど、バインディングに十分なコンテキストがあることを通知した後、自動的にアクティブ化されることが可能である。バインディングエンジンは、バインディングのアクティブ化を認識することを受け持つ。処理は、ブロック３０４に続く。
【００３０】
ブロック３０６において、特定されたソースプロパティのバリューが見つけられる。一実施形態では、バリューを見つけるためにリフレクションが使用される。リフレクションは、要求されたオブジェクトに関する情報を呼び出し側が取得するために使用する一般的なメカニズムである。この情報は、サポートされているオブジェクト、パブリックプロパティなどを含む。他の実施形態では、データ項目がコレクションである場合、バインディングエンジンは、発見的手法を何度も実行して、現在のレコードまたはデータオブジェクト（コレクション）自体を使用しているかどうかを判別する。第１の発見的手法は、バインディングがプロパティまたはインデクサを参照したときに適用される。このような状況では、コレクションオブジェクト上の対応するプロパティまたはインデクサは、そのようなプロパティまたはインデクサが存在する場合に使用される。それとは別に、コレクションの現在のレコードはデータ項目として使用される。プロパティまたはインデクサが存在しない場合、他の発見的手法が適用される。このような状況では、コレクションオブジェクトは、コレクションオブジェクトは有効である限り、ターゲットプロパティに使用される。そうでない場合、現在のレコードが使用される。ブロック３０８に進む前に、バインディングでトランスフォームを特定している場合（ブロック３０７）、トランスフォームがバリューに適用される。トランスフォームの適用については、以下のブロック３１６に関して詳しく説明されている。処理は、ブロック３０８に続く。
【００３１】
ブロック３０８において、見つかったバリューは、ターゲットプロパティに割り当てられる。一実施形態では、プロパティの階層保持する役割を持つプロパティエンジンがバリューを割り当てることができる。他の実施形態では、ターゲットプロパティにバリューを割り当てる前に、バリューをトランスフォームするためにバインディングの作成時に特定されたトランスフォームを呼び出すことが可能である。他の精密化では、プロパティエンジンはプロパティに新しいバリューを持つというマークをつけることができる。ブロック３０２〜３０８が実行された後、バインディングエンジンは、ターゲットプロパティおよびソースデータバリューを必要に応じてアップデートする用意ができている。一般に、バインディングメカニズムは非同期である。
【００３２】
したがって、ブロック３０８から、処理は２つの非同期パスを辿る。第１のパス（ブロック３１０〜３１８）は、ターゲットプロパティをアップデートすることに関連付けられており、第２のパス（ブロック３３０〜３３８）は、ソースデータバリューをアップデートすることに関連付けられている。これらのパスのそれぞれについて以下で説明する。第１に、ターゲットプロパティをアップデートする役割を持つパスについて示される。
【００３３】
決定ブロック(decision block)３１０において、バインディングエンジンは、ソースデータバリューおよびターゲットプロパティに関連付けられているバインディングでバインドタイプを一度だけとして特定しているかどうかを判別する。バインドタイプが一度だけの場合、そのバインドに関して処理は完了しており、終了に進む。当業者であれば、バインドタイプが一度だけの場合、バインディングエンジンはソースプロパティの変更イベントをリッスンしないことを理解するであろう。したがって、実際の運用では、バインディングエンジン内のロジックは必ずしも、ブロック３１０で示されているようにチェックを実行しない。さらに、データ項目がＩＰｒｏｐｅｒｔｙＣｈａｎｇｅを実施しない場合、処理は完了する。しかし、バインドタイプが一度だけでない場合には、処理はブロック３１２に続く。
【００３４】
ブロック３１２において、バインディングエンジンはバインディングに関連付けられている通知をリッスンする。データバインディングでソースデータバリューを使用してターゲットを直接アップデートしないため、本発明では通知メカニズムを実施する。プロパティ変更通知およびコレクションビュー「ＣｕｒｒｅｎｔＣｈａｎｇｅｄ」通知などの通知メカニズムは、当業では知られており、ここではさらに詳しい説明を要しない。異なるアクションにより、データバリュー変更、ページナビゲーション、シャットダウン、データコレクション内の注目するレコードの変更などの通知が実行される。本発明はデータコレクション内の注目するレコードの変更があるとアップデートをトリガするので、本発明は、ユーザインターフェースおよびロジックをさらに分離する便利なメカニズムを備える。例えば、本発明により、開発者は、データコレクション内の注目する次のレコードにどのように変更を加えるかを特定するコードをロジック内に作成するだけでよい。変更が実行されると、バインディングエンジンは、本発明により、すでに特定されているバインディングに基づき、ユーザインターフェースをアップデートする。すでに述べたように、ユーザインターフェースとロジックとのこのような分離により、ユーザインターフェースおよびロジックが相互に関連していたときに比べてアプリケーションはより堅牢になり、また保守も容易になっている。
【００３５】
以下のコードは、通知メカニズムの一実施例である。以下で作成されたコード例はＣ＃で書かれているが、当業者であれは、通知メカニズムを実施するためにさまざまな言語および構文が使用されることが可能であることを理解するであろう。このような実施については、各データ項目で使用できるようにインターフェースが定義される。各データ項目は、動的アップデートを実施するためにこのインターフェースを継承する。
Public interface IPropertyChange
{
event PropertyChangedEventHandler PropertyChanged;
}.
【００３６】
次に、イベントハンドラ(event handler)およびその引数(argument)が定義される。
public delegate void PropertyChangedEventHandler(object sender, PropertyChangedEventArgs e);
public class PropertyChangedEventArgs:EventArgs
{
public virtual string PropertyName { get ;}
}.
【００３７】
クラスPropertyChangedEventArgsは型文字列を持つPropertyNameという名前の読み取り専用プロパティを１つ含む。PropertyNameプロパティは、変更されたプロパティに対する名前を含む。次に、各ソースデータ項目は、そのプロパティの１つが変更された場合に必ず、ＰｒｏｐｅｒｔｙＣｈａｎｇｅｄデリゲートを呼び出すことによりこのインターフェースを実施する。以下は、通知メカニズムの実施形態により、ソースオブジェクト（例えば、データ項目２３２）を実施する例である。
public class myClass : IPropertyChange
{
private string foo = "Hello World";
public string Foo
{
get {return foo;}
set {if(foo ! = value)
{
foo = value;
NotifyPropertyChanged("foo");
}
}
public event PropertyChangedEventHandler Property Changed;
private void NotifyPropertyChanged(string propName)
{
PropertyChanged(this, new
PropertyChangedEventArgs(propName));
}
}.
【００３８】
上記のコード例に示されているように、「ｆｏｏ」プロパティの「ｓｅｔ」メソッドは、新しいバリューが旧いバリューと異なるかどうかを判別する。バリューが異なる場合、ハンドラが呼び出される。PropertyInfoを取得するためリフレクションが実行される。他の精密化では、バインディングエンジンは、リフレクションを通じて取得されたプロパティの型をキャッシュすることができる。したがって、リフレクションは１回実行され、プロパティについて通知が受信される毎に実行されるわけではない。他の精密化では、引数で空文字列が渡され、データ項目のデータバリューのそれぞれに対するすべてのバインディングをアップデートすべきであることを通知することができる。これは、ソースオブジェクトで、どのプロパティが変更され、各バインディングをアップデートしたいかがはっきりしない場合に実行できる。バインディングエンジンが、データソースバリューが変更されたという通知を受信すると、処理は決定ブロック３１４に進む。
【００３９】
決定ブロック３１４において、変更されたソースデータバリューに関連付けられているバインディングでバインディングに対するトランスフォームを特定していたかどうかを判別する。バインディングでトランスフォームを特定していない場合には、処理はブロック３１８に続く。しかし、バインディングでトランスフォームを特定している場合には、処理はブロック３１６に続く。
【００４０】
ブロック３１６において、バインディングで特定されているトランスフォームが実行される。一実施形態では、トランスフォーマ２６８は後述のようなオブジェクトである。
Public interface IDataTransformer
{
Public object Transform(object o, DynamicProperty dp, CultureInfo c) {;}
}.
【００４１】
上記のインターフェースでは、ｏはソースバリューを表し、ｄｐはターゲットの動的プロパティを表し、ｃはトランスフォーム時(transfomation)に使用するカルチャー(culture)を表す。Ｔｒａｎｓｆｏｒｍ（）メソッドは、ソースバリューｏを型ｄｐの動的プロパティに割り当てるのに適しているオブジェクトにトランスフォームする。Ｔｒａｎｓｆｏｒｍ（）メソッドは、バインディングのソースからターゲットプロパティにデータバリューを伝搬させるとき呼び出される。Ｔｒａｎｓｆｏｒｍ（）メソッドがｎｕｌｌバリューを返した場合、バインディングエンジンに対し、バリューの伝搬を停止することが通知される。
【００４２】
トランスフォーマは、さらに、バインディングで特定された関連ソースデータバリューに基づいて幅、高さ、フォント、位置（ｘ、ｙ）などの他のＵＩプロパティを制御するために使用されることも可能である。トランスフォーマでは、複数の方法でデータを表示するためデータバリューに対しロジックを実行することができる。他の精密化では、カルチャーは、バインディングで特定されているようにトランスフォーム時に適用されることも可能である。処理は、ブロック３１８に続く。
【００４３】
ブロック３１８において、ターゲットプロパティがアップデートされる。一実施形態では、プロパティエンジンはバリューをターゲットプロパティに割り当てる。さらに、ターゲットプロパティは新しいバリューを持つとマーク付けされることも可能である。その後処理はブロック３１２に続き、バインディングに関連付けられている次のプロパティ変更通知をリッスンする。アプリケーションが終了するか、またはバインディングが他の何らかの手段により打ち切られると、処理は終わりに進む。
【００４４】
上述のように、処理は、ブロック３０８から第２のパスへと続くことが可能である。したがって、ブロック３０８から、処理は決定ブロック３３０に続く。上述のように、決定ブロック３１０に関して、バインディングエンジン内のロジックは決定ブロック３１０でバインドタイプのチェックを必ずしも実行することはできないが、むしろ、バインディングエンジンはバインディングが作成されたときに通知をリッスンするように指示されていたため、プロセスは第２のパス内を流れない。しかし、流れの説明を明確にするために、バインドタイプを反映する決定ブロックが示されている。したがって、決定ブロック３３０において、バインディングが双方向(twoWay)のバインドタイプとして特定したかどうかの判別が行われる。すでに述べたように、双方向では、ターゲットプロパティの変更をソースデータバリューに伝搬させることができる。バインディングで双方向バインドタイプとして特定していない場合、処理は終わりに進む。しかし、バインディングで双方向バインドタイプとして特定している場合には、処理はブロック３３２に続く。
【００４５】
ブロック３３２において、バインディングエンジンは、ソースデータバリューのアップデートをトリガするいくつかのアクションを認識する。トリガが発生すると、処理は決定ブロック３３４に続く。
【００４６】
決定ブロック３３４において、バインディングがバインドに対し逆トランスフォームを特定したかどうかの判別が行われる。バインディングで逆トランスフォームを特定していない場合には、処理はブロック３３８に続く。しかし、バインディングで逆トランスフォームを特定している場合には、処理はブロック３３６に続く。
【００４７】
ブロック３３６において、逆トランスフォームがソースプロパティに適用される。一実施形態では、逆トランスフォーマは後述のようなオブジェクトである。
Public interface IDataTransformer
{
Public object InverseTransform(object o, PropertyInfo pinfo, CultureInfo c){;}
}.
【００４８】
上記のインターフェースでは、ｏはソースバリューを表し、ｃはトランスフォーム時に使用するカルチャーを表し、ｐｉｎｆｏはターゲットプロパティのＰｒｏｐｅｒｔｙＩｎｆｏを表す。ＩｎｖｅｒｓｅＴｒａｎｓｆｏｒｍ（）メソッドは、ソースバリューｏを型ｉｎｆｏのプロパティに割り当てるのに適しているオブジェクトにトランスフォームする。このメソッドは、バインディングのターゲットからソースにバリューを伝搬させるとき呼び出される。ＩｎｖｅｒｓｅＴｒａｎｓｆｏｒｍ（）メソッドがｎｕｌｌバリューを返した場合、バインディングエンジンはバリューを伝搬しない。ＩｎｖｅｒｓｅＴｒａｎｓｆｏｒｍが実行されると、処理は決定ブロック３３８に続く。
【００４９】
ブロック３３８において、アップデートタイプに応じてソースプロパティがアップデートされる。上述のように、アップデートタイプは、即時、フォーカスの喪失、明示的、およびその他をきっかけとしてよい。ソースプロパティがアップデートされた後、処理は終了へ進む。
【００５０】
図４は、バインディングを作成するいくつかの例を示している。作成手段(creation means)４００〜４１０では、マークアップを通じてバインディングを作成する。作成手段４１０では、コードを通じてバインディングを作成する。図４に示されている手段例は網羅的ではない。他の手段（構文）は、本発明の範囲から逸脱することなく、使用されることが可能である。
【００５１】
作成手段４００は、エレメント４２４に対しＤａｔａＣｏｎｔｅｘｔ名／バリューのペア（これ以降、ＤａｔａＣｏｎｔｅｘｔ ４２２と呼ぶ）およびＩｄ名／バリューのペア（これ以降、Ｉｄ ４２０と呼ぶ）を含む。作成手段４００はさらに、ＤａｔａＣｏｎｔｅｘｔ ４２２も含むため、Ｉｄ ４２０は不要である。Ｉｄ ４２０は、マークアップでＥｌｅｍｅｎｔＳｏｕｒｃｅを使用したり、コード内でＩｄＯｂｊｅｃｔＲｅｇを使用したりするなど、明示的なソースを参照するのが望ましい場合に必要である。これらの両方の用途について後で説明される。ＤａｔａＣｏｎｔｅｘｔ ４２２は、エレメント（例えば、エレメント４２４）で定義されている動的プロパティである。ＤａｔａＣｏｎｔｅｘｔ ４２２に関連付けられているバリューは、デフォルトのソースデータ項目を表し、継承可能なプロパティである。バインディングエンジンは、ＤａｔａＣｏｎｔｅｘｔ ４２２にクエリを実行し、エレメント４２４および子孫エレメント（例えば、Ｂｕｔｔｏｎエレメント４２６）のバインディングを作成するときにＤａｔａＣｏｎｔｅｘｔ ４２２を使用する。バインディングエンジンは、さらに、ＤａｔａＣｏｎｔｅｘｔ ４２２の変更についてもリッスンするし、そのトリガによりアップデートを実行する。したがって、必要はないけれども、ＤａｔａＣｏｎｔｅｘｔ ４２２は共通データ項目にバインドされるすべてのプロパティについてスコープを確立する便利なメカニズムを備える。子孫エレメントは、自ＤａｔａＣｏｎｔｅｘｔを持つことができ、これは親エレメントのＤａｔａＣｏｎｔｅｘｔ ４２２に優先する。バインディングは、作成手段４０２に関して後述するｎｕｌｌでないソースを供給することにより、ＤａｔａＣｏｎｔｅｘｔ ４２２をオーバーライドすることができる。
【００５２】
Ｂｕｔｔｏｎエレメント４２６は、ターゲットプロパティで例示されている（例えば、 Ｂｕｔｔｏｎ．Ｔｅｘｔ ４２８）。本発明では、バインディングエンジンは、「Ｄａｔａ：Ｂｉｎｄ」を見つけると、バインディングが特定されていることを認識する。後の名前／バリューのペアは、図２で特定されているように、バインディングプロパティ２６０〜２７２を設定する。当業者であれば、バインディングを示す「Ｄａｔａ：Ｂｉｎｄ」という用語は任意の用語であり、本発明を逸脱することなく用語はいくつ使用されていてもかまわない。作成手段４００は、詳細マークアップ形式を表す。
【００５３】
作成手段４０２は、コンパクトマークアップ形式を表す。ＵＩプロパティ（例えば、Ｂｕｔｔｏｎ Ｔｅｘｔ）は、さらにコンパクトな方式で表される。ここでもまた、「Ｄａｔａ：Ｂｉｎｄ」は、バインディングエンジンに対し後に続くのがバインディングであることを知らせるシグナルとして使用される。さらに、名前／バリューのペアと後に続く「Ｄａｔａ：Ｂｉｎｄ」は、図２でバインディングオブジェクト２５０についてすでに説明している所望のプロパティ２６０〜２７２に対応する。例えば、ＥｌｅｍｅｎｔＳｏｕｒｃｅ名／バリューのペア（これ以降ＥｌｅｍｅｎｔＳｏｕｒｃｅ ４３４と呼ぶ）はソース２６６に対応している。
【００５４】
マークアップでは、ソースプロパティを設定する方法は、ＥｌｅｍｅｎｔＳｏｕｒｃｅおよびＤａｔａＳｏｕｒｃｅの２つがある。これらのいずれも使用されない場合、ソースのデフォルトバリューはｎｕｌｌであり、作成後、エレメントのＤａｔａＣｏｎｔｅｘｔプロパティのバリューを取得し、そのバリューをソースオブジェクトとして使用するようバインディングエンジンに通知する。
【００５５】
作成手段（例えば、作成手段４０２）でＥｌｅｍｅｎｔＳｏｕｒｃｅを特定した場合、バインディングエンジンは、ＥｌｅｍｅｎｔＳｏｕｒｃｅプロパティにより特定されているＩＤを持つエレメントを見つける。その後、エレメントのＤａｔａＣｏｎｔｅｘｔｉｓは、ソースオブジェクトとして使用される。／Ｐａｒｅｎｔ／Ｐａｒｅｎｔおよび／Ｐｒｅｖｉｏｕｓ／Ｐｒｅｖｉｏｕｓなどの相対パス名は、データソースを特定するために使用されることが可能である。バインディングエンジンは、／Ｐａｒｅｎｔを見つけると、オブジェクト階層に関して現在のエレメントの親であるエレメントを探す。例えば、エレメントが顧客注文である場合、／Ｐａｒｅｎｔを特定すると、現在の注文に対する顧客に対応するエレメントを探すようにバインディングエンジンに通知することができる。／Ｐａｒｅｎｔを特定するのは、内側リピータのスコープ内にある外側リピータからのバリューを使用するのが望ましいネストされているリピータの場合に役立つ。／Ｐｒｅｖｉｏｕｓを特定すると、バインディングエンジンはＲｅｐｅａｔｅｒの下にある現在のエレメントの前のエレメントを探す。／Ｐｒｅｖｉｏｕｓを特定するのは、棒グラフなど、現在の項目の他に現在のｎ項目にアクセスするのが望ましい場合に便利である。連続する／Ｐｒｅｖｉｏｕｓと／Ｐａｒｅｎｔは、本発明に従って使用されることが可能である。
【００５６】
他の実施形態では、マークアップでＤａｔａＳｏｕｒｃｅを特定することができる。ＤａｔａＳｏｕｒｃｅが特定された場合、バインディングエンジンはＲｅｓｏｕｒｃｅのリソースＩＤを受け入れる。Ｒｅｓｏｕｒｃｅがデータプロパティを公開する場合、バインディングエンジンは、バインディングのソースを、ＤａｔａＳｏｕｒｃｅリソースのデータプロパティによって返されるオブジェクトに設定する。そうでない場合、バインディングエンジンはバインディングのソースをリソースオブジェクト自体に設定する。
【００５７】
当業者であれば、マークアップ言語を使用してプロパティ２６０〜２７２が表現され、したがって、これは他のプロパティのそれぞれがマークアップ言語を使用して表現されることが可能であることを理解するであろうし、ここで詳細には説明しない。
【００５８】
次の３つの作成手段４０４〜４１０は、本発明でバインドすることができる項目の種類に関して例を与える。作成手段４０４は、サブプロパティおよびインデクサへのバインディングのサポートを示している。作成手段４０４は、ｄｉ．ａ．ｂ［３］．ｃのようにＣ＃で書かれているバインディングに対応しており、ｄｉは関連するデータ項目である。データ項目、ｄｉ．ａを実施するクラス、ｄｉ．ａ．ｂを実施するクラス、およびｄｉ．ａ．ｂ［３］．ｃを実施するクラスが本発明の通知メカニズム（例えば、ＩＰｒｏｐｅｒｔｙＣｈａｎｇｅ）をサポートし、プロパティが変更されたときに通知する限り、作成手段４０４を使用して特定されたバインディングにより、バインディングエンジンは自動的にバインドされているプロパティ（例えば、ターゲットプロパティ）をアップデートし、ソースデータバリューの変更を反映する。
【００５９】
作成手段４０６は、データコレクションへのバインディングのサポートを示している。バインディングエンジンは、自動的に、各レベルでコレクションの現在のレコードを使用する（ａ、ｂ、およびｃは異なるレベルを表す）。例えば、ｄｉ．ａがＩＤａｔａＣｏｌｌｅｃｔｉｏｎ型であれば、バインディングでは、「ｂ」プロパティをフェッチするためにコレクションの現在のレコードを使用する。したがって、バインディングエンジンは、現在のレコードが変更された場合に必ず、データコレクションに関連付けられているバリューを自動的にアップデートする。
【００６０】
作成手段４０８は、ＸＭＬノードへのバインディングのサポートを示している。バリューへのパス２６０は、図４に示されているように、「／Ｃｕｓｔｏｍｅｒ／Ｏｒｄｅｒ［＠ＯｒｄｅｒＩＤ＝１０］／Ａｍｏｕｎｔ）」などのｘｐａｔｈ表現を使用して与えられる。作成手段４１０は、ＡＤＯデータテーブルへのバインディングのサポートを示している。この実施に関しては、バリューへのパス２６０は、図４に示されているように、「ＯｒｄｅｒｌＤ」などの特定の行に対するフィールド名として与えられる。
【００６１】
作成手段４１０では、プログラムによりバインディングを作成する。開発者は、バインディングでソースデータ項目として使用しなければならないオブジェクトへのｏｂｊｅｃｔｒｅｆを用意する。作成手段４１２に示されているプログラムのステートメントは、作成手段４１０により例示されているのと同じ動作でバインディングを作成する。ＳｅｔＢｉｎｄｉｎｇメソッドは、プログラマが上述のバインディングプロパティを特定する際に使用できるより精巧な変更形態を多数備える。上の単純な例では、ボタンのＤａｔａＣｏｎｔｅｘｔをソースオブジェクトとして使用する。以下のプログラムのステートメントは、特定のオブジェクト（実行時に知られる）をソースとして使用する単方向バインディングを作成する。
Object source = ... 何らかの任意のオブジェクト ...;
Binding.SetBinding(myButton, Element.BackgroundProperty, "Color", BindType.OneWay, new ExplicitObjectRef(source));
【００６２】
以下のコード例は、本発明のバインディングメカニズムを介してデータによりユーザインターフェースプロパティを制御するための一実施を示している。この例では、データバリュー（例えば、ｍｙＩｎｔｅｇｅｒ）およびＵＩプロパティ（例えば、ＴｅｘｔＣｏｎｔｅｎｔ）は、バインディングとしてアクティブ化にされる。さらに、トランスフォーム（例えば、ＭｙＴｒａｎｆｏｒｍｅｒ）は、このバインディングに対して特定される。
<Test TextContent="*Data:Bind(Path=myInteger)"
Foreground="*Data:Bind(Path=MyInteger;
Transformer=MyTransformer)"/>
public class MyTransformer:IDataTransformer
{
public object Transform(object o, DynamicProperty dp, CultureInfo culture)
{
if ((int)o <0) return Red;
else return Black;
}
public object InverseTransform(object o, PropertyInfo info, CultureInfo culture)
{
return null;
}
}.
【００６３】
したがって、説明したように、本発明は、ユーザインターフェースおよびロジックのコーディングの変更が分離されるようにソースデータバリューをターゲットプロパティに関連付けるメカニズムを備える。したがって、本発明により、開発者はアプリケーションの基本ロジックを修正することなく、ユーザインターフェースを容易に修正し、機能強化することができる。
【００６４】
上記の明細、実施例、およびデータにより、本発明の構成の製造および使用に関する説明が完全になされている。本発明の多くの実施形態は、本発明の精神と範囲を逸脱することなく実施できるため、本発明は付属の請求項によって定められる。
【技術分野】
【０００１】
本発明は、ユーザインターフェースプロパティをデータにより制御するためのプログラムを格納した記録媒体およびシステムに関する。
【背景技術】
【０００２】
ユーザに情報がどのように提示されるかにより、ユーザが情報をどの程度理解し把握できるかが決まる。コンピュータの表示装置では、色、フォントのスタイルなどを使用することにより、情報に強調(emphasis)を加えるのが標準的慣例となっている。このような強調を加えると、ユーザは情報の重要性を容易に把握することができる。情報（ユーザインターフェース）の表示を処理するコードおよび情報に対しアプリケーションのロジックを実行するコードは、通常、密接に結びついている。例えば、ロジックは、ユーザインターフェースのプロパティ（例えば、色、フォント、位置、サイズ）に直接データを割り当てる。したがって、ユーザインターフェースに変更があれば、ロジックも変わらなければならない。例えば、テキストボックス(text box)の場合、ユーザインターフェースコード(user interface code)はリッスン(listen)してテキストが変更(change)されたかどうかを判定(determine)し、変更(a change)があった場合、ユーザインターフェースコードは変更されたテキスト(changed text)が有効かどうかを確認(validate)し、その後、変更されたテキスト(changed text)を表示(display)する。ユーザインターフェースとロジックがこのように密接に結びついているという性質(nature)のため、コードは非常に脆弱(fragile)なものとなる。この脆弱なコード(fragile code)のメンテナンス(maintaining)は、非常にコストがかかり、時間も要する。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
本発明は、ユーザインターフェースプロパティをデータにより制御するプログラムを格納した記録媒体およびシステムを提供する。
【課題を解決するための手段】
【０００４】
本発明は、データをユーザインターフェースに関連付けるメカニズムを用意することにより、ユーザインターフェースとデータをそのアプリケーションロジック(application logic)とともに分離(decouple)する。本発明により、アプリケーションロジックを書くユーザインターフェース設計者(user interface designers)およびアプリケーション作成者(application authors)は独立に作業することができる。設計者(designers)も作成者(authors)も、互いに相手のコード(other's code)を理解する必要がないか、あるいは相手のコード開発(other's code development)に影響を与える(impact)こともない。本発明では、さらに、ユーザインターフェースへの変更をまったく簡単に行うことができる。例えば、新しい、よりユーザに訴える力のあるユーザインターフェースプラットフォーム(user interface platform)が使用可能になった場合、またはユーザインターフェース設計者がアプリケーションの外観(look of the application)を変更したくなった場合でも、設計者はアプリケーションロジック(application logic)を変更(change)する必要はない。さらに、データをユーザインターフェースに関連付けるメカニズムは、動的(dynamic)である。これにより、データの変更を自動的にプレゼンテーションに反映させることができる。さらに、ユーザインターフェースを介してユーザが行った入力により自動的にデータをアップデートすることができる。本発明を使用すると、ユーザインターフェースのデータ表示態様(data display aspect)（例えば、テキスト）だけでなく視覚的態様(visual aspect)（例えば、背景、フォントサイズなど）の関連付け(association)を行えるので、データの記述的な、視覚的効果の高い、柔軟性の高いプレゼンテーションが可能になる。例えば、株価が上昇しているときに、負数は赤色で表示されるか、または矢印は上方向を指すように表示できる。
【０００５】
したがって、本発明によれば、アプリケーション(an application)は、独立したパーツ(independent parts)と、ロジック部分(a logic portion)と、ＵＩ部分(UI portion)とに分けられる。ロジック部分では、アプリケーション内のデータバリュー(data values)を操作(manipulate)する。ＵＩ部分は、データのプレゼンテーション(presentation of the data)を受け持つ。バインディング仕様(binding specification)により、ＵＩプロパティ(UI property)とデータバリュー(data value)との間の関係を記述(describe)する。バインディング仕様は、データバリューに変更(a change)が生じたときに通知される方法と、その変更をＵＩプロパティに反映(reflect)するようにＵＩ部分を指令する方法を決定するために、システムレベルコード(system level code)により使用される。バインディング仕様は、ソースデータ項目(source data item)、ソースデータ項目内のデータバリューへのパス(a path to the data value)、ターゲットＵＩエレメント(target UI element)、およびターゲットＵＩエレメントのＵＩプロパティ(UI property on the target element)を識別(identify)する。バインディング(binding)は、コードまたはマークアップ言語(markup language)を使用して特定(specify)される。
【図面の簡単な説明】
【０００６】
【図１】本発明の実施例で使用できるコンピューティングデバイスの一例を示す図である。
【図２】本発明にしたがってユーザインターフェースプロパティをデータで制御するための一実施形態を例示した機能ブロック図である。
【図３】本発明の一実施形態によりユーザインターフェースプロパティをデータバリューにとバインドするプロセスを例示した論理流れ図である。
【図４】本発明にしたがってユーザインターフェースプロパティをデータと関連付ける複数の構文例を例示した図である。
【発明を実施するための形態】
【０００７】
本発明は、ユーザインターフェースをデータにより制御するシステムおよび方法を対象とする。本発明は、データをユーザインターフェースに関連付けるメカニズムを用意することにより、ユーザインターフェースとアプリケーションロジックとを分離する。後に詳述するが、関連するロジックとともに、ユーザインターフェースとデータとの間で行われるこのような分離により、さまざまな開発者グループは、他のグループのコード開発に影響を与えることなく、ユーザインターフェースおよびロジックの両方を取り扱うことができる。さらに、後に詳述するが、本発明は、データソースからユーザインターフェースへ、ユーザインターフェースからデータソースへデータを自動的に転送するシステムをおよびメカニズムを実現する。以下の説明全体を通して、「データバインディング(databinding)」という用語は、データバリュー(data value)をＵＩプロパティに関連付け、データバリューを転送(transfer)しアップデート(update)するなどのプロセスを指す。
【０００８】
コンピューティング環境
図１は、本発明を実施する際に使用することが可能なコンピューティングデバイスの一例を示す。図１を参照すると、非常に基本的な構成では、コンピューティングデバイス１００は、少なくとも１つの処理ユニット１０２およびシステムメモリ１０４を備えるのがふつうである。コンピューティングデバイス１００の正確な構成と種類に応じて、システムメモリ１０４は揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）、またはこれら２つの何らかの組み合わせとすることができる。システムメモリ１０４は、通常、オペレーティングシステム１０５、１つまたは複数のプログラムモジュール１０６を格納し、プログラムデータ１０７を含むこともある。プログラムモジュール１０６の例としては、ブラウザアプリケーション、財務管理アプリケーション、ワードプロセッサなどがある。基本構成は、図１において点線１０８内のコンポーネントにより示されている。
【０００９】
コンピューティングデバイス１００は、さらに特徴または機能を追加することもできる。例えば、コンピューティングデバイス１００は、磁気ディスク、光ディスク、またはテープなどの追加データ記憶デバイス（取り外し可能および／または取り外し不可能）を備えることもできる。このような追加ストレージ(additional storage)は、図１では、取り外し可能ストレージ１０９および取り外し不可能ストレージ１１０により例示されている。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造体、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実施される揮発性および不揮発性、取り外し可能および取り外し不可能媒体を含むことができる。システムメモリ１０４、取り外し可能ストレージ１０９、および取り外し不可能ストレージ１１０は、コンピュータ記憶媒体のすべての例である。コンピュータ記憶媒体としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）またはその他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたはその他の磁気記憶デバイス、または目的の情報を格納するために使用されることができコンピューティングデバイス１００によりアクセスされることが可能なその他の媒体がある。このような任意のコンピュータ記憶媒体をデバイス１００の一部とすることができる。さらにコンピューティングデバイス１００は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイスなどの入力デバイス１１２を備えることもできる。表示装置、スピーカー、プリンタなどの出力デバイス１１４を備えることもできる。これらのデバイスは、当業ではよく知られているため、本明細書でさらに詳しい説明をする必要はない。
【００１０】
また、コンピューティングデバイス１００は、デバイスがネットワークなどで他のデバイス１１８と通信するために使用する通信接続(communication connection)１１６も含むことができる。通信接続１１６は、通信媒体の一例である。通信媒体は、通常、搬送波またはその他のトランスポートメカニズムなどの変調データ信号を介して、コンピュータ可読命令、データ構造体、プログラムモジュール、またはその他のデータによって実現されることができ、情報配信媒体を含む。「変調データ信号(modulated data signal)」という用語は、信号内の情報を符号化する方法によりその特性のうち１つまたは複数が設定または変更された信号を意味する。例えば、通信媒体としては、有線ネットワークまたは直接配線接続などの有線媒体、および音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体がある。本明細書で使用されているコンピュータ可読媒体という用語は、記憶媒体と通信媒体の両方を含む。
【００１１】
実施例
図２は、本発明によりユーザインターフェースプロパティをデータにより制御するシステム２００の一実施形態を例示する機能ブロック図である。システム２００は、アプリケーション２０２、プラットフォーム２２０、およびデータソース２３０を含む。アプリケーション２０２は、図１に示されているコンピューティングデバイス１００上の複数のアプリケーション１０６のうちの１つとすることができる。アプリケーション２０２は、データバリュー（例えば、ソースデータバリュー(source data value)２３８）を操作するためのコード（これ以降、ロジック２０４と呼ぶ）を含む。一般に、ロジック２０４はデータバリューに対し検証(validation)を実行し、データバリューをアップデートする。データバリュー（例えば、データバリュー２３８）は、データ項目（例えば、データ項目２３２）のプロパティ（つまり、データソースプロパティ）の内容を表す。データ項目２３２は、データソース（例えば、データソース２３０）内に配置されている。それぞれのデータソース２３０は、複数のデータ項目を含むことができ、それぞれのデータ項目は、１つまたは複数のプロパティを備え、ソースデータバリューがそのプロパティに格納される。ロジック２０３は、複数のデータソースからのデータバリューを操作することができる。データソースは、ＸＭＬドキュメント、オブジェクト、データセットなどを含むことができる。後で詳述するが、データ項目のそれぞれのプロパティは、ユーザインターフェース（ＵＩ）を制御するために使用されることが可能である。
【００１２】
アプリケーション２０２はさらに、情報を表示するためのコード（これ以降ユーザインターフェース２０６と呼ぶ）も含む。ユーザインターフェース２０６は、複数のユーザインターフェースエレメント（例えば、ユーザインターフェースエレメント２０８）を含む。それぞれのユーザインターフェースエレメント２０８は、表示されるテキスト、色、フォント、位置、サイズなどの１つまたは複数のプロパティ（例えば、ＵＩプロパティ２１０および２１２）を含む。次に、後で詳述するが、これらのＵＩプロパティ２１０および２１２は、本発明により、データバリュー２３８および２４２の１つまたは複数に関連付けられる。一般に、関連付けは、プラットフォーム２２０内のバインディングエンジン(binding engine)２２４を介して実行される。プラットフォーム２２０は、オペレーティングシステム、仮想エンジンなどのシステムレイヤのサービスを表す。プラットフォーム２２０は、さらに、データバリュー２３４および２４２に関係する階層情報を保持し、関連付けられているプロパティをデータバリューでアップデートする役割を持つプロパティエンジン２２２を備える。バインディングエンジン２２４およびプロパティエンジン２２２は別々のコンポーネントとして示されているとしても、当業者であれば、それぞれに備えられている機能は、本発明から逸脱することなく、１つのコンポーネント内に収められることを理解するであろう。
【００１３】
データバリュー２３８および２４２とそのＵＩプロパティ２１０および２１２との関連付け（つまり、バインディング）は、図２において、データバリューからＵＩプロパティへの点線で表されている（これ以降バインディング２２６および２２８と呼ぶ）。以下の説明では、「データバリュー」という用語は「ソースデータバリュー」という用語に言い換えられることができる。同様、ＵＩプロパティという用語は、「ターゲットプロパティ」という用語に言い換えられることもできる。これらのバインディング２２６および２２８を使用すると、動的プロパティ（つまり、ターゲットプロパティ）は任意のオブジェクトのプロパティなどのデータバリュー（つまり、ソースデータバリュー）から自動的に設定されるようにできる。これらのバインディングは動的であり、ソースデータバリューの変更を反映するようにバインドされたターゲットプロパティは自動的にアップデートされる。
【００１４】
この自動的にアップデート機能を実現するために、本発明では、さらに、通知メカニズム(notification mechanism)を用意している（例えば、図２において、ノーティファイヤ(notifier)２３６および２４０とノーティファイヤからプラットフォーム２２０までの矢印で表されている）。各データ項目２３２および２３４にはそれぞれ、対応するノーティファイヤ２３６および２４０がある。通知メカニズムは、ソースデータバリューが変更されたこと、およびデータバリューはターゲットプロパティ（つまり、ＵＩプロパティ）に伝搬されることが可能であることをシステムに通知する役割を持つ。
【００１５】
マークアップ、コードなどを通じてバインディング２２６および２２８が作成されると、バインディングエンジン２２４はバインディングに関連付けられているバインディングオブジェクト（例えば、バインディングオブジェクト２５０および２５２）を作成する。例えば、バインディングオブジェクト２５２は、バインディングエンジン２２４内のバインディング２２８を表すことができる。それぞれのバインディングオブジェクトは、複数のプロパティを含む（例えば、バインディングプロパティ２６０〜２７２）。これらのバインディングプロパティ２６０〜２７２は、プログラムによる設定が可能である。以下の説明では、これらのプロパティのそれぞれについて説明し、図４に、それらプロパティのいくつかを特定(specify)するバインディングをアクティブにするコード例を示す。
【００１６】
バインディングプロパティの１つ(one of the binding properties)（これ以降、パス(path)２６０と呼ぶ）は、（ソースオブジェクトを介して）ソースデータバリューを特定する方法を識別する。パス２６０は、ソースオブジェクト上のプロパティ、サブプロパティ、またはインデクサ(indexer)、ＡＤＯ(ActiveX Data Objects)内の列、ＸＭＬ上のＸＰａｔｈなどを参照することができる。それとは別に、パスによりリフレクションまたはＡＤＯパスを参照することもできる。
【００１７】
バインディングプロパティのもう１つ（これ以降、バインドタイプ(bindtype)２６２と呼ぶ）により、バインディング２２６および２２８の型を定義する。一実施形態では、バインドタイプは、単方向(oneWay)の、双方向(twoWay)の、および一度だけ(oneTime)の、ものを含む。図のように、バインディング２２６は、双方向バインディング(twoWay binding)を表し、バインディング２２８は、単方向バインディング(oneWay binding)を表す。これらのバインディングタイプの１つはデフォルトとして設定される。一実施形態では、双方向バインディングが、デフォルトバインディングタイプとして設定されている。
【００１８】
バインドタイプ２６２が単方向(oneWay)として指定されている場合、これは、バインディングエンジン２２４に、関連するソースデータバリューに変更が生じる毎にターゲットプロパティ（例えば、ＵＩプロパティ２１０）をアップデートするよう通知する。ＯｎｅＷａｙバインドタイプは、データバリューを、テキスト色、テキスト背景色などの編集不可能なＵＩプロパティにバインドする場合に使用される。単方向バインドタイプを使用すると、後述するように、双方向バインドタイプのオーバーヘッドを避ける(avoid)ことができる。このようにオーバーヘッドの減少は、レイアウト内容に関するＵＩプロパティの変更をリッスン(listen)している場合に最も顕著である。これらのＵＩプロパティに対して、ＵＩプロパティの子のそれぞれの動的プロパティは、ＵＩプロパティ変更に関してリッスンされなければならない。単方向バインドタイプもまた、ＵＩプロパティの変更が単に他の表示の詳細を示すためだけであれば、有用であると思われる。
【００１９】
バインドタイプ２６２が双方向として指定されている場合、これは、バインディングエンジン２２４に、ソースデータバリューに変更が生じる毎にターゲットプロパティをアップデートし、またその逆を行うよう通知する。双方向バインディングは、ユーザが編集ボックスで行った変更がソースデータバリューに伝搬される必要がある場合にデータを編集ボックスにバインドするときに特に有用である。双方向バインディングの別のシナリオは、他のアプリケーションがソースデータフィールドを受け持ち、変更が編集ボックスの中に反映される場合である。
【００２０】
バインドタイプ２６２が一度だけのものとして指定されている場合、これは、バインディングエンジン２２４に、関連するソースデータバリューが変更された場合でも、ターゲットプロパティを１回アップデートしてからそのまま終了するよう通知する。一度だけのバインドタイプ(oneTime bindtype)は、一部のターゲットプロパティがソースフィールドからの何らかのバリューで初期化される必要があり、データコンテキストがあらかじめ知られていない場合に使用される。さらに、一度だけのバインドタイプは、ソースデータバリューを変更せずに読み取り専用で使用する場合に有用である。データソースが本発明のプロパティ通知メカニズムをサポートしていない場合（例えば、ＩＰｒｏｐｅｒｔｙＣｈａｎｇｅインターフェース）、単方向として指定されているターゲットプロパティは、バインディングがバインドタイプとして一度だけを指定している場合と同様にアップデートされる。
【００２１】
バインディングプロパティのもう１つ（これ以降、アップデートタイプ２６４と呼ぶ）により、バインドタイプ２６２が双方向を指定する場合に対するアップデートの種類を定義する。通常、双方向バインディングは、ターゲットプロパティの変更をリッスンし、その変更をソースデータバリューに伝搬させて返す。このプロセスは、ソースをアップデートすると言われる。通常、ターゲットプロパティが変更されると必ずアップデートすることが望ましい。しかし、状況によっては、キーを押す毎にアップデートするのでは無駄なサイクルが発生し、ユーザには入力エラーなどを訂正するチャンスがない。アップデートタイプ(updatetype)２６４では、ユーザはアップデートを実行する時期を特定することができる。一実施形態では、アップデートタイプ２６４により、Ｉｍｍｅｄｉａｔｅ、ＯｎＬｏｓｔＦｏｃｕｓ、およびＥｘｐｌｉｃｉｔを特定(specify)することができる。Ｉｍｍｅｄｉａｔｅを特定すると、バインディングエンジンは、ターゲットプロパティが変更される毎に、ソースデータバリューをアップデートする。ＯｎＬｏｓｔＦｏｃｕｓを特定すると、バインディングエンジンは、ターゲットエレメントがキーボードのフォーカスを失った後、ソースデータバリューをアップデートする。Ｅｘｐｌｉｃｉｔを特定すると、バインディングエンジンは、アプリケーションがアップデートを明示的に要求した場合のみ、ソースデータバリューをアップデートする。通常、この明示的な要求はメソッドを介して実行される。このメソッドはアップデートタイプ２６４の設定のため呼び出されることが可能であっても、このメソッドは、アップデートタイプがＥｘｐｌｉｃｉｔに設定されている場合に使用される。方法例を１つ以下に示す。
Binding.GetBinding(myElement, myProperty).Update();
【００２２】
バインディングプロパティのもう１つ（これ以降、ソース(source)２６６と呼ぶ）により、バインディングに対するソースデータ項目を識別する。簡単にいうと、図４に示され、それに関して説明されているように、ソース２６６は、プログラムにより、またはマークアップを使用して、設定されることが可能である。プログラムに関しては、開発者は、バインディングでソースデータ項目として使用しなければならないオブジェクトへのｏｂｊｅｃｔｒｅｆを用意する。簡単にいうと、図４に関して詳細に説明していうように、マークアップでは、ソースプロパティを設定するさまざまな方法がある。
【００２３】
バインディングプロパティのもう１つ（これ以降、トランスフォーマ(transformer)２６８と呼ぶ）は、クラス参照(class reference)を受け入れる。クラス参照は、＜Ｎａｍｅｓｐａｃｅ＞．＜Ｃｌａｓｓ＞，＜Ａｓｓｅｍｂｌｙ＞を使用して特定されることが可能である。特定されているクラス参照は、バインディングエンジン２２４により呼び出され、ソースデータバリューをターゲットプロパティによって受け入れられる形式にトランスフォームする。クラス参照内のメソッドはこのトランスフォームを呼び出すが、図２にトランスフォーム２４４として表されている。クラス参照では、さらに、ターゲットプロパティをソースデータバリューにより受け入れられる形式にトランスフォームする逆トランスフォーム(inverse transform)（図に示されていない）も特定することができる。トランスフォーム２４４は、ＵＩの意味を供給するか、またはカスタムタイプのコンバータとすることができる。
【００２４】
バインディングプロパティのもう１つ（これ以降カルチャー２７０と呼ぶ）は、ソースデータバリューをトランスフォームする前／後にソースデータバリューが処理されるべき方法を定義する。カルチャー２７０は、トランスフォーマ２６８とともに動作し、開発者はいソースデータバリューをトランスフォームする規則を特定することができる。例えば、カルチャーでは、数バリュー、日付などに対する特定の形式を特定することができる。一実施形態では、カルチャー２７０は、ＣｕｌｔｕｒｅＩｎｆｏ型のバリューを受け入れる。開発者は、トランスフォームを実行する際にカルチャー２７０により特定された規則を使用するオプションを用意する。
【００２５】
バインディングプロパティのもう１つ（これ以降、バインドフラグ２７２と呼ぶ）は、イベントを受信し、データの転送を通知するイベントを受信するメカニズムを備える。データバインディングの上述の方法は非同期であるが、バインドフラグ２７２では、開発者はいつターゲットが新しいバリューでアップデートされているかを知ることができる。このメカニズムを使用するために、バインドフラグ２７２は「ＮｏｔｉｆｙＯｎＴｒａｎｓｆｅｒ」に設定される。その後、いつもの方法を使用しイベントに関してハンドラを登録する。このようなメカニズムの一使用例を以下に示す。
Public static void main()
{
//ハンドラを追加する
elem.AddAttachedHandler(Binding.DataTranferEvent,
new DataTranferEventHandler(OnDataTransfer),
RoutedEventArgs.EventStage.Direct);
//イベントハンドラ
private static void OnDataTransfer(Element e, DataTransferEventArgs args)
{
DynamicProperty DP=args.DP;
v=e.GetValue(DP);
DoSomething(v);
}
source.field="new value";
}.
【００２６】
上記のコード例に示されているように、ＯｎＤａｔａＴｒａｎｓｆｅｒイベントが発生すると、開発者は動的プロパティがアップデートされていることが通知される。したがって、開発者は、さらに処理を進めるためターゲットバリューを使用することが可能である。
【００２７】
図３は、本発明の一実施形態によるバインディングメカニズムを例示する論理流れ図である。概して、バインディングメカニズムは、バインディングをセットアップするアクションを実行し（ブロック３０２〜３０６）、その後、バインディングで特定されているようにターゲットプロパティまたはソースデータバリューの変更に関係するアクションを実行する（ブロック３１０〜３３８）。処理は、ブロック３０２に続く。
【００２８】
ブロック３０２において、作成時に特定された引数(argument)に基づいてバインディングオブジェクトが作成される。簡単に言うと、バインディングオブジェクト２５２に対する各プロパティ（つまり、図２に示されているプロパティ２６０〜２７２）は、作成時に引数として特定されることが可能である。バインディングは、マークアップを通じて、プログラムで、および類似の方法で作成されることが可能である。図４は、バインディングを作成し、プロパティ２６０〜２７２を特定する構文例を示している。それぞれの作成方法で、ソースデータ項目、ソースデータ項目内のデータバリューへのパス、ターゲットＵＩエレメント、およびおＵＩエレメント上のターゲット動的プロパティを特定する。現在の流れ図には示されていないが、バインディングオブジェクトのプロパティも、アプリケーションプログラミングインターフェース（ＡＰＩ）を使用するなどして、実行時に動的に修正されることが可能である。処理はステップ３０６に進む。
【００２９】
ブロック３０４において、バインディングがアクティブにされる。一実施形態では、バインディングは、バインディングエンジンがソースオブジェクトを存在させる、ターゲットエレメントを表示できる状態にするなど、バインディングに十分なコンテキストがあることを通知した後、自動的にアクティブ化されることが可能である。バインディングエンジンは、バインディングのアクティブ化を認識することを受け持つ。処理は、ブロック３０４に続く。
【００３０】
ブロック３０６において、特定されたソースプロパティのバリューが見つけられる。一実施形態では、バリューを見つけるためにリフレクションが使用される。リフレクションは、要求されたオブジェクトに関する情報を呼び出し側が取得するために使用する一般的なメカニズムである。この情報は、サポートされているオブジェクト、パブリックプロパティなどを含む。他の実施形態では、データ項目がコレクションである場合、バインディングエンジンは、発見的手法を何度も実行して、現在のレコードまたはデータオブジェクト（コレクション）自体を使用しているかどうかを判別する。第１の発見的手法は、バインディングがプロパティまたはインデクサを参照したときに適用される。このような状況では、コレクションオブジェクト上の対応するプロパティまたはインデクサは、そのようなプロパティまたはインデクサが存在する場合に使用される。それとは別に、コレクションの現在のレコードはデータ項目として使用される。プロパティまたはインデクサが存在しない場合、他の発見的手法が適用される。このような状況では、コレクションオブジェクトは、コレクションオブジェクトは有効である限り、ターゲットプロパティに使用される。そうでない場合、現在のレコードが使用される。ブロック３０８に進む前に、バインディングでトランスフォームを特定している場合（ブロック３０７）、トランスフォームがバリューに適用される。トランスフォームの適用については、以下のブロック３１６に関して詳しく説明されている。処理は、ブロック３０８に続く。
【００３１】
ブロック３０８において、見つかったバリューは、ターゲットプロパティに割り当てられる。一実施形態では、プロパティの階層保持する役割を持つプロパティエンジンがバリューを割り当てることができる。他の実施形態では、ターゲットプロパティにバリューを割り当てる前に、バリューをトランスフォームするためにバインディングの作成時に特定されたトランスフォームを呼び出すことが可能である。他の精密化では、プロパティエンジンはプロパティに新しいバリューを持つというマークをつけることができる。ブロック３０２〜３０８が実行された後、バインディングエンジンは、ターゲットプロパティおよびソースデータバリューを必要に応じてアップデートする用意ができている。一般に、バインディングメカニズムは非同期である。
【００３２】
したがって、ブロック３０８から、処理は２つの非同期パスを辿る。第１のパス（ブロック３１０〜３１８）は、ターゲットプロパティをアップデートすることに関連付けられており、第２のパス（ブロック３３０〜３３８）は、ソースデータバリューをアップデートすることに関連付けられている。これらのパスのそれぞれについて以下で説明する。第１に、ターゲットプロパティをアップデートする役割を持つパスについて示される。
【００３３】
決定ブロック(decision block)３１０において、バインディングエンジンは、ソースデータバリューおよびターゲットプロパティに関連付けられているバインディングでバインドタイプを一度だけとして特定しているかどうかを判別する。バインドタイプが一度だけの場合、そのバインドに関して処理は完了しており、終了に進む。当業者であれば、バインドタイプが一度だけの場合、バインディングエンジンはソースプロパティの変更イベントをリッスンしないことを理解するであろう。したがって、実際の運用では、バインディングエンジン内のロジックは必ずしも、ブロック３１０で示されているようにチェックを実行しない。さらに、データ項目がＩＰｒｏｐｅｒｔｙＣｈａｎｇｅを実施しない場合、処理は完了する。しかし、バインドタイプが一度だけでない場合には、処理はブロック３１２に続く。
【００３４】
ブロック３１２において、バインディングエンジンはバインディングに関連付けられている通知をリッスンする。データバインディングでソースデータバリューを使用してターゲットを直接アップデートしないため、本発明では通知メカニズムを実施する。プロパティ変更通知およびコレクションビュー「ＣｕｒｒｅｎｔＣｈａｎｇｅｄ」通知などの通知メカニズムは、当業では知られており、ここではさらに詳しい説明を要しない。異なるアクションにより、データバリュー変更、ページナビゲーション、シャットダウン、データコレクション内の注目するレコードの変更などの通知が実行される。本発明はデータコレクション内の注目するレコードの変更があるとアップデートをトリガするので、本発明は、ユーザインターフェースおよびロジックをさらに分離する便利なメカニズムを備える。例えば、本発明により、開発者は、データコレクション内の注目する次のレコードにどのように変更を加えるかを特定するコードをロジック内に作成するだけでよい。変更が実行されると、バインディングエンジンは、本発明により、すでに特定されているバインディングに基づき、ユーザインターフェースをアップデートする。すでに述べたように、ユーザインターフェースとロジックとのこのような分離により、ユーザインターフェースおよびロジックが相互に関連していたときに比べてアプリケーションはより堅牢になり、また保守も容易になっている。
【００３５】
以下のコードは、通知メカニズムの一実施例である。以下で作成されたコード例はＣ＃で書かれているが、当業者であれは、通知メカニズムを実施するためにさまざまな言語および構文が使用されることが可能であることを理解するであろう。このような実施については、各データ項目で使用できるようにインターフェースが定義される。各データ項目は、動的アップデートを実施するためにこのインターフェースを継承する。
Public interface IPropertyChange
{
event PropertyChangedEventHandler PropertyChanged;
}.
【００３６】
次に、イベントハンドラ(event handler)およびその引数(argument)が定義される。
public delegate void PropertyChangedEventHandler(object sender, PropertyChangedEventArgs e);
public class PropertyChangedEventArgs:EventArgs
{
public virtual string PropertyName { get ;}
}.
【００３７】
クラスPropertyChangedEventArgsは型文字列を持つPropertyNameという名前の読み取り専用プロパティを１つ含む。PropertyNameプロパティは、変更されたプロパティに対する名前を含む。次に、各ソースデータ項目は、そのプロパティの１つが変更された場合に必ず、ＰｒｏｐｅｒｔｙＣｈａｎｇｅｄデリゲートを呼び出すことによりこのインターフェースを実施する。以下は、通知メカニズムの実施形態により、ソースオブジェクト（例えば、データ項目２３２）を実施する例である。
public class myClass : IPropertyChange
{
private string foo = "Hello World";
public string Foo
{
get {return foo;}
set {if(foo ! = value)
{
foo = value;
NotifyPropertyChanged("foo");
}
}
public event PropertyChangedEventHandler Property Changed;
private void NotifyPropertyChanged(string propName)
{
PropertyChanged(this, new
PropertyChangedEventArgs(propName));
}
}.
【００３８】
上記のコード例に示されているように、「ｆｏｏ」プロパティの「ｓｅｔ」メソッドは、新しいバリューが旧いバリューと異なるかどうかを判別する。バリューが異なる場合、ハンドラが呼び出される。PropertyInfoを取得するためリフレクションが実行される。他の精密化では、バインディングエンジンは、リフレクションを通じて取得されたプロパティの型をキャッシュすることができる。したがって、リフレクションは１回実行され、プロパティについて通知が受信される毎に実行されるわけではない。他の精密化では、引数で空文字列が渡され、データ項目のデータバリューのそれぞれに対するすべてのバインディングをアップデートすべきであることを通知することができる。これは、ソースオブジェクトで、どのプロパティが変更され、各バインディングをアップデートしたいかがはっきりしない場合に実行できる。バインディングエンジンが、データソースバリューが変更されたという通知を受信すると、処理は決定ブロック３１４に進む。
【００３９】
決定ブロック３１４において、変更されたソースデータバリューに関連付けられているバインディングでバインディングに対するトランスフォームを特定していたかどうかを判別する。バインディングでトランスフォームを特定していない場合には、処理はブロック３１８に続く。しかし、バインディングでトランスフォームを特定している場合には、処理はブロック３１６に続く。
【００４０】
ブロック３１６において、バインディングで特定されているトランスフォームが実行される。一実施形態では、トランスフォーマ２６８は後述のようなオブジェクトである。
Public interface IDataTransformer
{
Public object Transform(object o, DynamicProperty dp, CultureInfo c) {;}
}.
【００４１】
上記のインターフェースでは、ｏはソースバリューを表し、ｄｐはターゲットの動的プロパティを表し、ｃはトランスフォーム時(transfomation)に使用するカルチャー(culture)を表す。Ｔｒａｎｓｆｏｒｍ（）メソッドは、ソースバリューｏを型ｄｐの動的プロパティに割り当てるのに適しているオブジェクトにトランスフォームする。Ｔｒａｎｓｆｏｒｍ（）メソッドは、バインディングのソースからターゲットプロパティにデータバリューを伝搬させるとき呼び出される。Ｔｒａｎｓｆｏｒｍ（）メソッドがｎｕｌｌバリューを返した場合、バインディングエンジンに対し、バリューの伝搬を停止することが通知される。
【００４２】
トランスフォーマは、さらに、バインディングで特定された関連ソースデータバリューに基づいて幅、高さ、フォント、位置（ｘ、ｙ）などの他のＵＩプロパティを制御するために使用されることも可能である。トランスフォーマでは、複数の方法でデータを表示するためデータバリューに対しロジックを実行することができる。他の精密化では、カルチャーは、バインディングで特定されているようにトランスフォーム時に適用されることも可能である。処理は、ブロック３１８に続く。
【００４３】
ブロック３１８において、ターゲットプロパティがアップデートされる。一実施形態では、プロパティエンジンはバリューをターゲットプロパティに割り当てる。さらに、ターゲットプロパティは新しいバリューを持つとマーク付けされることも可能である。その後処理はブロック３１２に続き、バインディングに関連付けられている次のプロパティ変更通知をリッスンする。アプリケーションが終了するか、またはバインディングが他の何らかの手段により打ち切られると、処理は終わりに進む。
【００４４】
上述のように、処理は、ブロック３０８から第２のパスへと続くことが可能である。したがって、ブロック３０８から、処理は決定ブロック３３０に続く。上述のように、決定ブロック３１０に関して、バインディングエンジン内のロジックは決定ブロック３１０でバインドタイプのチェックを必ずしも実行することはできないが、むしろ、バインディングエンジンはバインディングが作成されたときに通知をリッスンするように指示されていたため、プロセスは第２のパス内を流れない。しかし、流れの説明を明確にするために、バインドタイプを反映する決定ブロックが示されている。したがって、決定ブロック３３０において、バインディングが双方向(twoWay)のバインドタイプとして特定したかどうかの判別が行われる。すでに述べたように、双方向では、ターゲットプロパティの変更をソースデータバリューに伝搬させることができる。バインディングで双方向バインドタイプとして特定していない場合、処理は終わりに進む。しかし、バインディングで双方向バインドタイプとして特定している場合には、処理はブロック３３２に続く。
【００４５】
ブロック３３２において、バインディングエンジンは、ソースデータバリューのアップデートをトリガするいくつかのアクションを認識する。トリガが発生すると、処理は決定ブロック３３４に続く。
【００４６】
決定ブロック３３４において、バインディングがバインドに対し逆トランスフォームを特定したかどうかの判別が行われる。バインディングで逆トランスフォームを特定していない場合には、処理はブロック３３８に続く。しかし、バインディングで逆トランスフォームを特定している場合には、処理はブロック３３６に続く。
【００４７】
ブロック３３６において、逆トランスフォームがソースプロパティに適用される。一実施形態では、逆トランスフォーマは後述のようなオブジェクトである。
Public interface IDataTransformer
{
Public object InverseTransform(object o, PropertyInfo pinfo, CultureInfo c){;}
}.
【００４８】
上記のインターフェースでは、ｏはソースバリューを表し、ｃはトランスフォーム時に使用するカルチャーを表し、ｐｉｎｆｏはターゲットプロパティのＰｒｏｐｅｒｔｙＩｎｆｏを表す。ＩｎｖｅｒｓｅＴｒａｎｓｆｏｒｍ（）メソッドは、ソースバリューｏを型ｉｎｆｏのプロパティに割り当てるのに適しているオブジェクトにトランスフォームする。このメソッドは、バインディングのターゲットからソースにバリューを伝搬させるとき呼び出される。ＩｎｖｅｒｓｅＴｒａｎｓｆｏｒｍ（）メソッドがｎｕｌｌバリューを返した場合、バインディングエンジンはバリューを伝搬しない。ＩｎｖｅｒｓｅＴｒａｎｓｆｏｒｍが実行されると、処理は決定ブロック３３８に続く。
【００４９】
ブロック３３８において、アップデートタイプに応じてソースプロパティがアップデートされる。上述のように、アップデートタイプは、即時、フォーカスの喪失、明示的、およびその他をきっかけとしてよい。ソースプロパティがアップデートされた後、処理は終了へ進む。
【００５０】
図４は、バインディングを作成するいくつかの例を示している。作成手段(creation means)４００〜４１０では、マークアップを通じてバインディングを作成する。作成手段４１０では、コードを通じてバインディングを作成する。図４に示されている手段例は網羅的ではない。他の手段（構文）は、本発明の範囲から逸脱することなく、使用されることが可能である。
【００５１】
作成手段４００は、エレメント４２４に対しＤａｔａＣｏｎｔｅｘｔ名／バリューのペア（これ以降、ＤａｔａＣｏｎｔｅｘｔ ４２２と呼ぶ）およびＩｄ名／バリューのペア（これ以降、Ｉｄ ４２０と呼ぶ）を含む。作成手段４００はさらに、ＤａｔａＣｏｎｔｅｘｔ ４２２も含むため、Ｉｄ ４２０は不要である。Ｉｄ ４２０は、マークアップでＥｌｅｍｅｎｔＳｏｕｒｃｅを使用したり、コード内でＩｄＯｂｊｅｃｔＲｅｇを使用したりするなど、明示的なソースを参照するのが望ましい場合に必要である。これらの両方の用途について後で説明される。ＤａｔａＣｏｎｔｅｘｔ ４２２は、エレメント（例えば、エレメント４２４）で定義されている動的プロパティである。ＤａｔａＣｏｎｔｅｘｔ ４２２に関連付けられているバリューは、デフォルトのソースデータ項目を表し、継承可能なプロパティである。バインディングエンジンは、ＤａｔａＣｏｎｔｅｘｔ ４２２にクエリを実行し、エレメント４２４および子孫エレメント（例えば、Ｂｕｔｔｏｎエレメント４２６）のバインディングを作成するときにＤａｔａＣｏｎｔｅｘｔ ４２２を使用する。バインディングエンジンは、さらに、ＤａｔａＣｏｎｔｅｘｔ ４２２の変更についてもリッスンするし、そのトリガによりアップデートを実行する。したがって、必要はないけれども、ＤａｔａＣｏｎｔｅｘｔ ４２２は共通データ項目にバインドされるすべてのプロパティについてスコープを確立する便利なメカニズムを備える。子孫エレメントは、自ＤａｔａＣｏｎｔｅｘｔを持つことができ、これは親エレメントのＤａｔａＣｏｎｔｅｘｔ ４２２に優先する。バインディングは、作成手段４０２に関して後述するｎｕｌｌでないソースを供給することにより、ＤａｔａＣｏｎｔｅｘｔ ４２２をオーバーライドすることができる。
【００５２】
Ｂｕｔｔｏｎエレメント４２６は、ターゲットプロパティで例示されている（例えば、 Ｂｕｔｔｏｎ．Ｔｅｘｔ ４２８）。本発明では、バインディングエンジンは、「Ｄａｔａ：Ｂｉｎｄ」を見つけると、バインディングが特定されていることを認識する。後の名前／バリューのペアは、図２で特定されているように、バインディングプロパティ２６０〜２７２を設定する。当業者であれば、バインディングを示す「Ｄａｔａ：Ｂｉｎｄ」という用語は任意の用語であり、本発明を逸脱することなく用語はいくつ使用されていてもかまわない。作成手段４００は、詳細マークアップ形式を表す。
【００５３】
作成手段４０２は、コンパクトマークアップ形式を表す。ＵＩプロパティ（例えば、Ｂｕｔｔｏｎ Ｔｅｘｔ）は、さらにコンパクトな方式で表される。ここでもまた、「Ｄａｔａ：Ｂｉｎｄ」は、バインディングエンジンに対し後に続くのがバインディングであることを知らせるシグナルとして使用される。さらに、名前／バリューのペアと後に続く「Ｄａｔａ：Ｂｉｎｄ」は、図２でバインディングオブジェクト２５０についてすでに説明している所望のプロパティ２６０〜２７２に対応する。例えば、ＥｌｅｍｅｎｔＳｏｕｒｃｅ名／バリューのペア（これ以降ＥｌｅｍｅｎｔＳｏｕｒｃｅ ４３４と呼ぶ）はソース２６６に対応している。
【００５４】
マークアップでは、ソースプロパティを設定する方法は、ＥｌｅｍｅｎｔＳｏｕｒｃｅおよびＤａｔａＳｏｕｒｃｅの２つがある。これらのいずれも使用されない場合、ソースのデフォルトバリューはｎｕｌｌであり、作成後、エレメントのＤａｔａＣｏｎｔｅｘｔプロパティのバリューを取得し、そのバリューをソースオブジェクトとして使用するようバインディングエンジンに通知する。
【００５５】
作成手段（例えば、作成手段４０２）でＥｌｅｍｅｎｔＳｏｕｒｃｅを特定した場合、バインディングエンジンは、ＥｌｅｍｅｎｔＳｏｕｒｃｅプロパティにより特定されているＩＤを持つエレメントを見つける。その後、エレメントのＤａｔａＣｏｎｔｅｘｔｉｓは、ソースオブジェクトとして使用される。／Ｐａｒｅｎｔ／Ｐａｒｅｎｔおよび／Ｐｒｅｖｉｏｕｓ／Ｐｒｅｖｉｏｕｓなどの相対パス名は、データソースを特定するために使用されることが可能である。バインディングエンジンは、／Ｐａｒｅｎｔを見つけると、オブジェクト階層に関して現在のエレメントの親であるエレメントを探す。例えば、エレメントが顧客注文である場合、／Ｐａｒｅｎｔを特定すると、現在の注文に対する顧客に対応するエレメントを探すようにバインディングエンジンに通知することができる。／Ｐａｒｅｎｔを特定するのは、内側リピータのスコープ内にある外側リピータからのバリューを使用するのが望ましいネストされているリピータの場合に役立つ。／Ｐｒｅｖｉｏｕｓを特定すると、バインディングエンジンはＲｅｐｅａｔｅｒの下にある現在のエレメントの前のエレメントを探す。／Ｐｒｅｖｉｏｕｓを特定するのは、棒グラフなど、現在の項目の他に現在のｎ項目にアクセスするのが望ましい場合に便利である。連続する／Ｐｒｅｖｉｏｕｓと／Ｐａｒｅｎｔは、本発明に従って使用されることが可能である。
【００５６】
他の実施形態では、マークアップでＤａｔａＳｏｕｒｃｅを特定することができる。ＤａｔａＳｏｕｒｃｅが特定された場合、バインディングエンジンはＲｅｓｏｕｒｃｅのリソースＩＤを受け入れる。Ｒｅｓｏｕｒｃｅがデータプロパティを公開する場合、バインディングエンジンは、バインディングのソースを、ＤａｔａＳｏｕｒｃｅリソースのデータプロパティによって返されるオブジェクトに設定する。そうでない場合、バインディングエンジンはバインディングのソースをリソースオブジェクト自体に設定する。
【００５７】
当業者であれば、マークアップ言語を使用してプロパティ２６０〜２７２が表現され、したがって、これは他のプロパティのそれぞれがマークアップ言語を使用して表現されることが可能であることを理解するであろうし、ここで詳細には説明しない。
【００５８】
次の３つの作成手段４０４〜４１０は、本発明でバインドすることができる項目の種類に関して例を与える。作成手段４０４は、サブプロパティおよびインデクサへのバインディングのサポートを示している。作成手段４０４は、ｄｉ．ａ．ｂ［３］．ｃのようにＣ＃で書かれているバインディングに対応しており、ｄｉは関連するデータ項目である。データ項目、ｄｉ．ａを実施するクラス、ｄｉ．ａ．ｂを実施するクラス、およびｄｉ．ａ．ｂ［３］．ｃを実施するクラスが本発明の通知メカニズム（例えば、ＩＰｒｏｐｅｒｔｙＣｈａｎｇｅ）をサポートし、プロパティが変更されたときに通知する限り、作成手段４０４を使用して特定されたバインディングにより、バインディングエンジンは自動的にバインドされているプロパティ（例えば、ターゲットプロパティ）をアップデートし、ソースデータバリューの変更を反映する。
【００５９】
作成手段４０６は、データコレクションへのバインディングのサポートを示している。バインディングエンジンは、自動的に、各レベルでコレクションの現在のレコードを使用する（ａ、ｂ、およびｃは異なるレベルを表す）。例えば、ｄｉ．ａがＩＤａｔａＣｏｌｌｅｃｔｉｏｎ型であれば、バインディングでは、「ｂ」プロパティをフェッチするためにコレクションの現在のレコードを使用する。したがって、バインディングエンジンは、現在のレコードが変更された場合に必ず、データコレクションに関連付けられているバリューを自動的にアップデートする。
【００６０】
作成手段４０８は、ＸＭＬノードへのバインディングのサポートを示している。バリューへのパス２６０は、図４に示されているように、「／Ｃｕｓｔｏｍｅｒ／Ｏｒｄｅｒ［＠ＯｒｄｅｒＩＤ＝１０］／Ａｍｏｕｎｔ）」などのｘｐａｔｈ表現を使用して与えられる。作成手段４１０は、ＡＤＯデータテーブルへのバインディングのサポートを示している。この実施に関しては、バリューへのパス２６０は、図４に示されているように、「ＯｒｄｅｒｌＤ」などの特定の行に対するフィールド名として与えられる。
【００６１】
作成手段４１０では、プログラムによりバインディングを作成する。開発者は、バインディングでソースデータ項目として使用しなければならないオブジェクトへのｏｂｊｅｃｔｒｅｆを用意する。作成手段４１２に示されているプログラムのステートメントは、作成手段４１０により例示されているのと同じ動作でバインディングを作成する。ＳｅｔＢｉｎｄｉｎｇメソッドは、プログラマが上述のバインディングプロパティを特定する際に使用できるより精巧な変更形態を多数備える。上の単純な例では、ボタンのＤａｔａＣｏｎｔｅｘｔをソースオブジェクトとして使用する。以下のプログラムのステートメントは、特定のオブジェクト（実行時に知られる）をソースとして使用する単方向バインディングを作成する。
Object source = ... 何らかの任意のオブジェクト ...;
Binding.SetBinding(myButton, Element.BackgroundProperty, "Color", BindType.OneWay, new ExplicitObjectRef(source));
【００６２】
以下のコード例は、本発明のバインディングメカニズムを介してデータによりユーザインターフェースプロパティを制御するための一実施を示している。この例では、データバリュー（例えば、ｍｙＩｎｔｅｇｅｒ）およびＵＩプロパティ（例えば、ＴｅｘｔＣｏｎｔｅｎｔ）は、バインディングとしてアクティブ化にされる。さらに、トランスフォーム（例えば、ＭｙＴｒａｎｆｏｒｍｅｒ）は、このバインディングに対して特定される。
<Test TextContent="*Data:Bind(Path=myInteger)"
Foreground="*Data:Bind(Path=MyInteger;
Transformer=MyTransformer)"/>
public class MyTransformer:IDataTransformer
{
public object Transform(object o, DynamicProperty dp, CultureInfo culture)
{
if ((int)o <0) return Red;
else return Black;
}
public object InverseTransform(object o, PropertyInfo info, CultureInfo culture)
{
return null;
}
}.
【００６３】
したがって、説明したように、本発明は、ユーザインターフェースおよびロジックのコーディングの変更が分離されるようにソースデータバリューをターゲットプロパティに関連付けるメカニズムを備える。したがって、本発明により、開発者はアプリケーションの基本ロジックを修正することなく、ユーザインターフェースを容易に修正し、機能強化することができる。
【００６４】
上記の明細、実施例、およびデータにより、本発明の構成の製造および使用に関する説明が完全になされている。本発明の多くの実施形態は、本発明の精神と範囲を逸脱することなく実施できるため、本発明は付属の請求項によって定められる。
【特許請求の範囲】
【請求項１】
１つ又は複数のユーザインターフェースプロパティをそれぞれ含むユーザインターフェースエレメントを有するユーザインターフェース部分と、ソースデータバリューを操作するように構成されたロジック部分とを備えるコンピュータ実行可能プログラムを格納したコンピュータ可読記録媒体であって、前記プログラムは、記憶手段を備えるコンピュータに
前記ユーザインターフェース部分のユーザインターフェースプロパティを前記記憶手段に記憶されたソースデータバリューと関係付けるバインディングを作成するステップと、
前記バインディングのバインディングオブジェクトであって、前記ソースデータバリューを特定するための方法を含むパスと、バインディングのタイプを定義するバインディングタイプと、前記ユーザインターフェースプロパティに対するアップデートが発生した時期を特定するアップデートタイプと、前記ソースデータバリューをトランスフォームするための規則を特定するためのカルチャープロパティとを含むバインディングプロパティを有するバインディングオブジェクトを作成するステップと、
前記ソースデータバリューが変更された通知を受けたとき、当該ソースデータバリューに係る前記バインディングオブジェクトに基づいて前記ユーザインターフェースプロパティに前記変更を反映させるステップと、を実行させ、
前記バインディングタイプは、前記ソースデータバリューを編集不可能な前記ユーザインターフェースプロパティに前記バインディングにより関係付ける場合に使用される「単方向」、又は前記ソースデータバリューを編集可能な前記ユーザインターフェースプロパティに前記バインディングにより関係付ける場合に使用される「双方向」を含み、
前記受ける通知は、前記変更されたソースデータバリューに係る前記バインディングオブジェクトの前記バインディングタイプに基づいていること
を特徴とするコンピュータ可読記録媒体。
【請求項２】
前記ユーザインターフェースプロパティに前記変更を反映させる前に、前記カルチャープロパティに基づいて前記ソースデータバリューをトランスフォームすることを特徴とする請求項１に記載のコンピュータ可読記録媒体。
【請求項３】
前記プログラムは、前記コンピュータに
前記ユーザインターフェースプロパティが変更されたときに、前記ソースデータバリューを更新するステップを実行させること
を特徴とする請求項１又は請求項２に記載のコンピュータ可読記録媒体。
【請求項４】
前記ソースデータバリューを更新するステップは、前記ユーザインターフェースプロパティの変更の後に非同期で実行されることを特徴とする請求項３に記載のコンピュータ可読記録媒体。
【請求項５】
前記ソースデータバリューを更新するステップは、前記ユーザインターフェースエレメントに対するフォーカスが失われた後に非同期で実行されることを特徴とする請求項３に記載のコンピュータ可読記録媒体。
【請求項６】
前記作成されたバインディングは、コードを使用して特定されることを特徴とする請求項１から請求項５のいずれか１つに記載のコンピュータ可読記録媒体。
【請求項７】
前記作成されたバインディングは、マークアップ言語を使用して特定されることを特徴とする請求項１から請求項５のいずれか１つに記載のコンピュータ可読記録媒体。
【請求項８】
前記プログラムは、前記コンピュータに
前記ユーザインターフェースプロパティを他のソースデータバリューに関連付ける他のバインディングを作成するステップを実行させること
を特徴とする請求項１に記載のコンピュータ可読記録媒体。
【請求項９】
前記ソースデータバリューは、前記記憶手段から、ＸＭＬ上のＸＰａｔｈ、ＡＤＯのカラム、およびリフレクションのうちの１つを通じて特定されることを特徴とする請求項１から請求項８のいずれか１つに記載のコンピュータ可読記録媒体。
【請求項１０】
１つ又は複数のユーザインターフェースプロパティをそれぞれ含むユーザインターフェースエレメントを有するユーザインターフェース部分と、
ソースデータバリューを操作するように構成されたロジック部分と、
記憶手段と、
前記ユーザインターフェース部分のユーザインターフェースプロパティを前記記憶手段に記憶されたソースデータバリューと関係付けるバインディングを作成する手段と、
前記バインディングのバインディングオブジェクトであって、前記ソースデータバリューを特定するための方法を含むパスと、バインディングのタイプを定義するバインディングタイプと、前記ユーザインターフェースプロパティに対するアップデートが発生した時期を特定するアップデートタイプと、前記ソースデータバリューをトランスフォームするための規則を特定するためのカルチャープロパティとを含むバインディングプロパティを有するバインディングオブジェクトを作成する手段と、
前記ソースデータバリューが変更された通知を受けたとき、当該ソースデータバリューに係る前記バインディングオブジェクトに基づいて前記ユーザインターフェースプロパティに前記変更を反映させる手段とを備え、
前記バインディングタイプは、前記ソースデータバリューを編集不可能な前記ユーザインターフェースプロパティに前記バインディングにより関係付ける場合に使用される「単方向」、又は前記ソースデータバリューを編集可能な前記ユーザインターフェースプロパティに前記バインディングにより関係付ける場合に使用される「双方向」を含み、
前記受ける通知は、前記変更されたソースデータバリューに係る前記バインディングオブジェクトの前記バインディングタイプに基づいていること
を特徴とするコンピュータシステム。
【請求項１１】
前記ユーザインターフェースプロパティに前記変更を反映させる前に、前記カルチャープロパティに基づいて前記ソースデータバリューをトランスフォームすることを特徴とする請求項１０に記載のコンピュータシステム。
【請求項１２】
前記ユーザインターフェースプロパティが変更されたときに、前記ソースデータバリューを更新する手段を備えることを特徴とする請求項１０又は請求項１１に記載のコンピュータシステム。
【請求項１３】
前記ソースデータバリューを更新する手段は、前記ユーザインターフェースプロパティの変更の後に非同期で実行されることを特徴とする請求項１２に記載のコンピュータシステム。
【請求項１４】
前記ソースデータバリューを更新する手段は、前記ユーザインターフェースエレメントに対するフォーカスが失われた後に非同期で実行されることを特徴とする請求項１２に記載のコンピュータシステム。
【請求項１５】
前記作成されたバインディングは、コードを使用して特定されることを特徴とする請求項１０から請求項１４のいずれか１つに記載のコンピュータシステム。
【請求項１６】
前記作成されたバインディングは、マークアップ言語を使用して特定されることを特徴とする請求項１０から請求項１４のいずれか１つに記載のコンピュータシステム。
【請求項１７】
前記ユーザインターフェースプロパティを他のソースデータバリューに関連付ける他のバインディングを作成する手段を備えることを特徴とする請求項１０に記載のコンピュータシステム。
【請求項１８】
前記ソースデータバリューは、前記記憶手段から、ＸＭＬ上のＸＰａｔｈ、ＡＤＯの列、およびリフレクションのうちの１つを通じて特定されることを特徴とする請求項１０から請求項１７のいずれか１つに記載のコンピュータシステム。
【請求項１】
１つ又は複数のユーザインターフェースプロパティをそれぞれ含むユーザインターフェースエレメントを有するユーザインターフェース部分と、ソースデータバリューを操作するように構成されたロジック部分とを備えるコンピュータ実行可能プログラムを格納したコンピュータ可読記録媒体であって、前記プログラムは、記憶手段を備えるコンピュータに
前記ユーザインターフェース部分のユーザインターフェースプロパティを前記記憶手段に記憶されたソースデータバリューと関係付けるバインディングを作成するステップと、
前記バインディングのバインディングオブジェクトであって、前記ソースデータバリューを特定するための方法を含むパスと、バインディングのタイプを定義するバインディングタイプと、前記ユーザインターフェースプロパティに対するアップデートが発生した時期を特定するアップデートタイプと、前記ソースデータバリューをトランスフォームするための規則を特定するためのカルチャープロパティとを含むバインディングプロパティを有するバインディングオブジェクトを作成するステップと、
前記ソースデータバリューが変更された通知を受けたとき、当該ソースデータバリューに係る前記バインディングオブジェクトに基づいて前記ユーザインターフェースプロパティに前記変更を反映させるステップと、を実行させ、
前記バインディングタイプは、前記ソースデータバリューを編集不可能な前記ユーザインターフェースプロパティに前記バインディングにより関係付ける場合に使用される「単方向」、又は前記ソースデータバリューを編集可能な前記ユーザインターフェースプロパティに前記バインディングにより関係付ける場合に使用される「双方向」を含み、
前記受ける通知は、前記変更されたソースデータバリューに係る前記バインディングオブジェクトの前記バインディングタイプに基づいていること
を特徴とするコンピュータ可読記録媒体。
【請求項２】
前記ユーザインターフェースプロパティに前記変更を反映させる前に、前記カルチャープロパティに基づいて前記ソースデータバリューをトランスフォームすることを特徴とする請求項１に記載のコンピュータ可読記録媒体。
【請求項３】
前記プログラムは、前記コンピュータに
前記ユーザインターフェースプロパティが変更されたときに、前記ソースデータバリューを更新するステップを実行させること
を特徴とする請求項１又は請求項２に記載のコンピュータ可読記録媒体。
【請求項４】
前記ソースデータバリューを更新するステップは、前記ユーザインターフェースプロパティの変更の後に非同期で実行されることを特徴とする請求項３に記載のコンピュータ可読記録媒体。
【請求項５】
前記ソースデータバリューを更新するステップは、前記ユーザインターフェースエレメントに対するフォーカスが失われた後に非同期で実行されることを特徴とする請求項３に記載のコンピュータ可読記録媒体。
【請求項６】
前記作成されたバインディングは、コードを使用して特定されることを特徴とする請求項１から請求項５のいずれか１つに記載のコンピュータ可読記録媒体。
【請求項７】
前記作成されたバインディングは、マークアップ言語を使用して特定されることを特徴とする請求項１から請求項５のいずれか１つに記載のコンピュータ可読記録媒体。
【請求項８】
前記プログラムは、前記コンピュータに
前記ユーザインターフェースプロパティを他のソースデータバリューに関連付ける他のバインディングを作成するステップを実行させること
を特徴とする請求項１に記載のコンピュータ可読記録媒体。
【請求項９】
前記ソースデータバリューは、前記記憶手段から、ＸＭＬ上のＸＰａｔｈ、ＡＤＯのカラム、およびリフレクションのうちの１つを通じて特定されることを特徴とする請求項１から請求項８のいずれか１つに記載のコンピュータ可読記録媒体。
【請求項１０】
１つ又は複数のユーザインターフェースプロパティをそれぞれ含むユーザインターフェースエレメントを有するユーザインターフェース部分と、
ソースデータバリューを操作するように構成されたロジック部分と、
記憶手段と、
前記ユーザインターフェース部分のユーザインターフェースプロパティを前記記憶手段に記憶されたソースデータバリューと関係付けるバインディングを作成する手段と、
前記バインディングのバインディングオブジェクトであって、前記ソースデータバリューを特定するための方法を含むパスと、バインディングのタイプを定義するバインディングタイプと、前記ユーザインターフェースプロパティに対するアップデートが発生した時期を特定するアップデートタイプと、前記ソースデータバリューをトランスフォームするための規則を特定するためのカルチャープロパティとを含むバインディングプロパティを有するバインディングオブジェクトを作成する手段と、
前記ソースデータバリューが変更された通知を受けたとき、当該ソースデータバリューに係る前記バインディングオブジェクトに基づいて前記ユーザインターフェースプロパティに前記変更を反映させる手段とを備え、
前記バインディングタイプは、前記ソースデータバリューを編集不可能な前記ユーザインターフェースプロパティに前記バインディングにより関係付ける場合に使用される「単方向」、又は前記ソースデータバリューを編集可能な前記ユーザインターフェースプロパティに前記バインディングにより関係付ける場合に使用される「双方向」を含み、
前記受ける通知は、前記変更されたソースデータバリューに係る前記バインディングオブジェクトの前記バインディングタイプに基づいていること
を特徴とするコンピュータシステム。
【請求項１１】
前記ユーザインターフェースプロパティに前記変更を反映させる前に、前記カルチャープロパティに基づいて前記ソースデータバリューをトランスフォームすることを特徴とする請求項１０に記載のコンピュータシステム。
【請求項１２】
前記ユーザインターフェースプロパティが変更されたときに、前記ソースデータバリューを更新する手段を備えることを特徴とする請求項１０又は請求項１１に記載のコンピュータシステム。
【請求項１３】
前記ソースデータバリューを更新する手段は、前記ユーザインターフェースプロパティの変更の後に非同期で実行されることを特徴とする請求項１２に記載のコンピュータシステム。
【請求項１４】
前記ソースデータバリューを更新する手段は、前記ユーザインターフェースエレメントに対するフォーカスが失われた後に非同期で実行されることを特徴とする請求項１２に記載のコンピュータシステム。
【請求項１５】
前記作成されたバインディングは、コードを使用して特定されることを特徴とする請求項１０から請求項１４のいずれか１つに記載のコンピュータシステム。
【請求項１６】
前記作成されたバインディングは、マークアップ言語を使用して特定されることを特徴とする請求項１０から請求項１４のいずれか１つに記載のコンピュータシステム。
【請求項１７】
前記ユーザインターフェースプロパティを他のソースデータバリューに関連付ける他のバインディングを作成する手段を備えることを特徴とする請求項１０に記載のコンピュータシステム。
【請求項１８】
前記ソースデータバリューは、前記記憶手段から、ＸＭＬ上のＸＰａｔｈ、ＡＤＯの列、およびリフレクションのうちの１つを通じて特定されることを特徴とする請求項１０から請求項１７のいずれか１つに記載のコンピュータシステム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２００９−１５１８１０（Ｐ２００９−１５１８１０Ａ）
【公開日】平成２１年７月９日（２００９．７．９）
【国際特許分類】
【出願番号】特願２００９−３２０１２（Ｐ２００９−３２０１２）
【出願日】平成２１年２月１３日（２００９．２．１３）
【分割の表示】特願２００５−５００４０５（Ｐ２００５−５００４０５）の分割
【原出願日】平成１５年５月１７日（２００３．５．１７）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＥＥＰＲＯＭ
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公開日】平成２１年７月９日（２００９．７．９）
【国際特許分類】
【出願日】平成２１年２月１３日（２００９．２．１３）
【分割の表示】特願２００５−５００４０５（Ｐ２００５−５００４０５）の分割
【原出願日】平成１５年５月１７日（２００３．５．１７）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＥＥＰＲＯＭ
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]