Spurious History Break Warnings

Although I’m working without using HIstory, when I’m joining or trimming certain objects I’m getting occasional History Break dialog boxes. Anyone else seeing this?

(6.0.17059.2211, 28-Feb-17)

Phil Cook
SimplyRhino UK

Hi Phil - can you post an example when you get a chance? Dims get History automatically right now in V6, and there may be other objects as well - we need to clean up what happens in these cases but dimensions so far here just report on the command line that history updating failed - I do not get the message box.


Many thanks Pascal. I’m working on a ‘real’ project right now in the WIP so it’s getting more use. It could be dimensions that’s causing the issue. These appear to be associative (ie have history) now without turning history on. This is good BUT I find getting the history break warning when you delete an object that has a dimension is slightly troubling.

1 Like

Hi Pascal,

This may be one of the examples.

History Off.
Create a simple rectangle.
Apply a linear dimension to it.
Select Objects with History - Dimension is Selected.
Delete Dimension - No History Break warning.
Delete Rectangle - History Break Warning appears.

Hi Phil -
I tend to agree, I lobbied against this, myself… I’ll see if we can ‘revisit’ that.



1 Like

@Phil_Cook -

Is the difference that the history break for dimensions is annoying because the history got turned on automatically?

If you make 2 lines and loft between them with history on and delete one of the lines, you get the same warning. Is it appropriate then since you intentionally turned on history?

I can suppress the warning for annotations, and I’m trying to understand the problem better so I can hopefully fix it right.


Hi Lowell,

Yes it’s exactly that. If I turn on History and do something that breaks it then I would expect to get a warning. However if History is automatically applied to an object, as with Dimensions, then the break warning is annoying. It’s also the fact that it’s a generic History warning so you are not told what this History Break warning refers to and, of course, if you are working on a large model that has taken somw weeks or months of work it could be anything. Does that make sense? Phil

1 Like

OK, I’ll suppress the warning

Hi Lowell,

I’m not sure a mere suppression is a constructive solution.
This will become an issue for people relying on the history link and a warning message if it breaks.
I’d opt for 2 toggles in the Document options related to annotations:

  • toggle auto-history recording for annotations
  • toggle history break warnings for annotations.

It’s my best guess for a setup that suits most. IMO hardcoded history recording for annotations is not ideal to begin with. However if it remains so or becomes optional, users will need to be able to rely on it. It would be counter intuitive and rather odd that history breaks for annotations are suppressed.

Please consider this a serious issue, if implemented poorly it’s another ‘typical Rhino’ issue where great features are not implemented with enough consideration. @pascal what are your thoughts on this?


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…


1 Like

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.

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

1 Like

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.

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?

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.

@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.

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