Dimension history bug

I have been complaining about this in a very inarticulate way for a while, but finally figured out a repeatable example. In the attached, just move either the magenta line in layout space or the green square in model space and you will see one of the dimensions fly off in space.

DimBug.3dm (86.1 KB)

The one side of the dimension that flies off is snapped to the layout space object, the other end of the dimension was snapped to the model space object. The side that flies off will go to the layout space coordinates that match the model space coordinates that it was snapped over.

I tend to set sheets up so that I have a detail showing a clipped model, and will draw as needed in layout space to augment the model (section lines, hatches, hidden lines, that kind of thing), so this is a situation that I run into a fair amount.


Hi Sam - checking it, thanks.

This part is the deal… I can reproduce it, thanks.



1 Like

I had been working in V7 wip, and just jumped back to V6 to check this, and I’m not sure I am completely pleased with the solution. It seems that if one pick is layout space, the dim now just doesn’t pick up the detail scale, even if the other side is picked to an object in a detail. This feels like a step back in usability from V5. It is possible to get V5 behavior back for dim pics like this, where the dim still picks up detail scale were possible?


Do you mean that if one end of a dim is snapped to a model space obj in a detail and the other end is snapped to something outside that detail you still want to use the detail scale?
What if the dim snaps to model space objs in different details?

I think the v5 behavior was good: if one end is snapped to model space object, and the other pick isn’t providing conflicting scale info, go with the model snapped end. If it does conflict, no scale is inherited. If you want super bonus points, if I am snapping between two details of the same scale and view, give me a broken dim showing the actual distance in model* :slight_smile:


Edit: To further complicate the bonus points portion; only give a broken dim line if (actual model space distance) != (layout space distance) * 1/(scale factor), as there are times I use multiple details for a jogged section, and in those cases wouldn’t want a broken dim (I know the possibility of this is low, but you never know what ends up on your guy’s radar, so I thought I should clarify just in case)

1 Like

OK, I can do the basic part of that without too much trouble.

RH-44380 is fixed in the latest Service Release Candidate