Spurious History Break Warnings

(Pascal Golay) #10

I don’t use annotation enough in real life to really have a horse in the race, but the history break warning on dimensions as described by Phil does seem unhelpful to me. (In fact parental deletion seems like it should be allowed without a warning (like V5) - that was what I referred to above, I did not see enough advantage to this when it was added, myself. But that is debatable perhaps - let’s just say I don’t an advantage myself, and I do use History a lot in real life.)

More options is always a possibility - despite appearances, there is a pretty strong bias to avoid adding options if we can. But, maybe that is a way out…


(Wim Dekeyser) #11

I’m not understanding the way it works at the moment.

I make a rectangle and explode it.
I dimension the upper horizontal line.
I put a fillet between the upper horizontal and one of the vertical lines.
Command-line echo:

History failed to update 1 object.

I dimension the lower horizontal line.
I delete the lower horizontal line.
Windows warning sound and message box:
The Delete command broke history on 1 object.

What is the logic in the difference between these two?

By the way, I am all for having history on for dimensions.

(Lowell Walmsley) #12

OK, I guess we’ll have to talk bout it here before we do anything more

(Lowell Walmsley) #13

I don’t know if a technical explanation will help much in this case, but in one case, the curve is deleted and in the other it’s still there with the same uuid, etc. In the second case the parameter where the dimension attached is no longer on the curve and that causes the update to fail.
It wouldn’t have to cause it to fail but it does now.

I can’t remember why it does cause a failure, but there’s enough effort made in checking that I think there must have been a reason.

Anyway, what would you have expected or wanted it to do?



In V5 I use the Escape key to dismiss broken history warnings, which I get zillions of since I always have history recording. In V6 I have to use a mouse to dismiss the warnings; the Escape key will dismiss the warning, but also undo the action that broke the history.

I get it that normally hitting Escape during a command will cancel the command, but in this case the command has completed and the message is just informational.

Personally, I really miss the V5 functionality and would love to have it back.

As far as the auto dimension history break warning, could it be worded differently so the user could quickly recognise that it was a dimension that was broken and not geometry? Might be less confusing.

(Wim Dekeyser) #15

Yes, thank you. That explains what happens. I don’t think it’s a good idea, though. For the end-user it doesn’t matter what happens with the UUID.

Not sure what you mean by that. Are you saying that the other behavior could be that the dimension shrinks to the left-over length of the curve? I can see arguments in favor of that but that would mean that we need to more careful where we snap when we set a dimension. I would generally snap to the “end point” of a rectangle without paying much attention if that is to the end point of the horizontal line or the vertical line. If the dimension were to shrink with the left-over, this would make a difference. But that is just a matter of habits, I suppose, and not necessarily bad.

Ah, the million dollar question.

I don’t think I have all possible workflows clear in my head and as such, an option to turn on or off the behavior of enabling history by default for dimensions (and hatches?) would be good. Perhaps in the form of a list in Rhino Options > General > Command Lists > Always record history for these commands:

Further, in my mind, a dimension has little value without geometry and I would have history recording on by default. When the geometry that it is attached to disappears, I don’t think that I would mind that the dimension also disappears without warning (or perhaps only an echo on the command-line). When working on a model that is dimensioned on a detail on a layout, I think it would be good that one didn’t have to go looking for orphans all over the place. If the command-line would also record on which sheet and perhaps which detail a dimension was removed, that would be fantastic.

:confused: There are strange things happening while testing some of this (and the command-line doesn't record broken history events when the message box pops up - it would help if it did). I had a rectangle in the top view that I exploded and put some dimensions on. Then, in a detail, I added another dimension. Back in Modelling, I deleted everything and got the message that doing this broke history on x items. But one then one time I got
Command: '_SelAll 3 curves, 2 linear dimensions added to selection. Command: _Delete Linear Dimension to Edit:
(the command-line doesn't echo which command would trigger such feedback)

and when I undid everything and redid the deleting, I got

Command: '_SelAll
3 curves, 2 linear dimensions added to selection.
Command: _Delete
History updated 1 object.
and the one dimension in the detail had shrunk. But why?

(Lowell Walmsley) #16

What part don’t you think is a good idea?

Yes, but I haven’t thought through all of the possibilities either. Now, the location on the curve is stored as a parameter. If the domain of the curve changes so that the parameter is not on the curve, now it causes a failure and it could instead snap the parameter to the new curve end. In the example of filleting a rectangle, though, I think it would be more likely that I’d want the dimension to stay where it is.

That’s true, but if you had 3 rectangles end to end and a dimension on the middle one and the middle one was deleted, the dimension would still show the distance between the other 2 rectangles even if it wasn’t connected to them with history.

This is getting pretty complicated and it seems like it will take some experimenting to figure it out.

I don’t exactly understand your “strange things” and I’ll have to work through it more carefully.

(Lowell Walmsley) #17

@Mark -
Those seem like reasonable ideas to me. II also find the dialog warnings annoying.
I wasn’t part of the discussion about changes in History reporting and don’t know what the thinking was.
I’m getting involved now because it’s coming up with regard to dimensions.
Maybe @pascal has some ideas about it.

(Pascal Golay) #18

I grumbled some more in the bug track item - https://mcneel.myjetbrains.com/youtrack/issue/RH-38439. Mikko has a less grumpy take on the logic for the warning than I do however…



I just found this thread noticing joining some curves bringing up, far as I can tell, spurious history break warnings.joining curves spurious history warning.3dm (133.4 KB)


If a dimension line loses its association (history) to the object it is dimensioning, many cases exist when the “drawing” will be wrong (geometry changed, dimension lines still shows the old values). In architecture drawings are unfortunately still the most important tool to communicating dimensions, due to the manual / human based construction work. Wrong dimension lines cause serious legal trouble. With hundreds of dimension lines in a project, it is very labor intensive and error prone to check them all after a change.

Please see this older post, for a suggestion on how a useful warning dialogue box could look like: Dimensions features

(Pascal Golay) #21

Hi Jim - no warnings here joining curves in this file - no objects with History either…



Hi Pascal,

Interesting. No there is no history on the curves, but there was some history on them–they were parent objects actually–previous to trying to join them all up, then these warnings start popping up at every operation, even though their children had been deleted.

(Pascal Golay) #23

Hi Jim - OK - thanks - I can repeat this - Explode a rectangle, and Extrude the lines with History, then delete the extrusions and join the lines… History break warning. I guess in the session, Rhino still knows abut the extrusions for Undo purposes, maybe that is what is triggering the warning.



Would it be possible for effected dimensions to be marked in any way? Say with a dot or something?

One example is say that I dimension the height of a wall, and snap to the baseboard instead of the bottom of the wall. If i later delete or change that baseboard geometry, the height dimensions on all my drawings are going to shrink or just be wrong which can be very hard to spot on a sheet with 50 dimensions.

A perfect situation for me would be for the dimension to lose history but remain unchanged when the associated geometry is deleted, but be clearly marked so that I could find, and adjust them if needed.

Having the dimension shrink on its own can be a very big problem if I have that dimension on many different sheets to try and find. As things are now, I will most likely need to turn off dimension history to be safe, unless I’m working on something very simple.

(Lowell Walmsley) #25

It does sound bad to have dimensions change on their own.
I don’t understand how that can happen though.
Can you explain that?
As far as I can see, when the object a dimension is snapped to is deleted, the dimension stays unchanged.


Hi, it mostly seems to happen when dimensioning between multiple items. Here’s an example with 2 boxes. If you delete one of them, the dimensions are changed and moved around to some arbitrary numbers which could go un-noticed in a large sheet of drawings.

temp.3dm (125.8 KB)

Ideally they would remain the same once losing the connection, but it would also be nice to have a way to visually see which dimensions have lost history on top of that so that I could verify that I dont need to manually update them to any changes later on…


(Lowell Walmsley) #27

Thanks. That’s a bug in the history update. I’ll fix it.


I would go as far as to delete the dimension. It is not safe enough, that it just looses its history. On arch. drawings only dimension values are what is binding for execution. Correct object geometry with an incorrect dimension number (even if the discrepancy is visible), will be built according to the incorrect dimension.

(Brian Gillespie) #29

RH-40353 is fixed in the latest WIP