Mleader automatic justification lost, and not returning

[mpa-la]

According to my research, if you (meaning someone I have no control over 🙂 ) manually changes the justification of mleader text with the text editor, there's no getting back the auto justification function.  Even the latest version of stripmtext has a blurb in it that it may not strip justification overrides from mleaders or dimensions, and indeed for me, it does not.  Has anyone found a solution to this that I've missed?  Thanks!

[Anonymous]

what do you mean by "auto justification"?

[mpa-la]

When you relocate the text by using the grips, and the leaderline switches from the right or left of the text to the other side, the justification of the text changes to match.  Also if you mirror the mleader.  This does not happen if you have edited the text and changed the justification in the editor.  It stays wherever you tell it to in the editor.  Nothing will ever allow it to change its justification automatically after that.

[pendean]

MLEADERSTYLE command's CONTENT tab when you modify the text Mleader settings: set that behavior to what you want it to be instead of just accepting the default behavior you have observed that are set.

These are all user-controlled settings. Take control today.

[mpa-la]

I'm talking about mleaders that someone improperly edits to add justification within the text editor.  Try it yourself.  Make an mleader and move the text back and forth with the grip and watch the justification change automatically.  Then, edit the text, and in the text editor click one of the justification buttons.  Then try moving the text to the left and right and see that the justification no longer changes when you move it.  It always stays where you put it in the editor.  It's similar to editor overrides in mtext.  Changes in the editor override the overall properties of the object, the difference being that you can clear overrides from mtext, but I can't find a way to clear this override from mleaders once they're there.

[Anonymous]

you have something messed up in your mleader style, doesn't work the way you explained for me. do you have always left justify ticked in your settings?

[mpa-la]

I'll tell you the settings on one style this occurs with.  Always left justify is not ticked.  Horizontal attachment is selected and extend leader to text.  Note that you don't notice this is occuring unless you notice the text grip location or have enough text to wrap.  I hope the attached picture clarifies my question, but I'm coming to the conclusion there is no solution.

[pendean]

Post a DWG sample then: I have to be able to recreate the problem in order to help try and fix it. Is that an option?

Otherwise, two ways to fix the problem. First, in the MLEADERSTYLE definition. Second, using PROPERTIES. See both graphics below.

[mpa-la]

My settings are as you indicated, except that I don't want them to always left justify, I want them to justify automatically depending on which side of the leader they're on.  I've attached a dwg with my mleader.  The top one is unadulterated, the bottom one has been set to right justify in the text editor, as you can see if you select it.  It has an extra grip on the top right.  The left and right attachment settings remain the same in the change properties box becuase the change was made in the editor, not on the overall entity.  The change property box does indicate that it is right justified, but will not let you change it, it just flips back to right. 

As a point of interest, if you leave your change properties box open, then move the text on the top leader by grips you can see it change from left to right in the properties box, but if you do the same thing with the bottom one, it doesn't change.

Again, this is not a problem I'm creating, I know how to setup and use mleaders up correctly, it's junk drafting I'm trying to clean up from other people's drawings.  I have figured out how they're causing the problem, but I don't think there's a fix.

[Victoria.Studley · Accepted solution]

Hi @mpa-la,

Thank you for posting. I've tested this here in a new drawing in AutoCAD 2016, and confirmed the behavior you described. If the justification is text justification is manually changed, it will no longer switch justification automically when the multileader is adjusted from one side to the other. Instead it maintains the justification that was manually set. There does not appear to be a method for reversing this once it's done.

This seems like expected behavior for a manual override, although it would be nice to have the option to restore the automatic justification behavior when you encounter multileaders that are overridden in this manner. I've just logged this with the development team on your behalf, so that it can be considered for a future release.

[Dj_T_Rex2002]

Was this ever fixed? I'm using AutoCAD Architecture 2015 ... figured they would have come up with a patch to fix this.

[Anonymous]

I've notice that this behavior happens when entering the symbol for property line "PL". After I enter the PL symbol in the MLeader the text losses the property to automatically adjust by using the text box grips. See attached.

[Anonymous]

So in case anybody was curious, I'm on a trial version of 2019 and having this same exact problem. I never entered into the Mtext of the leader and manually changed the justification, I simply did a match property on one multi-leader to another. I was taking text from an old job and updating a set of drawings, pretty wacky huh? Call it "junk drafting" but it seems like a reasonable line of logic to follow that shouldn't result in your leader being irrevocably stupid.

With all the money AutoDesk has flooding into it, you'd think they could fix problems like these rather than just shuffling around icons year to year. 

[gotphish001]

Can you do the opposite? What happens if you use match properties from a Mleader that doesn't have the override problem to one that does have the problem? Does it fix it after matching the unaltered justification?

[Anonymous]

---

@gotphish001 wrote:

Can you do the opposite? What happens if you use match properties from a Mleader that doesn't have the override problem to one that does have the problem? Does it fix it after matching the unaltered justification?

---

It was worth a shot. Unfortunately, it doesn't work for Civil3D 2017.

[mpa-la]

Nope, doesn't work.

[punisher]

Have we seen a resolution to this? I have been fighting this for a long time now. It does seem a bit ridiculous. To be honest, if this persists, I'll just go back to qleaders.

[MauCabrera789 · Accepted solution]

Hey there, I know I'm slightly late to the party (by a few years), but seeing this issue has not been resolved as of AutoCAD 2019, and we all would like to purge our drawings of inconveniences, I would like to offer a work-around for this issue that has helped me as of late.

Firstly, for this work-around to be effective, make sure you have well-defined text + mleader styles in your drawing. Make these the "Current" styles in your drawing (commands "STYLE" and "MLEADERSTYLE" -> browse for style and click "Set Current"). Important to have the box "Always left justify" turned off in your mleader style (see pic). 

Next, you'll need the following LISP routine L2ML that allows you to select a leader object, then an mtext object, and merges both selections into a Mleader (and deletes the selections). The first selection does not have to be a leader object, it can also be a polyline. I found it over at https://forums.autodesk.com/t5/autocad-forum/mtext-to-multileaders/td-p/5336487. Included as attachment as well (you can always APPLOAD it into your client as well). 

Now you're ready for the fun.

1) Identify infected Multileader whose text won't auto-justify when dragged with grips.

2) Explode target Mleader. You should get the arrow head, line, and mtext objects. 

3) Engage L2ML command.

      a) Select the previous leader line (which should be a polyline object).

      b) Select mtext.

4) You now have recreated the mleader and once dragged, see its auto-justification property has returned. 

Unfortunately, this work-around means you have to work mleader by mleader to restore its auto-justification. However, I find it is much more efficient than manually creating new mleader objects and pasting the text content into the new leader. You can just group-select all the infected mleaders, explode, then L2ML a few times, and finally adjust overall scale if necessary. 

[mpa-la]

I'm still here, years later 🙂  That is an interesting workaround.  Very well described, kudos!

I'm very interested in the routine that turns things into mleaders.  I have two I have to use, one turns qleaders into mleaders, so if they're not qleaders, I have another routine that takes a dimension arrow and text and combines them into qleaders, then I run the other routine on that.  Your routine would save me about 7 steps when I run into that problem! 

I'm going to go download that right now, thanks for adding to the knowledge base!

Allison

[Julia.Sargent]

When editing text, make sure the paragraph alignment is set on Default, and do not click left/right/center. Then you can justify the mutileader normally without having to go into text edit in properties.