Properties of exploded dimensions

Wiebe van der Worp

With default settings for dimensions "byblock" and text "white"...

When I explode a block with "byblock" parts , all resulting objects are "byblock" as expected.

When I explode a dimension, all resulting objects get colour "bylayer" instead of "byblock" and "white". This is not what I expected. Is there a reasoning behind this behaviour?

Michael Mayer

Hmmh,
not experienced with Autocad at all.
But when I think about that from outside ...

1. Basics
   When a Block Instance in the drawing gets exploded
   (and so separated from the Block Definition)
   it does no more make sense anymore to have Attributes "by Block"

If Elements don't have any "by Element" information available,
in my understanding they should switch to "by Layer".

And if you want to use the Elements again in an other or existing Block,
I think it is ok to need to manually set them back to "by Block".

2.
Or is there another Autocad complexity in a "by Block" setting, so that
it will work in "by Layer" Mode, as long as there is no dictating Block
available ?

3.
Or do you think about nested Blocks,
where you explode an Child Block in a Container Block and want to
have the Elements to now inherit the Attributes from the parent
Container Block ?
Which I think is also a bit questionable in an environment where
you try to control everything specific by non-by Element definitions.
I think it is quite arbitrary that the Attribute Definitions accidentally
match the desired Attributes for those elements (?)

TL;DR;
I think the Dimensions behavior after being exploded makes more sense ....

BTW
The Color White,
as an explicit "by Element" setting,
should be kept of course !

Wiebe van der Worp

ad 1: If a block is exploded with explode, one should expect it to become the building stones of the compound block. When properties are to be influenced, there is command xplode. I don't think it is a good idea that the program tries to be smarter than me ;-)

ad 2: That was what I am looking for: Is there another reason to make the colour of resulting objects, after exploding a dimension, "bylayer" instead of "byblock"?

ad 3: I've checked attributes too, exploding them works as expected. Basically, colour, not only white (7), also 0 (byblock) and 256 (bylayer), should not be changed by exploding.

ad ad 1: It is easy to check the applied settings of a dimension:

• Create a dimension
• Put it on layer "red" (which has colour red off course)
• Change the colour of the dimension to blue
  When the dimension turns out blue, you can be sure that the blue dimension parts are coloured "byblock".

Michael Mayer

ad 1: If a block is exploded with explode, one should expect it to become the building stones of the compound block. When properties are to be influenced, there is command xplode.

Uh,
wasn't aware or even expected something like that ...

I don't think it is a good idea that the program tries to be smarter than me ;-)

For me they try that all the time, not totally unsuccessful
That is why I prefer dumb Apps with strict simple rules over those with
overly complex rule excepitions.

ad ad 1 ... * Change the colour of the dimension to blue

• When the dimension turns out blue, you can be sure that the blue dimension parts are coloured "byblock".

I don't understand that at all.
(I think I would get it if it would be : Change the colour "Layer" of the
dimension to " a blue Layer ....)

Where I come from there was no "by Block".
(Such an option only applied to BIM Plugin Objects like Walls, Windows or such)
Just manual explicit "by Object" settings or inherit "by Layer" Settings.
A Block Definition was exactly a Block. And all Instances are 100% 1:1 Copies
of that Block and identical. No exceptions (no cry)

Wiebe van der Worp

Ha! Now I understand why I had some trouble trying to figure out your post.

Sometimes there is the problem of not being able to change properties like colour of a block. The underlying cause is the way the objects of the block are defined. It is a complex topic. But jumping to two general conclusions is easy:

• When defining blocks: Take care that all relevant properties are "byblock" and on layer 0 - unless you know what you are doing.
• Layer 0 is special, it behaves like a chameleon

Attached is a screen dump where you can see what the consequences are...

Michael Mayer

OMG

Thanks Wiebe,
What were they thinking when they invented Blocks ?
Were all these features and complexity on their list of what
Blocks should be able to do. Or did they start with a simple Block
and couldn't resist of implementing any single user request into
it over the last century.

"byblock" and on layer 0 - unless you know what you are doing.

I am no more sure if I know anything Block-ish anymore.
But the only way I can keep control of and manage my Projects is by
strictly controlling Attributes by Layer without (nearly) any exception.
(And/or by Styles and Compositions in BIM)
Even if that needs some 5 extra Layer "Duplicates".

So same for my Objects in my Blocks.
If one needs to differ, it needs a modified Duplicate of that Block.
I think I should keep my strict rules in my case.

(Or an Anonymous Block ... arrrrgh ... in that case)
Or better just a Group or even loose Elements on different Layers,
... by Layer.

But for your problem,
(even if I may still think those features are completely wrong )
I think such Attribute Magic should clearly work in the same way for all Objects,
no matter if Geometry, Text or Dimensions.

I think this is worth a Support Request.
Either something that may not work as designed or listed,
or someone who can explain what deeper logic is behind the way it is.

(Otherwise it would be totally unpredictable, even for those who
are able to manage and need that complexity ?)