I never noticed this before... Dimension entities used in Blocks

Sort of strange, but I think I like it.

Can someone verify/explain this? (I am using ADT 2004, btw)

Use MBLOCK to create a block which contains some dimension entities.
Make sure to RETAIN the original objects.

Now INSERT the new block a few times.

Now go back and edit/move those original dimension entities.

Do the dimensions in block inserts update automatically when you do this?
(IOW, WITHOUT taking any further steps to redefine the block)

The original dimensions seem to work kind of like a live "interior xref"

Is this just a serendipitous feature or by design?

Can anyone think of some useful ways to use this behavior?

 

I could be wrong, but I think it is due to the fact that the dims in
question share the same "dim block" (each dim stores it's data in a block)

 

not sure i like it.

yup, happens in LDDT5 too. dimassoc set to 1 or 2 (that surprised me).

not off hand, it makes me nervous.

 

Oh, c'mon, Doug.

Yeah, I can see where it might lead to problems - but then again...

In my 'eureka' case, I'm using the dimension to represent a header beam in
an apartment unit "wall block", which is then inserted several places on the
plan. I haven't tried this yet, but if I should find that the dimension
text is not optimally placed with respects to the framing (for example, if I
would like the text to be below the line rather than above), I'm
thinking/hoping that all I may need to do is edit the original dimension's
text to be below and - voila! - instant block update...

At least, that's one possibility.

I haven't tried this either, but I'm ass-u-ming that if the original
dimension object is deleted, the dimension subentities in the block are NOT
deleted, but just become 'static' until a deliberate/forced redefinition.
Yes? No?

Just something sort of different.

Perhaps someone can find more elegant uses for this behavior?

Best regards,
David Kozina

 

i dimension a building footprint "bldg a", create a block with the described
method and place it in a subdivision 10 different places.

time for "bldg b" that is similar enough to "a" that i just stretch a few
things around in the original geometry and make a new block.

oh no, dimension in "bldg a" is now kaputt.

fortunately, i'm pretty sure i haven't done aything in this exact fashion,
but durn! , i could get burned here.

thanks for the heads-up anyhow!

 

Well, in the case you describe, if you COPY the original geometry so as to
create a new building type (which I would do so as to have both types
available), then create the new block from of the copied entities, there
shouldn't be any problems. But I understand the scenario you describe.

BTW, I tried the text adjustment thing and the delete thing and the results
were as expected. Text was adjusted. Block dimensions became 'static'.

Glad you found the info useful, anyways.

 

as would I, normally.........

the potential catastrophy lies in the practice here of often suppressing
dimension and extension lines on bldg footprints for clarity. if the value
where to change via this scenario, it wouldn't be immediately evident.

i'm concerned enough to submit a bug report (i got the form bookmarked with
auto-entry for most of the fields) to see what adesk thinks about it.

be careful about getting attached to back-door "features" like this. they
may disappear on the next release, but then you probably already knew that.

 

David,
Thanks for the notice. It seems entirely consistent with
block definition. Grip editing dimensions is like refediting
normal blocks. Since the graphical components of dimensions
are represented by an associated block, other blocks that
nest those dimension blocks are bound to change.

It is no different than refediting another nested block. Try
it. Make a block definition. Insert it. Make a copy.
Nest it into another block definition. Insert that copy. Now
refedit the first copy and regenerate the drawing. Same
behavior.

This is certainly NOT a bug.

Regards,
Doug

 

it is a bug

because the DIMENSION in *Model_Space has a different properties than the
one in the block definition they should have a different '(...(2 .
"*DXXX")...) value

to demonstrate the behavior, you don't need to define a block at all.

create a dimension, and run:

(setq anon_block_name (assoc 2(entget(car(entsel"select first dimension:
")))))

create a second dimension and run:

(setq elist(entget(car(entsel"select second dimension: "))))(entmod(subst
anon_block_name(assoc 2 elist)elist))(command"._REGEN")

the second dimension would take on the appearance of the first one except
that entmod'ing it updates the anonymous block definition so the first one
now looks like the second one. there are actually two there that coincide
graphically, their grips remain where they are supposed to be. both
dimensions look like the last one modified, you will only see one dimension.

because one dimension could be in model space and the other in paper space
you may find some benefit. even though audit doesn't fix the problem i
still wouldn't rely on the behavior

 

Perhaps this is a really dumb idea, but in the project du jour I'm finding
it would really be cool if AutoCAD HAD an *automatically updating* BLOCK
capability, not unlike the dimension in a block behavior. And I'm not
talking about FIELDS.

The way I would envision it, when block geometry is RETAINED during BMAKE,
perhaps an additional checkbox could become activated to allow the original
geometry to be 'live-linked' to the block definition. If the retained
geometry is edited, the block would update automatically. IOW, an xref
without the external file.

XREFS are great, but sometimes they're just more than you need.

Any thoughts on this?

Would've sure saved me some time today...
(I'll be kicking myself if this already exists.)

Best regards,
David Kozina

 

mataeux,

The drawings you've posted are quite fascinating and imaginative, to say the
least.
Thanks for sharing them!

Perhaps I'm missing the point, but I don't understand why we should be
calling the 'recursive' dimension arrowhead you've created here a 'bug',
since the program is simply trying to do *exactly* what you're telling it to
do. No?

I generally find this sort of obedience *desirable* in software, since the
problems that may arise are then simply my own doing. I may not be happy
about it, but I've got no one to blame but myself.

Best regards,
David Kozina