Definately a bug.. been around since 2010 still isnt fixed.
Mleader text that is centre or right justified will move to the right everytime i edit it..
PLEASE FIX!! very annoying.. see example drawing
Original Position
after double click editing
Solved! Go to Solution.
MLEADER text with no leader? Isn't that just MTEXT?
That type of text relocates/adjusts to the location of the leader/landing line, that's why it moves: it's designed to leave the leader location intact instead of having the leader stretch/shrink and bounce around all over the place anytime anyone edited the text in the MLEADER.
I don't think it should be 'fixed' to match your need, sorry, that's useless for MLEADER functionality.
ummm.. im not understanding anything your saying there mate..
Mleader text with no leader is just mleader text still.. try it.. the reason we use mleader text with no leader is occasionally at smaller scales you dont need a leader and larger scakes it becomes to small to put the text inside so you need to quickly add a leader to the text to point at the object..
If I had some mtext.. i double click in it.... then change the content ... get out of it... and the basepoint moves left by 20 units...im pretty sure that is not the intended functionality...
after a few edits in paperspace the text would eventaully take off outside the viewport!!!
Kapanther
Hi Brad,
Dean is correct with the info. It's as designed at the moment. However we understand the inconvenience you have with that, i have provided your feedback to our development team.
We will work with our developers to see any enhancements that can be done on this functionality. Do contact me, if you have any concern.
If MLEADER text has no leaders to adjust to why should it move? I understand the functionality if leaders existed... but my MLEADER text has no leaders!
Alternatively why not simply prevent MLEADER text from having no leader... then that confusion doesnt exist..
Brad
Not really I use MTEXT all the time... I am merely on a crusade to improve a product I use everyday..
If the functionality is for the leader (even an imaginary one) to stay in the same place. How come the text moves away even further froms its imaginary leader?
Top text is Mleader Text with Leader (center Justified), bottom text is the same mleader text with leader removed (the cyan leader is where the imaginary leader should be.
After double click editing you would expect both pieces of text to move to the right the same distance. Because maintaining the leader the designed functionality.
I added " Friend" to both pieces of text. Why does the mleader text with no leader move further away than the mleader text with a leader?
I thought the leader imaginary or not defines the location of the text?
Try it yourself.. see attached dwg.
Brad
Sorry Dean
I jsut couldnt resist working you up a little..
😛
Kapanther
Interesting because I use MLEADER is the same way sometimes because it does work better than MTEXT and have never had this problem!
Try center justifying it then double click edit and exit.. it will move right to maintain the imaginary leader position.
I wanna resurrect this forum for a sec. I ran into the same exact problem, but I've found the actual solution.
The reason I'm using a leaderless mleader rather than mtext is because I want to have text with a box around it that stretches depending on the text inside, and mleader does this most easily. The glitch that the OP brought to light is really a small glitch combined with 1 piece of missing information. Pendean's point addresses the basic functionality of why it's doing what it's doing, but doesn't explain why this specific problem is happening. Here's why:
If you were to leave the leader attached, and move the leader to the right side, you would have no problem. The problem is that when you actually remove the leader (right click > remove) it defaults it back to the left side. And when you have a left attached, hidden leader with right (or center, for whatever reason) aligned text you get the glitch of the text moving 'the distance that the text takes up' to the right. See pictures below (where left is before edit, right is after). If this were intended, the same thing would happen when the leader was still attached, as C3D said.
The way to get around this glitch is to trick AutoCAD into thinking the leader is still there. So if you need your text to be right or center aligned...
Keep the arrow attached, then move it to the end of the landing line (effectively making it distanceless) and make your landing distance 0. You'll have to use the M command to move the text rather than drag it by it's handle, otherwise the arrowhead will stay put and the text will move, undoing what you did, but it's definitely a solid workaround.
Hope this helps.
Well done.. that is a solid workaround.. I would give you kudos as well. but for some reason its broken for my user account.
MLEADER ... SMH ... I have never used it since 2004 and have never had problems like what is described so often with the silly command.
Is this related to the issue where upon opening a DWG file with annotative mleaders, the landing distances and landing gaps seem to reset to some random setting.
I introduced annotative mleaders and mleader styles to my firm a few weeks ago in an effort to evolve our CAD practice, but am catching flak because of the issues we are having with one file's mleaders resetting as described above.
Attached is a dwg with one of the culprit mleaders in it. To get it to "mess up" change the text style to something else and then back to "standard" in the properties menu. The result is a landing that ends up extending over the text.
Any help would be greatly appreciated. As silly as it sounds, our decision to move forward with using viewports, sheet space, annotative elements, etc... hinges on this. If I don't find an answer soon, I will have to endure the practice of mental scale conversions and model space sheet drafting for the distant future. : ]
Thanks in advance.
Model Space sheet drafting, really? In this day and age?!!!
I introduced annotative Mleaders and text years ago and have never had this problem.
However, we do not change the text style within the Mleader. If we need another style we create another Mleader style and use that.
Same with Mtext, different styles for different requirements. We do not chnage style within Mtext.
Yes... really. Trying to get things turned around, but am having a difficult time selling this given the mleader issue. Thanks for the reply, BTW. I'm not sure if changing the text style is the culprit, but it seems to trigger the issue. The real issue is that all of the mleaders seem to reset or randomly change upon opening the file. I found out today that one of the architects here saves their CAD files back to 2004 version. I'm currently looking into whether this is what is causing the issues. I will post again when I find out.