- UID
- 1
- 积分
- 15891
- 精华
- 贡献
-
- 威望
-
- 活跃度
-
- D豆
-
- 在线时间
- 小时
- 注册时间
- 2002-1-3
- 最后登录
- 1970-1-1
|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有账号?立即注册
×
HOW TO RETAIN THE XREFS OF AN INSERTED SOURCE DRAWING
Product AUTOCAD Author BOLAN,SHAWN
Date 26-MAY-99 Document ID 34804
Expiration date Attachments
Keywords API_R13_BAD; API_R14_OK; API_TAHOE_OK; ARX; OBJECTARX
Developer Consulting Group technical solution. Autodesk confidential, for ADN members only. Please read the disclaimer
Question
I am copying a number of drawings into the one drawing using wblock/insert,
similar to the actions taken in the clones sample function, clone3().
However, if the drawing being copied has an external reference in it, it is
not correctly copied. How do I carry the XREF over into the target drawing?
Answer
Some side effects occur when a source drawing with XREFs is inserted into a
target drawing. This behavior is not confined to the ObjectARX API only. It
can be replicated in AutoCAD by performing the following steps:
1) Create a drawing which contains an XRef,
2) Save it,
3) Create a new drawing,
4) Use the "Insert" command and insert the previously created drawing in the
actual one.
AcDbDatabase::insert(pDb) on a source database with a XREF attached results
in a target database that contains a block table record with the name of the
XREF. But, the BTR contains an extraneous AcDbText entity in place of
entities contained in the XREF's modelspace. This AcDbText entity therefore
holds no useful info on tracing where the original XREF resides nor what the
drawing contains.
If the source contains an overlaid XREF, a different behavior occurs upon an
ARX insert: The target contains a block table record with the same name for
the XREF, but the record is empty - no entities whatsoever.
So in ObjectARX, if you want to retain the XREF's intact, you basically need
to bind them to their containing database before issuing an insert so that
the target database won't drop or mutate them. Once inserted into the target
database, former XREF blocks will appear as regular block table records, but
with the crucial distinction of a pathname citing the drawing from which the
binding occurred. In other words, unlike a basic block table record, a call
to AcDbBlockTableRecord::pathName() will not return NULL even though XREF
status shows "kXrfNotAnXref". Gleaning the XREF pathnames from the target
database's block records, you should be able to restore XREF connections via
AutoCAD XREF-Attach. Of course, this also entail cleanup because you'll have
to erase the unresolved XREF block table records that were initially inserted
into the target. Therefore, it's easier just to leave the bound XREFs
untouched in the target DWG.
void copyDBIn() {
AcDbBlockTable *pBlockTable;
AcDbDatabase *pDb = acdbHostApplicationServices()->workingDatabase();
pDb->getBlockTable(pBlockTable,AcDb::kForRead);
// We have to iterate through the block table and look for XREF's: //
AcDbBlockTableIterator* pIterator;
AcDbBlockTableRecord *pBlockTableRec;
pBlockTable->newIterator( pIterator );
AcDbBlockTable *pDestBlockTable;
AcDbBlockTableRecord *pDestBlockTableRec;
// Will convert attached XREFs into AcDbText and overlaid XREFs are
dropped
// finalDB->insert(*matr, pDb, Adesk::kTrue);
AcDbDatabase *xrefDB;
AcDbObjectId newXrefBlockId;
for (pIterator->start(); !pIterator->done(); pIterator->step()) {
Acad::ErrorStatus es = pIterator->getRecord( pBlockTableRec,
AcDb::kForRead );
// Is it an XREF?
if ( pBlockTableRec->isFromExternalReference() ==
Adesk::kTrue ||
pBlockTableRec->isFromOverlayReference() ==
Adesk::kTrue ) {
AcDbObjectId recordId;
char *xrefBlockName;
pBlockTableRec->getName(xrefBlockName);
pBlockTableRec->close();
if ( RTNORM != ads_command( RTSTR, "_.-XREF", RTSTR,
"_BIND", RTSTR,
xrefBlockName, RTNONE )) {
delete [] xrefBlockName;
return;
}
delete [] xrefBlockName;
}
}
pBlockTable->close();
AcGeMatrix3d *matr= new AcGeMatrix3d();
AcDbDatabase *finalDB = new AcDbDatabase();
finalDB->insert(*matr, pDb);
finalDB->saveAs("target.dwg");
delete matr;
delete finalDB;
} |
|