2016-06-18 29 views
0

私は実際の技術プログラミングよりも「ベストプラクティス」の理論が多​​いです。Revit API作成後の要素の編集

私はそれは私のプログラムで配置された後の要素を編集処理するための最善の方法を考えるようにしようとしています。

ユーザーは、本質的にRevitで、「プロジェクトにいくつかの家族を追加」ツールをクリック:具体的に私は次のように私のプログラムを設定しています。ユーザーが作成したスケッチを読み込み、スケッチに基づいてアイテムを配置します。

Sketch

Element creation

私は、ユーザーに床スラブを言うのに似て、それらの要素の「スケッチを編集」する能力を与えたいです。私はRevit APIが「スケッチモード」を使ってスケッチを行う能力を公開しているとは思っていません。私は私のプログラムでこの非常に有用な機能を模倣しようとしています。

だから、私がやったことは、拡張可能なストレージを使用して、私のツールを使用して作成されたすべての要素にユニークIDを格納しています。プログラムが行うことは、ユーザーが「要素の編集」ツールをクリックし、新しいスケッチを求め、既存の要素をクリックし、既存の要素のUniqueIdを読み取り、そのUniqueIdを持つすべての要素を呼び出して削除したときです。プログラムは、ユーザの新しいスケッチを使用して、プロジェクトに新しい要素を再度追加します。

問題は、ユーザーがプロジェクトに追加された元の要素を削除して編集しようとした場合、UniqueIdを持つ元の要素を削除しないようにするにはどうすればよいですか?私は、Revit APIでDynamic Model Update機能を使用する方法があると思います。

これらのアルゴリズムのほとんどはどのように記述されていますか?私は正しい道にここにいますか?私はUniqueIdsを要素に割り当てて要素自体に格納するので、後でそれらを呼び出すことはできますか?多分私が紛失しているパズルの基本的な理論的な部分があります。データ構造

答えて

0

あなたは本質的に正しい軌道にいると思います。 UniqueIDをを保存するために拡張可能なストレージを使用した

は間違いなく行く方法であり、また、変更に対応するためにDMU動的モデルアップデータ機能を使用するといいですね。不明瞭であるように思わ

一つのことは、彼らが作成されるときにRevitが自動的に要素に固有のIDを割り当てます、そしてあなたがそれに影響を与えるためにできることは何もない事実です。ユニークなIDは一意で不変です。あなたはそれを制御できません。

したがって、最も簡単なアプローチは、以前のすべてのスケッチ要素を削除し、スケッチ全体を再作成し、スケッチを何らかの方法で変更する必要があるときはいつでもスケッチを定義するすべての要素をゼロから作成することです。

+0

お返事ありがとうございます。物事をクリアするために、私は拡張可能なストレージを使い、単一のuniqueidを作成しており、そのスケッチに属するすべての要素に適用されます。したがって、スケッチを編集するとき、ソフトウェアはそのスキーマとエンティティ内のフィールドに割り当てられたubique IDを検索します。私が持っているその独特のものは支配している。 また、多くのRevit APIヘルプ記事を読んだ後、私はあるプロジェクトから別のプロジェクトに要素をコピーすることができ、IDは一意にとどまるので、固有の印象を受けていました。 Maxence、あなたはこれがelementidsで起こると言っていますか? – pirit4

+0

拡張ストレージに格納された要素IDを使用すると、revitはリレーションシップの変換をインテリジェントに処理します。http://thebuildingcoder.typepad.com/blog/2011/06/extensible-storage-features.html#7 –

0

ワークシェアリングの更新が発生したときにELEMENTIDが自動的に新しいELEMENTIDに再マッピングされているのであなたは、構造化ストレージのためELEMENTIDの代わりにユニークIDを使用する必要があります。 ElementIdは、要素が削除されると、ElementId.InvalidElementIdに設定されます。

+0

同意する!それを指摘してくれてありがとう!ここには注釈があります:http://thebuildingcoder.typepad.com/blog/2011/06/extensible-storage-features.html#7 –

関連する問題