Share
 
 

Handling Hard References to AcDbEntities During wblockClone(): CASE 2

The previous example will only work when the reference is in an entity, and that entity is always in the same block table record as the referenced entity. Because they are in the same block table record, the setting of isPrimary for the referring entity will also be valid for the referenced entity. However, if the referenced entity can exist in a different block table record, or if the referring entity is an AcDbObject, you must use other means to determine if appending should be done.

First, you will need to check the WBLOCK notification to determine which type of WBLOCK is occurring, probably by setting a global flag that can then be queried by your wblockClone() function:

  • If it is a WBLOCK*, do not use AcDbBlockTableRecord::appendAcDbEntity() in the custom class's override of wblockClone(), during callbacks, or in any other place.
  • If it is a WBLOCK of a user-defined block, it may depend on where the referenced entity currently exists. First, remember that the selected block is getting exploded into model space of the destination drawing. You may want to define this behavior in some other way, but a couple scenarios may be as follows: 1) always clone the referenced entities into model space as well. In this case, you would always set isPrimary to Adesk::kTrue, or, 2) check the current location of the referenced entity. If it is in model space or paper space, clone it to the corresponding space and set isPrimary to Adesk::kTrue. If it is in the selected block, also clone it to model space. If it is in some other user-defined block, then call wblockClone() on that block record. Just be sure that you do not try to clone the selected block. In this case, the block table record will take care of cloning your referenced entity.
  • If it is a WBLOCK of a selection set, only reset isPrimary to Adesk::kTrue if the referenced entity is going into model space or paper space. If it is in a user-defined block, call wblockClone() on that AcDbBlockTableRecord, instead of on your referenced entity.

Finally, it should be noted that setting up a hard reference to an AcDbEntity is not currently supported by the AcDbProxyObject system, even if you use an AcDbHardPointerId for the reference. AcDbProxyObject uses the default wblockClone() implementation, and thus will not do the append of any referenced entities during either form of WBLOCK. If a WBLOCK happens when your entities are proxies, the references will get cloned, but without the append they will be ownerless and are not persistent. The result is that when the wblocked drawing gets loaded, your reference ID will be NULL, and the referenced entity will be missing. You must code your custom object to handle this situation gracefully.

Was this information helpful?