Topic: Purge vs Wblock

[Jeff H]

To clean up a drawing Wblocking the entire drawing seems to clean it up better than all the purging I can do to it.
Things I find with using a database explorer that purge misses seem to usullay be taken care with wblock.
 
Has anyone had problems or 'gotchas' with Wblocking a entire drawing for cleaning it up?

[BlackBox]

No issues at all; WBLOCK has greatly helped us simplify cleaning up problem drawings for the reasons you state (i.e., cleaning up better than purge, etc.).

[dgorsman]

If thats WBLOCK with a manual selection of on-screen elements, no problems.  WBLOCK -> ALL grabs things like blocks with only invisible attributes, attributes with no contents, isolated objects.

They don't get used a lot, but might want to check to see if GROUP'd objects stay grouped.

[Jeff H]

If thats WBLOCK with a manual selection of on-screen elements, no problems.  WBLOCK -> ALL grabs things like blocks with only invisible attributes, attributes with no contents, isolated objects.

They don't get used a lot, but might want to check to see if GROUP'd objects stay grouped.

Would need to check if any layers are locked if you wanted entites on locked layers to be included.

[Crank]

I'm using xdata that contain handles. The WBLOCK command would assign new handles to the objects, so my xdata would become useless.

[Cathy]

Crank, I'm pretty sure that if you have the XData labeled as a Handle that it will get updated automatically.  That is, that the Xdata would be changed to contain the new handle. 

[Jeff H]

But if you have a handle say '61D' stored in a database or wherever and now it gets changed to '683' that most definitely would cause some problems, but if Crank were ever to send me or someone drawings he would not have 3MB+ of useless crap that is copied and pasted from all over and never used, so would not be a problem.
 
Not familiar with Lisp but would store ObjectID's as hard pointers for objects in same drawing to reference each other so they would update to point to each other after clone operations.

[dgorsman]

I'm using xdata that contain handles. The WBLOCK command would assign new handles to the objects, so my xdata would become useless.

I think 1005-coded references get translated automatically, whereas other types such as a plain text would not be.  Thats assuming the object references are referring to what got WBLOCK'd out.  If the referenced objects were not in the WBLOCK selection I'm not sure what would happen to the references.

[Jeff H]

There are four versions of AcDbDatabase::wblock():
WBLOCK*
 

Acad::ErrorStatus AcDbDatabase::wblock( AcDbDatabase*& pOutputDatabase); 

WBLOCK of a user-defined block
 

Acad::ErrorStatus AcDbDatabase::wblock( AcDbDatabase*& pOutputDatabase, AcDbObjectId nObjId); 

WBLOCK of a selection set
 

Acad::ErrorStatus AcDbDatabase::wblock( AcDbDatabase*& pOutputDatabase, const AcDbObjectIdArray& pIdSet, const AcGePoint3d& pPoint3d); Acad::ErrorStatus AcDbDatabase::wblock( AcDbDatabase* pOutputDb, const AcDbObjectIdArray& outObjIds, const AcGePoint3d& basePoint, AcDb::DuplicateRecordCloning drc); 

One of the main internal differences between these versions of wblock is their treatment of the model space and paper space AcDbBlockTableRecords. Because the entire database is being cloned in version one, all the entities in model space and paper space are cloned along with their containing paper and model space AcDbBlockTableRecords. However, in the other versions, the intent is to clone only a selected set of entities. Although the model space and paper space AcDbBlockTableRecords are processed, these use a “shallow clone,” which does not in turn clone all the entities contained in model space and paper space.
Even though the model space and paper space blocks have been cloned in versions two and three, they are empty. Therefore, it is not only acceptable to call AcDbBlockTableRecord::appendAcDbEntity() to place the cloned entities into them, it is necessary to do so. (This is the exception to using AcDbBlocKTableRecord::appendAcDbEntity() on AcDbBlockTableRecords, whose IDs are in flux). Also, in both versions two and three, the entities will have isPrimary set to Adesk::kTrue when they get their wblockClone() call. This is because the internal code individually clones the entities of the selection set, or the entities of the selected AcDbBlockTableRecord. It does not clone the AcDbBlockTableRecord itself. (Entities in nested blocks, however, will still have isPrimary set to Adesk::kFalse). This behavior is useful, as will be seen in the next section, in Case 1. It saves applications from having to know what type of WBLOCK operation is occurring.
Here are some more rules to keep in mind:

• Never use AcDbBlocKTableRecord::appendAcDbEntity() during WBLOCK*. If you must create new entities, you must keep them in memory, along with their future owner's ID, and then append them after AcEdItorReactor::endDeepClone(). This also applies to appending objects to AcDbDictionaries, polylines, polyfacemeshes, polygonmeshes, and block references.
• In the other forms of WBLOCK, only use AcDbBlocKTableRecord::appendAcDbEntity() when appending to model space or paper space. But with that exception, all the other restrictions mentioned for WBLOCK* still apply.

[Crank]

Crank, I'm pretty sure that if you have the XData labeled as a Handle that it will get updated automatically.  That is, that the Xdata would be changed to contain the new handle.

Thanks Cathy,

After a small test I think you could be right about this.

[M-dub]

One other thing you might want to remember would be any variables set (and saved) in the original drawing.

I was trying to find a list of the variables which are saved in the drawing vs the variables saved in the registry.  Didn't really find "IT" but this should be close, I think.

Unit format and precision
Title blocks and borders
Layer names
Snap and Grid spacing
Text styles
Dimension styles
Multileader styles
Table styles
Linetypes
Lineweights
Layouts
Page setups