テーブル通知について
適用対象: Outlook 2013 | Outlook 2016
クライアントは、多くの場合、オブジェクトから直接通知を受け取るために登録するのではなく、テーブル通知を使用してオブジェクトへの変更を学習します。 通知を送信する一般的な変更には、行の追加、削除、変更、重大なエラーなどがあります。 通知が到着すると、クライアントは別の呼び出しを行ってテーブルを再読み込みするかどうかを決定できます。
テーブル通知は非同期であるため、通知の処理が簡単ではないいくつかの問題があります。
TABLE_NOTIFICATION構造体で渡されたデータは、テーブルの最新の状態を表していない可能性があります。 たとえば、クライアントがメッセージに変更を加え、削除することを決定する場合があります。 メッセージを含むコンテンツ テーブルを実装するメッセージ ストア プロバイダーは、TABLE_ROW_MODIFIED イベントとそれに続く TABLE_ROW_DELETED イベントという 2 つの通知を送信します。 メッセージ ストア プロバイダーの通知の時刻に応じて、クライアントは行の削除後にTABLE_ROW_MODIFIED通知を受け取る場合があります。
通知に含まれる列セットは、テーブルの現在の列セットとは異なる場合があります。 MAPI では、通知列セットが、通知が生成された時点で有効だった列セットと一致している必要があります。 クライアントが IMAPITable::SetColumns を呼び出して、通知後を含め、いつでも列セットを変更できるため、2 つの列セットは同期されない可能性があります。
テーブル通知は、ビューの一部である行に対してのみ送信されます。 つまり、制限が原因で行がビューから除外された場合、またはテーブルが折りたたまれた状態になっている場合、その行が変更されても通知は送信されません。 また、カテゴリ状態の変更についてクライアントに通知する通知は送信されません。
クライアントは、すべてのテーブルがTABLE_SORT_DONE通知をサポートしているわけではないことを認識し、次の方法でこの条件を処理するように準備する必要があります。
並べ替えを強制的に同期する。
IMAPITable::SortTable が返されたときにテーブルの行を再読み込みする。