Revit API 2012: Extensible Storage – Revit Element Data Extension

The Revit API 2012 provides an official way to extend the Element data now. In the old days, we could only create some cumbersome invisible parameters and attach them to the elements where we want to store some extra data. Now the Extensible Storage API can directly address so basic a need for us and has much power.

However, as introduced and demonstrated before, unnecessary complexities, impositions, redundancies and inconsistencies are here and there. In case any of those points as mentioned repeatedly in early posts slips out of our minds, the data storage or retrieval would just fail. In addition, the out-of-box supported data types are just a few, far less than enough.

Things become super easy and cool with the Revit Data Operator. Better, with the Revit Element Data Extension, things will be more convenient and natural.

Here is the Revit Element Data Extension:

using System;
using System.Xml.Serialization;
using System.IO;

using Autodesk.Revit.DB;
using Autodesk.Revit.DB.ExtensibleStorage;  //Revit API 2012 only

namespace RevitAddinWizard
{
    public static class ElementDataExtension
    {
        private const string SingleStringFiledName = "SingleStringForAll";
        public static void SetData(this Element e, string id, object o)
        {
            SchemaBuilder sb = new SchemaBuilder(new Guid(id));
            sb.SetSchemaName(id.Replace("-", ""));
            FieldBuilder fb = sb.AddSimpleField(SingleStringFiledName, typeof(string));

            XmlSerializer xml = new XmlSerializer(o.GetType());
            using (StringWriter w = new StringWriter())
            {
                xml.Serialize(w, o);

                Entity ent = new Entity(sb.Finish());
                ent.Set<string>(SingleStringFiledName, w.ToString());
                e.SetEntity(ent);
            }
        }

        public static T GetData<T>(this Element e, string id)
        {
            Schema sch = Schema.Lookup(new Guid(id));
            string s = e.GetEntity(sch).Get<string>(SingleStringFiledName);

            XmlSerializer xml = new XmlSerializer(typeof(T));
            using (StringReader r = new StringReader(s))
            {
                return (T)xml.Deserialize(r);
            }
        }
    }
}

Here is a data class and the test code to write a sample data to a selected Element:

    public class MyData
    {
        public byte byteVar;
        public ushort ushortVar;
        public long longVar;
        public char charVar;
        public decimal decimalVar;
        public DateTime dateTimeVar;
    }

Reference picked = CachedUiApp.ActiveUIDocument.Selection.PickObject(ObjectType.Element, "Pick a window to attach our data");
using (Transaction trans = new Transaction(CachedDoc, "AttachDataTo"))
{
    trans.Start();

    MyData data = new MyData
    {
        byteVar = 255,
        charVar = 'a',
        ushortVar = 65535,
        longVar = 1234567890,
        decimalVar = 1.123456789123456789M,
        dateTimeVar = new DateTime(2012, 2, 14, 23, 59, 59)
    };
    CachedDoc.GetElement(picked).SetData("DA4AAE5A-4EE1-45A8-B3E8-F790C84CC44F", data);

    trans.Commit();
}

Here is the code to read back the data from the same Element:

Reference picked = CachedUiApp.ActiveUIDocument.Selection.PickObject(ObjectType.Element, "Pick the window having our data");
using (Transaction trans = new Transaction(CachedDoc, "ReadDataFrom"))
{
    trans.Start();

    MyData data = CachedDoc.GetElement(picked).GetData<MyData>("DA4AAE5A-4EE1-45A8-B3E8-F790C84CC44F");
    string str = string.Empty;
    FieldInfo[] propInfoArrary = typeof(MyData).GetFields();
    foreach (FieldInfo fi in propInfoArrary)
    {
        object obj = typeof(MyData).InvokeMember(fi.Name, BindingFlags.GetField, null, data, null);
        str += string.Format("{0} : {1}\n", fi.Name, obj == null ? string.Empty : obj.ToString());
    }
    MessageBox.Show(str, "MyData");

    trans.Commit();
}

If the above test code is put into an external command, we can happily verify that everything works just fine.
 
As can be seen, those complexities and impositions all go away. We do not have to specify the same schema GUIDs, scheme names, field names, data types, unit types repeatedly. We do not have to care about all those intermediate objects such as Schema, SchemaBuilder, Field, FieldBuilder, or Entity anymore either.

What we need to care about now are what we really want, the Element itself, the data object, and the Schema identifier. If they are consistent with each other, it will be very hard to make the data storage or retrieval fail.

Life is becoming easier and easier, cooler and cooler. Huh?

The Revit Addin Wizard (RevitAddinWizard) is going to provide a coder to help generate Extensible Storage code.

Comments

[Matthias]

Hi,

in the code to read back the data from the Element, a Transaction is used. I'm wondering if this is really neccessary. I dont see writing access to Revit.

I hope it is not neccessary, because starting a Transaction can be tricky in some cases,,,

[Spiderinnet]

Matthias, you are right the transaction may not be necessary for reading purpose. We can also skip transactions in help methods and only start one in external commands.