Text override behavior

I know text and annotations in general are getting some active work, so much of this may be known or expected at this point, but I am experiencing what I would consider unexpected behavior when overriding text.

So, if I start a file which has one dimension style in it:

1. Use the Text command and place a piece of text
2. Copy that text, then double click to modify it, such as changing it’s height.
3. Now copy that modifed text, then double click it to modify

At this point you will be asked if you want to delete current annotation style. This is the first unexpected thing. It seems Rhino is creating invisible annotation styles to store my overrides, so I’m being asked if I want to delete the invisible style created to handle the override, but I find this to be confusing.

4. Say “No” do deleting the annotation style.
5. Change the height again to somethinig unique

At this point you should see both the second copy (the one you are currently editing), and the first copy (the one you are not editing) update their size to the new unique value. This in my oppinion is a bug. I as a user am only expecting the text I have double clicked to edt to be the text that is updating. Further, there is no way for me the user to know what text is currently assigned this invisible annotation sytle, so if I am editing text in a file, there is no way as far as I am aware to know what text will be updated.

6. If you are still in the text editing window, hit OK, and now call the Text command again to place another piece of text.

Over here, the text height of the new text will be the unique value you used in step 5 rather than the text height of the expected current annotation style text height. When checking the current style, over here after saying “No” to deleting the current annotaion style, no style will be selected, which is also unexpected.

7. Now double click one of the modified pieces of text. You should be asked again if you want to delete the current annotation style. Say “Yes”.

Over here, no text editing window comes up, and all the modified copies revert back to the pre-existing annotation style that the file opened with. I find this also unexpected.

8. Now select one of the copied, modified pieces of text. In the properties window, notice that both the Style and Height is (varied). Select the height text, and start to type a value.

Over here this crashes Rhino (I sent in the crash report).

So, the TL;DR version, I find it weird that editing one piece of text can inadvertently modify another piece of text :slight_smile:


Buggified as:

@SamPage - Thanks for the help.
I can see at least 2 bugs to start with. There are probably more that will show up when those are fixed.
First, when text with an override is copied, it’s override style should also be copied.
Second, the override style should never be set as the current style.
We’ll start with those and I’m sure there’s more to it than that.
It looks like the dialog gets pretty confused somewhere along the line when there are overrides involved.
That may just have to do with deleting styles that are being used.


I just ran through this list again and it all is working correctly as far as I can tell.

When next week’s WIP comes out, could I get you to have another bash at this and the other techniques you use with text and see if you can find anything else that is goofy?

There have been a few more fixes since this week’s WIP went out; I’m using a daily in-house build from this morning, but I think all of the main functionality is there now.
We’re sure there will be some small, minor things that need to be tweaked but next week we’ll be ready for full on guerilla testing of the new text and dimension tools.


Over here on 6.0.17003.8321 it looks like it still had some issues, but I will certainly give it a run on next weeks wip. I’m excited to try it out, as I’m to the point in my current project were it is down to drawing, so all layout and annotations, and I haven’t been able to use v6 much.

Thanks for the heads up,

The override problem is fixed now. Let me know if you see it differently

As far as I see, this is solved. Thanks!