Dimension inside block not updating?

Could someone explain to me why Dimension Objects stored inside blocks are not updating ?

Here’s a short video showing the issue.
Dim_History.3dm (2.1 MB)

Rhino 6 (6.34.21034.07002, 2021-02-03)
MacOS Catalina 10.15.7

Thank you in advance for any answer

Rodolfo Santos

Hi Rodolfo - I do not know what is expected there - I’ll see what I can find out.
@RodolfoSantos - it might be possible to make this work but it might not - the way blocks work, the connection between objects is lost - this is true of any objects connected by History.
RH-63012 Dimensions: maintain history in a block


Dear Pascal

Thank you for your answer.

Yesterday, during a live webinar, I had to face a real nightmare because of this ‘unpredictable’ behaviour.
I had decided to propose this strategy during the live webinar because it was working well the day before ?

What I would like to know is whether it’s supposed to work or not ?

In some circumstances, using dimensions is necessary, it is not a secondary feature.
Explaining to the learners that a block-based strategy involving the use of dimensions “may work” is not pedagogically acceptable.

Without further informations, I am simply unable to explain why it is not advisable (although perfectly logical ) to link dimensions to objects stored inside blocks.

Is this related to Rhino 6 or MacOS ?
Is this fixed in Rhino 7 ?

Tanks in advance for any info.


Here’s what is questioning me regarding History Update & Dims.

Manipulating Individual Objects is working as expected.
Some operations like Distribute are breaking part of the history which is logic.

Manipulating Object stored inside a BlockDef is a bit more surprising…

Manipulating copied BlockDefs is more unpredictable…

This is very hard to explain to learners when studying the BlockDef with Rhino.

Small Update :
Just Tested with my Rhino6 for Windows lic .
Same conclusions.

Rodolfo Santos

Hi Rodolfo - I think, if I am reading this all correctly, that what you show makes sense if you assume, as is the case, that history relationships are not maintained inside a block.




What is difficult to understand is why that relationship isn’t maintained when dimensions are added to the block definition ( not inside )…

I also discovered that when scaling of an object linked to a dimension with the Gumball via internal calculation, the relationship isn’t maintained.


Hi Rodolfo - What do you mean exactly? How can a dimension be added to a block defintion without being inside it? Do you mean when a block instance is dimensioned, perhaps?



I am afraid, English is not my is not my native language, I probably don’t express myself properly.

Dimensioning a block instance is probably the right wording.


Hi Rodolfo - that looks like a bug in DimRadius to me - a linear dimension does update - thanks for pointing this out.

RH-63031 DimRadius - does not update with changes to a block instance


Dear Pascal

Is you start talking about a bug, here’s a list of possible other bugs.
Tested on Rhino 6 for mac

**Dimensioned Block

  • DimRadius - no relationship
  • DimDiameter - no relationship
  • Dim ( linear ) - no relationship when Scaling the stored object
  • DimCurveLength - No valid data displayed (get ###) - No relationship

**Dimensioned Object

  • DimArea - Dim object does not follow moved object ( displayed data updates well )
  • DimCurveLength - Dim object does not follow moved object ( displayed data updates well)


RH-63031 is fixed in the latest Rhino 7 Service Release Candidate

@brian @pascal

Thank you for the follow-up.
I will do few tests soon.

Rodolfo Santos.


Using a dimensioned Arc ( From Quad to Arc center ) and an Open Curve ( From Crv Mid to a Ref point aligned to Left EndPt )does not provide the same behaviour with the Linear Dimension Object.

History relationship is maintained with the Arc
History relationship is not maintained with the open curve

As the second reference point chosen for the Linear Dimension associated to the open curve is in the air, I would like to ask is this is the wanted behaviour?

Rodolfo Santos

Hi -

You need to snap to geometry, so, yes, that would be the expected behavior.
If you used .x or .y references to place that dimension point, the request is on the list as RH-47854.

Thank you for the follow up.

Rodolfo Santos