yang686526

grouping in svg based on block hierarchy
grouping in svg based on block hierarchy
hi,
while exporting from dwg to svg, in case of multiple references of a block, is the order of processing of each reference of the block is same as the order in which the references are present in acdbblocktablerecord?
for example, if block "test" is inserted at two different locations, the block table record would be as shown below:
acdbblocktablerecord
2
test
340
0
102
{blkrefs
331
17a
331
182
102
}
17a is the handle of the first instance and 182 is the handle of the second instance of the block. can we "always" assume that during svg processing, 17a would be processed prior to 182 (the order in which they appear in the acdbblocktablerecord)?
no. the order of processing block references does not depend on blrrefs list.
it depends on the order of block references in active layout. some of references may be not processed at all if they are not in active layout. also block references can be nested.
for example active layout contains:
reference to block a
reference to block b at this moment where is only one reference to b (1).
block a is edited and another one reference to b (2) is inserted into a.
while procesing layout the second nested reference to b will be processed first as part of processing block a.
sergey slezkin
hi slezkin,
thanks for the reply.
we are facing problem while trying to retrieve the actual block handle when processing dwg for svg output, in the odgiconveyorgeometry overrides (like circleproc, polygonout etc..) in the case of multiple references of a block.
we are able to get the block table record using the following lines of code in the overrides:
const odgidrawabledesc* pdesc = drawcontext()->currentdrawabledesc();
oddbentityptr pent = oddbentity::cast( oddbobjectid( pdesc->persistid ).safeopenobject(oddb::kforread) );
oddbblocktablerecordptr l_oddbblocktablerecordptr = pent->blockid().safeopenobject();
in case of multiple references, this block table record contains handles for all the references. is there a way to retrieve the current reference handle of the block each time an entity is being processed for each reference?

hi,
for example, you can use pparent member of odgidrawabledesc structure in this case:
if you has, for example, drawing, which contains two block references with block, containing one circle, and one helix in model space, you will get following stack in odgidrawabledesc:
block table record (*modelspace)
block table record (*modelspace) --> block reference (1)
block table record (*modelspace) --> block reference (1) --> block table record
block table record (*modelspace) --> block reference (1) --> block table record -->circle entity
block table record (*modelspace) --> block reference (2)
block table record (*modelspace) --> block reference (2) --> block table record
block table record (*modelspace) --> block reference (2) --> block table record -->circle entity
block table record (*modelspace) --> helix entity
, so, if you will use safe casting of pparent you can get block references like this:
code:
oddbblockreferenceptr pbr;
const odgidrawabledesc* pdesc = drawcontext()->currentdrawabledesc();
if (pdesc->pparent != null)
{
oddbblocktablerecordptr pbtr = oddbblocktablerecord::cast(oddbobjectid(pdesc->pparent->persistid).safeopenobject(oddb::kforread));
if (!pbtr.isnull() && pdesc->pparent->pparent)
{
pbr = oddbblockreference::cast(oddbobjectid(pdesc->pparent->pparent->persistid).safeopenobject(oddb::kforread));
}
}
if (pbr.isnull())
{
// no block reference for this entity found
}
else
{
// pbr.id()
hi mark,
thank you very much and the method you suggested is working.
last edited by tanuja.padhi@patni.com; 17th march 2009 at 01:30 amfff">.