AcDbBlockTableRecord::appendAcDbEntity() requires valid AcDbObjectIds in order to do the append properly. During cloning, an entity may be appended to an AcDbBlockTableRecord only if AcDbBlockTableRecord::isObjectIdsInFlux() returns Adesk::kFalse. This indicates that the AcDbBlockTableRecord itself is not currently being cloned. The one exception to this rule occurs when the cloned AcDbBlockTableRecord is empty. Because an empty AcDbBlockTableRecord contains no untranslated AcDbObjectIds, the append will work properly. This situation arises during some forms of wblock(), and is described in more detail shortly.
If deep cloning is being called on individual entities, then their clones must be appended to the destination AcDbBlockTableRecord. However, when the AcDbBlockTableRecord itself is being deep cloned, then all its entities are cloned with it, and a call to AcDbBlockTableRecord::appendAcDbEntity() will not only be unnecessary, but would corrupt the cloned
AcDbBlockTableRecord.
Default implementations of deepClone() and wblockClone() know when to call AcDbBlockTableRecord::appendAcDbEntity() by checking the isPrimary value. When an entity is being deep cloned by itself, isPrimary is true, and append is called. If the entity is being cloned as the result of a deep cloning of an AcDbBlockTableRecord, then isPrimary is false, and append is not called.
Normally, applications do not need to be concerned with this detail and can rely on the default implementation of deepClone() and wblockClone() to handle entities. However, situations can arise when applications may want to add entities during cloning, or use hard references to entities. The hard referenced entity will have an isPrimary value of Adesk::kFalse and will not call append, even when it may need to do so. This situation is covered in the next section.
The following rules illustrate important aspects of cloning.