I make two rectangles and add dimensions:
I select all and move up and … the dimensions are stuck at their original location:
This doesn’t occur moving the sideways.
Interesting 
Same in here.
Seems the position of the dimension is vertically fixed.
-C-H-A-R-L-E-S-
So that’s a bug, right?
No.
There is no ‘offset’ property for dimensions. So what is recorded by history is the geometry that is snapped to, and - for horizontal dimensions - the Y value of the text position.
But Record History is off
In RH6, history is always on for dimensions.
I’m misunderstanding something here. That would imply that if you want to move both the geometry and dimensions you’ve created you’d have to re-do the dimensions? That can’t be right, there’s something I’m not seeing.
Hi Alex,
@pascal and I discussed this yesterday.
This is on the tracker as RH-37199 and was passed back to the developers yesterday.
In the WIP, History is not longer optional on dimensions. Dimension always have history, regardless of your own History settings in the Status bar.
We agree, if the objects and dimension are explicitly selected, then they need to move together and maintain the relative relationship to each other.
We also agree that it is confusing when the dimension does not move and or updates to the original placement.
One work around that may help you get your work done with this WIP, is to Copy and Paste the geometry from the clip board. The pasted geometry will be historically purged and you can now work as you expect, but with no history. (IMO doing History Purge All is more time consuming.)
I will let you know when the fix is in the WIP, so you can test it out.
Thanks again for all the work testing the Rhino 6 WIP.
Sincerely,
Mary Ann Fugier
1 Like
Another work-around for the time being is to first move the geometry and then turn on the points of the dimension. Select the 3 points in the dimension line and move those. This will keep history intact - if you were to need this.
@mikko, when you turn on the points of both a line and its dimension and then select and move all of these at the same time, the current WIP will pop up the History Warning - "The Move command broke history on 1 object."
This seems like a bug to me - though I understand that all of this is undergoing construction. 
1 Like
What do you expect to happen? Do you expect to not see the warning? The situation is similar to selecting just the dimension and moving it. The history connection will break if the dimension is moved, and currently a warning is shown.
Or, do you expect the dimension to be ignored in the move, in which case only the line is moved and the dimension updates as the history replay kicks in? It would look identical to selecting just the line and moving.
From a user’s perspective, I’m not sure why I would expect different behavior based on how something is selected:
In this screen recording, I first select the line and dimension, making sure I don’t select any of the points. Moving works - with the restriction that @mary identified, namely that the Y-position of the dimension is stuck. I then select all, including the points, and do the same. Now history is broken.
So I expect both to move and maintain relative position to each other and not break history in the process.
OK, thanks. I’ll add a comment to the related youtrack item. Control point transform is separate from whole object transform, so this will need to be handled separately.
1 Like
This didn’t quite make it into the build for the WIP release yesterday, but here’s where it’s going for now.
The reason for fixing the dimension line at all is that it makes it much easier to keep strings of dimensions lined up when you edit parent geometry.
If you select the dimension and the parent, the dimension line moves with everything else now.