Then I’m seeing a bug. Once you click it, it stays blue.
sounds like it.
If I change the setting in Options > Annotations, then the property panel reflects the change.
I think I see the bug too.
Check uncheck stays blue.
Remove Overrides fixes the blue to be correct.
K. Thanks.
That’s probably a bug for Alain
@margaret
Do you want me to add the bug report?
I’m on it.
1 Like
Hi @lowell, here are some more items for you to consider:
When adjusting the text justification in the property panel, the text string is not constrained to the text box boundary - disappears out of the box if middle or right justification clicked as the edit box seems very wide by default, the double-click edit box is ok.
SaveAs back to V5 loses the text wrap, so opening a V5 file in V6.
In a text edit box or layer list, when changing a word in a string with a double-click, the space at the end of the word is also selected, but the space isn’t replaced with the new word so the space needs to be re-applied. (V5 works and the space is returned).
Opening an existing V5 drawing in V6, the dimension ‘82’, in the image below, looks a bit messy in the V6 version. The arrows have been relocated when not necessary, is there an adjustment to override this arrow placement? What dimension property determines the new arrow placement? In the ‘16’ dimension shown, I think the V5 version is cleaner without the line joining the two arrows, can this be overridden?
I’m seeing the line work coming out heavier in V6, both default wireframe in the image here with curves set to 1 pixel.
V5 left / V6 right
Mask text doesn’t seem to be operating correctly yet, the text string is unmasked when deselected and the override not working yet.
It looks to me like if I use the Background for the mask it is working correctly if the text is selected and not masking if I deselect it. Same problem with a solid color and lines bleeding through.
I’ll get this on the list.
https://mcneel.myjetbrains.com/youtrack/issue/RH-37492
Masks draw that way in V5 too.
You have to BringToFront to ensure that they cover everything.
We can think about forcing it in the display.
Selected stuff always draws on top
The way style overrides work (may be right or wrong) is that once they are overridden, they stay overridden until they’re removed, either by the Remove overrides option in the Style dropdown, or by setting the annotation to use a different style.
The blue text shows that the property is overridden.
A subtle effect of that is the if a property is overridden, then set back to the style’s value (still overridden) and then the property in the style itself is changed, the override stays in place.
So when an override is set, two things happen - the value changes and the field is marked as an override. There is no way, currently, to remove a single override mark. The are removed all at once as I said above.
Whether that is useful, confusing or something else is an open question, but that’s at least a way of thinking about it for now.
Yes, that is pretty annoying. Since the edit box is often wider than the docked properties dialog, the text ends up getting hidden. It’s going to take some fiddling to make that work, and we may have to nit move the text to the right when the alignment changes in ObjProperties
Yes, there isn;t any attempt to translate text wrap. I was hoping to avoid having to do that.
I tried what I think you said and it seems to me to work the same in V5 and V6. Double clicking selects the word and the space, and pasting pasts exactly what’s in the clipboard whether it has a space or not.
Maybe I don’t understand what yu meant.
I agree that needs a little tuning for the threshold for pushing text or arrows outside. There’s a little added to the arrow size for checking if things fit. I’ve changed it a few times and I don’t remember what it is now, but it does look like it’s too big.
There isn’t a manual override for it and I was hoping not to need one, but maybe we will.
I’ll have to check that out, but it seems like 1 pixel woudl be the same in either one
I’ve been a long proponent of having history automatically enabled on dimensions - so, Thank You for implementing this.
A few things I’m hoping could be tuned up:
-
Make a line and dimension that. Delete the dimension. Then delete the line. A
History Warningpops up saying that history was broken on 1 object. -
Make a line and dimension that. Select both objects (by whatever means). Move both objects. A
History Warningpops up saying that history was broken on 1 object.
Does that have to be the way it works? (I’m hoping it doesn’t)
Yeah, this is the way history works on all objects, not just dims - if you do something to the child - even if you do the same to the parent in the same operation, it breaks the history… Don’t know what might be done there, but it’s global, not just dimension related.
–Mitch
Both of those seem to not make sense, especially the one about deleting the dependent and then getting a warning deleting the parent.
As you say, Mitch, they’re in the history system, not just dimensions.
I know they are in the history system.
Dimensions are the only thing that will automatically turn on history for objects (which is good) and a lot more people will start seeing this behavior.
My question is just - does it have to be that way? And specifically so for dimensions / annotations.
I’m sure it would be possible to get rid of those warnings. I haven’t looked through that whole process lately and I don’t know what it would take to do it. It does come up more now and it would be nice to get it worked out better.
Hi Lowell, yes, pasting is good here too, here is an image of what I was trying to say. Editing a word in the edit box by double-clicking that word picks up the space at the double-click but the gap is closed when typing starts and not replaced as it was in V5. Image shows the word ‘Middle’ replaced with ‘Top’
V5 left, V6 right
Just noticed while testing this that the edit box is closed, as opposed to cancelled, so the edit gets through to the screen and escape doesn’t get you back to the previous state - an undo is then required, just an observation.
There is another scrollbar misbehaving in the Dimstyle editor, see image where the scroll runs out of travel.
To repeat:
In Dimstyle editor - expand text, expand Dimension Lines, then scroll down to Leaders and expand it. Similar happens with tolerance too. The scroll sometimes doesn’t readjust when the expanded items are contracted.
My DimStyles usually have whole numbers for dimensions and I use override to adjust one-of precision when required - Rhino’s default precision to 2 decimal points would probably be fine in the example given - tricky one to please all.
There are times when a drawing set is requested in .dwg format and in V5 there are some things to be aware of to ensure the drawing looks the way it is intended. Below is a list of issues when saving V6 as a .dwg.
Text wrap translation is important to me and others, no doubt, who will be accessing their V5 archives from V6. To edit multi-line V5 text in V6 will require shuffling around with line breaks and back spaces or deleting all line breaks and introducing spaces to get back to a situation where you can use grips effectively - then the same again if the client wants V5 files from your V6 originals. Your call Lowell but I hope you consider text wrap translation.
V6 Round trip via .dwg issues (I don’t have autocad so can’t test how V6 files look when opened in Acad) :
A wrapped text string in V6 is converted to a single string (V5 text wrap to dwg works), so text wrap can’t be used effectively when saving a dwg, a step backwards to line breaks and manual formatting of text seems necessary.
Radius and Diameter dimensions are flipped in .dwg round trip (V5 the same). This is pretty important as it can’t be worked around.
Leaders see an increase in leader tail length of around 50% and lose their text justification.
Empty leader lines (with no text attached) don’t get through to .dwg
In V5, text which has been underlined in Autocad, comes into V5 with %% prefix, don’t know about V6 yet.
‘NoPrint’ print width is lost in .dwg and becomes default print width(same in V5)
Solid hatch is lost when saved as .dwg (same in V5).
Dims with dimension text adjusted by grips in Rhino is recentered in dwg. The new method of forcing text or text and arrows outside is working well though.
Text loses justification and anchor position on a round trip to .dwg, All text comes back Left justified, anchored top. (was working in V5)
Also groups are lost in Acad, which can lead to a mess at the Autocad end.
This is minor - If opening a new file after exiting an unsaved .dwg file, the drop-down list could be a bit longer to include .3dm without the need to scroll. (V5 the same)
Masked dimensions end up as a long winded name and uid.
Annotation Test V6.3dm (155.1 KB)
Annotation Test V6.dwg (24.8 KB)
The files uploaded here are an example V6 file with it’s savedas dwg for comparison. Open the dwg to see some of the above points.
Try worksession the dwg into the V6 file above to see some problems with text being added to default layer at a reduced text height, instead of remaining with the attached file - also a crash occurs when the text is selected. Worksession the dwg is also a good way to spot the differences when the Worksession sublayers are selected.
Below screenshots show the display difference I’m getting, the heavier one is V6. Same file, same monitor, same default wireframe display. Curious to know if it’s my system or a common occurrance. Not very happy with Dell monitors anyway, V5 display seems a bit wishy-washy with greyish blacks, so V6 looking better, but a touch heavy.
I see what you mean now about the trailing space. That little pop-up edit box was heavily customized for that specific purpose. The ones we use now are different and I don’t know if we’ll be able to get that kind of control now.
It seems like now at least one of the major goals will be to make more accurate translations to and from dwg files, and depending on how things shape up, probably between v5 and v6 too. The things you itemized are part of that.