I think just a gif of what I’m dealing with worth 1000 words.
I just want the leader end point to stay stuck to the left middle of the text box. It sometimes stays and sometimes goes back to the right. I’m not sure what causes it to go back.
edit: In case it matters, the bottom line of the text is a z-coordinate auto-text tag.
edit 2: also double clicking to edit the text box sometimes triggers this.
It goes back because it is a leader… and they tend to stick to the side that the pointer / arrow is pointing to.
Not sure if you can make it stay - but if I wanted to try something I would turn off the end condition (dot), then draw a short line segment to where you want it to end. Maybe group everything together… and see if that works?
Thanks. I’ll try that. I understand that typical leader behavior is to stay on that side. I got excited today when I discovered that there are these predefined green and yellow snap points on the text box though!
You might be able to make the leader line with no stroke and then have your own line for the height…
Edit: unsolved.
Extra line is a lot of extra clicks to change each annotation, and there are problems with the line sometimes getting in the way of control points for the leader. Saving time is the goal of using auto-text for my elevation datum lines.
I’m intrigued at Dave’s solution. Can you elaborate? I actually thought I had it fixed by messing with the text anchor settings and justification. I’m having trouble figuring out the logic of why the leader end point resets sometimes.
So I think I have solved this. I’ll leave it up to the sages and the team as to whether this is a feature or bug.
The leader endpoint loses its place when I click on the bounding box of the text for any reason, whether to drag and move it or to double click on it to edit it. I can click and drag the stem or the branch of the leader line itself to my heart’s content and it stays. I can edit the text box as long as I double click in the text box and not on it.
I deleted my previous post because although it works because it’s not great in some situations like if there’s three lines of text.
This seems to work, despite the bugginess…
I don’t mind bugginess if there’s a logic to it that makes the bug avoidable. Just never click text boxes. No problem!
An update: my method works for ungrouped labels. If I group them, the endpoint doesn’t stick during a move. It also doesn’t work when selecting multiple objects at the same time. Slight bummer.
Related question:
Is there a way to make the leader NOT stick to what it’s pointing at during a copy?
I should add that if anyone has achieved what I’m trying to achieve (easily copyable annotations with dynamic text tags in layout) I’m happy to fast forward to the best way of doing it.
You have to grab it close to the start point and the whole leader will move when copying. If you grab it close to the end / text it will stay ‘stuck’.
Does that work outside of a group or when selecting the label and other objects?
I don’t know what you mean - I use surface area and item name quite a bit and copy leaders around by grabbing near the start and they update by themselves when copied to a different location.
Clicking and dragging from the pointer part of the leader works when the label isn’t pointed at something. Copying it while it’s pointing at something doesn’t work well unless you unstick the leader.
I think.
Ahhh, I see what you are doing. I don’t use that method - I was talking about moving / copying normal leaders around.
I have formed a tentative truce with layout but moments like this are the true test of mettle.
I think that it has to do with how close I’m clicking to the text box?
I spoke too soon I guess. In some cases, such as with this label, it doesn’t let me edit the text box without dislocating the leader.
The mechanics of labels is definitely finicky at best and buggy at worst.