タスクの背景
たとえば、顧客に問題が発生しました。
- 1Cでモデル要素を構築します。
- 1Cでは、モデルのこれらの部分をコントラクトで使用します。たとえば、そのような要素がすでに構築されていること、およびそのような要素が計画されていることなどを示します。
- Navisworksでは、たとえばモデル要素をさまざまな色で表示することで、何らかの方法でこれを図面で見ることができます。 これを行うために、彼らは、数量化テーブル（テイクオフテーブル）から1Cにデータをコピーし、1Cからそれらをテイクオフテーブルに入れることができるNavisworks用のプラグインを作成しました。
また、1Cでは、契約で使用されるモデル要素（部屋）の色を変更することが想定されていました。
1Cでこれらの表形式のデータを変更した後、Navisworksはそれらが変更されたことを理解せず、更新する必要があることが判明しました。 したがって、プログラマーである私は彼にこれを伝える必要があります。
プログラマーの仕事
1Cとの交換後、TK_Itemテーブルのデータ、特にColorフィールドが変更されました。 表示された図面の色は、表に示されている色に合わせて調整する必要があります。
方法を探しています。 説明を掘ります。 関数を見つけます-
public void OverridePermanentColor(IEnumerable<ModelItem> items, Color color)
さて、選択したTK_Item要素に対応するモデル要素を見つける方法は別の話ですが、興味深い場合は別の機会に説明します。 しかし、誰がそれを必要とします-そして、彼はそれを理解します。 しかし、色によってすべてがより面白くなってきました。
まず、関数のパラメーターで指定された色はSystem.Drawing.Colorではなく、Autodesk.Navisworks.Api.Colorであり、そのブラックジャックと...でわかります。 まあ、それをさせてください、しかし彼はそのようなコンストラクタを持っています：
public static unsafe Color FromByteRGB(byte red, byte green, byte blue)
したがって、問題なく、Autodesk APIが必要な色を作成します。
（実際、私が最初に試すべきことは、選択したアイテムに対応する要素を見つけ、色を選択し、この色に設定することです。）
しかし。 このテーブルでは、フィールドColorにInt64型の1つの値があります。 そして、それをColorタイプのオブジェクトと比較する方法は不明です。
さらに、ドキュメントでもフォーラムでも、例でも、データベースにどのように記述されているかはわかりませんでした。
OK、実験的に掘ります。
Navisworksを使用して、数量化を開き、要素の色を変更します。 正直、きれいな赤で言ってください。
その後、プラグインを取得し、TK_Itemテーブルからデータをポンプで送り、テーブルに何があるかを確認します。
（幸いなことに、デバッグ用のプラグインはそのようなオプションを提供しました-データをダウンロードしてフォームに表示します。）
判明したのは、-65536です。
手順を数回繰り返し、結果をテキストファイルにまとめます。
| 役職 | 色 | 表の色の値 | テーブル内の色のバイナリ表現 |
|---|---|---|---|
| マーク上の壁タイプ1.1 0,000 | 赤 | -65536 | 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 0000 0000 0000 0000 |
| マークの上の壁タイプ1.2 0,000 | 緑色 | -16711936 | 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 0000 0000 1111 1111 0000 0000 |
| 壁タイプ2.1マークの上 0,000 | 青 | -16776961 | 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 0000 0000 0000 0000 1111 1111 |
| マークの下の壁タイプ0.1 0,000 | 赤= 16 | -15728640 | 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 0001 0000 0000 0000 0000 0000 |
| マークの下の壁タイプ0.2 0,000 | 赤= 17 | -15663104 | 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 0001 0001 0000 0000 0000 0000 |
| 標高の関係。 0,000 | 赤= 193緑= 32青= 74 | 12 656 714 | 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1100 0001 0010 0000 0100 1010 |
最初は、表の数値、特に正と負の値の存在に非常に驚きました。
コンポーネントR、G、Bの値を試したところ、これら3つのコンポーネントが数字の最後の3バイトで表示されることに気付きました。
しかし、それは奇妙です-なぜ上位バイトがゼロではなく単位で埋められているのですか？
ただし、それらが常に単位で満たされていると仮定すると、負の数の存在が説明を取得します。 上位バイトを入力するだけで、数値の符号が決まります。
しかし、常に負の数があるわけではありません！
そして、>>および<<関数がどのように機能するかを覚えていると、符号ビットを含む数字で上位ビットを愚かに埋めることができることに気付きました。 そして、最上位ビットは必要ないので、そこに何があってもかまいません。
それから質問は-何のために彼らは色のためにそんなに重要性を必要としたのですか？ すでに64ビットですか？ このデータが格納されているテーブルの構造を調べました。すべての整数にInt64を使用しています。 確かに、なぜ些細なことですか？
まとめ
表に記録されている色の値は、次のように取得されます。
Int64 dbColor = Rb<<16 + Gb<<8 + Bb;
逆変換-モデルの要素に使用される色へのテーブルの色-これを行います：
byte R = (byte)(dbColorValue >> 16 % 256); byte G = (byte)(dbColorValue >> 8 % 256); byte B = (byte) (dbColorValue % 256); var color = Autodesk.Navisworks.Api.Color.FromByteRGB(R, G, B);