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 <ComponentInstance>
If you want the Area, use
<FaceArea>
If you want the overall definition of a component, use
<ComponentDefinition>
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â
2 Likes
@MikeWayzovski Doesnât sound like you understand what @daveedwards is asking.
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.
1 Like
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.
Try it.
Sounds like a job for the LO API that we never got TRIMBLE?