Xrecord Objects

The xrecord object is a built-in object class with a DXF name of “XRECORD”, which stores and manages arbitrary data streams, represented externally as a result-buffer list composed of DXF groups with “normal object” groups (that is, non-xdata group codes), ranging from 1 through 369.

Xrecord objects are generic objects intended for use by ObjectARX and AutoLISP applications. This class allows applications to create and store arbitrary object structures of arbitrary result-buffer lists of non-graphical information completely separate from entities. The root owner for all application-defined objects is either the named object dictionary, which accepts any AcDbObject type as an entry, including AcDbXrecord, or the extension dictionary of any object.

Applications are expected to use unique entry names in the named object dictionary. The logic of using a named object dictionary or extension dictionary entry name is similar to that of a REGAPP name. In fact, REGAPP names are perfect for use as entry names when appending application-defined objects to the database or a particular object.

The use of xrecord objects represents a substantial streamlining with respect to the current practice of assigning xdata to entities. Because an xrecord object does not need to be linked with an entity, you no longer need to create dummy entities (dummy entities were often used to provide more room for xdata), or entities on frozen layers.

Applications can use xrecord objects to do the following:

• Protect information from indiscriminate purging or thawing of layers, which is always a threat to nongraphical information stored in xdata.
• Utilize the object ownership/pointer reference fields (330–369) to maintain internal database object references. Arbitrary handle values are completely exempt from the object ID translation mechanics. This is opposed to 1005 xdata groups, which are translated in some cases but not in others.
• Remain unaffected by the 16K per object xdata capacity limit. This object can also be used instead of xdata on specific entities and objects, if one so wishes, with the understanding that no matter where you store xrecord objects, they have no built-in size limit, other than the limit of 2 GB imposed by signed 32-bit integer range.

  In the case of object-specific state, xrecord objects are well suited for storing larger amounts of stored information, while xdata is better suited for smaller amounts of data.

When building up a hierarchy of xrecord objects (adding ownership or pointer reference to an object), that object must already exist in the database, and, thus, have a legitimate entity name. Because acdbEntMake() does not return an entity name, and acdbEntLast() only recognizes graphical objects, you must use acdbEntMakeX() if you are referencing nongraphical objects.

The acdbEntMakeX() function returns the entity name of the object added to the database (either graphical or nongraphical). If the object being created is an entity or a symbol table record, then acdbEntMakeX() will behave the same as acdbEntMake() (in other words, it will create the object and establish the object's ownership). For all other object types, acdbEntMakeX() appends the object to the database, but does not establish ownership.