If you have an AutoText with the Leader pointing at a certain Component, if you copy that AutoText and point the Leader to a different Component, it will not pick up the Value from this Component. If you Point it at the original Component, the Value appears. Any Ideas? Is there a way to force it to take the Value from the new component?
“Right Thing”? What if I’ve created something with other graphics (i.e. a circle) Grouped and placed in a Scrapbook? Moving the Leader to the new Component to pick up it’s Attribute values is how it SHOULD work. Or some other Linking operation.
The way the Scrapbooks work is that you ‘pick’ the style from it, upon activating the tool.
First, activate the tool, then hoover over the wanted ObjectStyle in your Scrapbook.
If you want to select instances, for instance:), create a label in the Scrapbook and replace the text with the Autotext Tag
If you want the Area, use
If you want the overall definition of a component, use
Etc. You can always switch while placing, but it is a nice way of indicating the different types of info of what you are labeling or tagging.
You must use the tag indicators(<,>) otherwise, it won’t recognise.
Edit: added tags ‘labels’ and ‘workflow’
If you anchor an existing autotext label onto a new component, the autotext doesn’t read the new component. The autotext just breaks, and you’re forced to double-click into the text again and reconfigure it.
@daveedwards, I’ve noticed the same issue. It’s frustrating. You can understand why it behaves this way when you think about the fact that the label tool can read nested groups and components. When you first add the label and anchor it to a face in a viewpoint, you have to select which container you want to reference. The problem is when you move the anchor over a new component, the label doesn’t know which nested entity it should pull the data from (even if the nested structure is identical). So the solution the LayOut team came up with is to just break the autotext…
I propose a different approach. The label should try to match the hierarchy of whatever it was originally anchored to. So in simple examples like the GIF above, two components with no nested entities, it is straightforward, it should just show the Component definition of either component.
When it can’t match the hierarchy, it should default to the lowest level container, determined by which entity you are hovering over.
In all cases, I think the autotext popup should appear as soon as you reanchor a label, and if you agree with the default value it picks, you can just press enter. Otherwise, you can select a new value.
There will always be cases where it won’t be able to match a value to the new entity, so having the popup appear would give users the opportunity to assign a new value.
The way it is now, it’s kind of a pain. After reanchoring the label, you have to double click the text, single click the dropdown, click the value, then click outside to close.
Thanks - that explains it very well and I like the solution you offered. Another way (I harder but more complete way) would be for the Window to show a hierarchy of any “nested” parameters (ala Outliner) so you can select the one you want without having to “drill” into them.
It already shows you the hierarchy based on what you hover over. In this example, it shows the root entity (Face), it’s component (tread#1), its parent (OB_STAIRS), and the parent container above that (LO_FIRST FLOOR). You pick which nest object you want to pull data from. This is why it’s hard to anchor a label to something else and keep the autotext, it’s not going to have the same hierarchy most times.
Thanks - didn’t know that. You can have use SU since Day One and still have much to learn.
Very true. I recently learned you can measure radius and diameter dimensions right inside SketchUp. Never knew that!
Well, maybe it doesn’t sound like it, but I do understand the frustration, though. I do not remember exactly, there might be a post removed, but scrapbooks were mentioned Copying doesn’t work, because the original ID gets lost.(what do you do when labeling? Do you head for your Xerox, or pick another?)
Instead of copying, and moving bits and pieces of a label around, why not just add a new?
Have a scrapbook open with different labels, set up as I suggested, and hoover over it after you activate the tool.
You can also have one with the tag <DynamicComponent(name)>
(You need to have DC’s in your model, off course)
Then, even nested components or groups of components still pick the right attribute. No need to hussel around.
Sounds like a job for the LO API that we never got TRIMBLE?