Execute()メソッドの目的は、更新プログラムがドキュメントに対して行われた変更に反応し、それに関して適切な処理を行えるようにすることです。このメソッドは、この更新プログラムの UpdateTrigger と一致した要素が追加、変更、削除されたドキュメント トランザクションの最後に Revit によって呼び出されます。このメソッドは、他の更新プログラムによって行われた変更により、同じトランザクションに複数回呼び出されることがあります。更新プログラムは DocumentChanged イベントの前に起動されるため、このイベントには、すべての更新プログラムによって行われた変更が含まれます。
このメソッドの呼び出し中に行われたドキュメントに対するすべての変更は、呼び出しトランザクションの一部になり、元に戻す、およびやり直し操作で編集されます。このメソッドを実装すると、新しいトランザクションを開けない(例外がスローされます)場合がありますが、必要に応じてサブトランザクションを使用できます。
また、このメソッドを使用してドキュメント以外のデータを更新することもできますが、このような変更は元のトランザクションの一部にはならず、元のトランザクションが元に戻されたりやり直したりされても、元に戻す、およびやり直し操作の対象にはなりません。このメソッドを使用してドキュメント以外のデータを修正する場合は、DocumentChanged イベントを受信設定して、元のトランザクションが元に戻されたりやり直しされたりした場合に、データを更新する必要があります。
Execute()メソッドには、ドキュメントや更新をトリガした変更に関する情報などの更新を実行するのに必要なすべての必要データを提供する UpdaterData パラメータがあります。3 つの基本的なメソッド(GetAddedElementIds()、GetDeletedElementIds()、GetModifiedElementIds())は更新をトリガした要素を識別します。特定の変更が IsChangeTriggered()メソッドを使用して更新をトリガした場合は、更新プログラムも特別に確認できます。
次のメソッドは、要素間のクロスリファレンスを起こすため、更新プログラムの実行中は呼び出されない場合があります。(これらの変更がワークセットの操作で結合される場合は、これによってドキュメントが破損する場合があります)。更新プログラムがこれらのメソッドのいずれかを呼び出そうとすると、ForbiddenForDynamicUpdateException がスローされます。
上記の禁止されたメソッドに加えて、ドキュメントをトランザクションのない状態にする必要のある 他のAPI メソッドは、どれも呼び出されない場合があります。このようなメソッドには、Save()、SaveAs()、Close()、LoadFamily()などがありますが、これに限定されません。詳細については、それぞれのメソッドのマニュアルを参照してください。
更新プログラムの Execute()メソッド内からの RegistryUpdater()または AddTrigger()などの UpdaterRegistry クラスへの呼び出しも禁止されています。任意の UpdaterRegistry メソッドを呼び出すと、例外がスローされます。この規則の例外は、UpdaterRegistry.UnregisterUpdater()メソッドです。これは、登録を解除される更新プログラムが現在実行中でない限り、更新プログラムの実行中に呼び出される場合があります。
次のメソッドは更新プログラムの実行中に許可されていますが、要素間のクロスリファレンスが呼び出しの結果として確立されると ForbiddenForDynamicUpdateException をスローできます。このような一例として、既存の壁面と交差する壁面の作成が挙げられます。これら 2 つは結合される必要があります。これらのメソッドを更新プログラムから呼び出す場合は注意が必要です。
また、既存の要素の修正で十分な場合は、要素を削除、再作成しないように注意してください。要素の削除は簡単な解決策ですが、Revit のパフォーマンスに影響を与えるだけでなく、その他の要素から「再作成された」オブジェクトへの参照を破棄してしまいます。これにより、問題となっている要素に付けた拘束や注釈が失われる場合があります。
更新プログラムは、これを使用することにより生じる可能性のある複雑な問題に、後に要素に加えられた変更を調整するなどして対処できる必要があります。更新プログラムによって修正された要素は、更新プログラムが次に起動されるまでに変更される場合があり、これらの変更は更新プログラムによって修正された情報に影響を与える場合があります。たとえば、要素はユーザが明示的に編集する、または再生成によってトリガされた変更が拡大されたために黙示的に編集される場合があります。
同じ要素を別の更新プログラムによって、同じトランザクションで修正する場合もあります。まったく同じデータの明示的な変更は、追跡され、禁止されていますが、間接的および変更の拡大は可能です。最も複雑な場合は、ユーザと、ファイルの別バージョンの同じ更新プログラムの両方またはいずれかで、要素を変更できる場合です。ユーザが最新版を再ロードする、または中央ファイルに保存した後、修正されたターゲット要素は他のファイルから読み込まれ、更新プログラムは変更を調整する必要があります。
ドキュメントが中央ファイルと同期した場合、要素の ElementId が影響を受ける場合があることを理解しておくことも重要です。新しい要素が同じファイルの 2 つのバージョンに追加され、同じ ElementId が両方で使用される場合は、ファイルが中央データベースに同期されると ElementId が調整されます。この理由から、別の要素に存在するある要素をクロスリファレンスするために更新プログラムを使用する場合は、一意であると保証された Element.UniqueId を使用する必要があります。
考慮すべきもう 1 つの問題は、更新プログラムがいくつかのデータを(パラメータとして)要素にアタッチする場合は、追加される要素の情報を保持するだけでなく、コピー/貼り付けやグループの拡大によってその要素が複製される場合に、データを調整する必要があることです。たとえば、更新プログラムがパラメータ「鉄筋の総重量」を鉄筋ホストに追加する場合、鉄筋自体がホストでコピーされない場合でも、そのパラメータと値は複製された鉄筋ホストにコピーされます。この場合、更新プログラムは、パラメータ値が新しくコピーされた鉄筋ホストでリセットされることを確認する必要があります。