ssget X destroys leaders

[LyleHardin]

The following code

  (setq rvd_block (ssget "X" (list (cons 2 "revdate"))))

messes up the mleader tail of left justified, multi line text mleaders.

See image.

It's part of a larger routine that finds a revdate block (green in the images) and updates the information in it.

We've used it for over 15 years now.

After running the routine, all the left justified, right pointing, multiline Mleaders' tails or hooks go away. Partially. (2nd Image) Run it again and the whole hook is gone. (3rd image)  Sometimes, though, not until you select the mleader.

If the Mleader text is grip edited, moved right so the arrow points left, then moved back again so the arrow points right, the leader hook reappears. Weird.

We left justify all our Mleaders. Arrows run from middle left of top line or middle right of bottom line. Leader tail is extended to text.

Note that if the style Leader is NOT extended to text in the Mleader style, everything is AOK. The tails stay put.

It only happens when the style is annotative.

AutoCAD 2012 and Civil 3D 2012

[pbejse]

Its going to take a lot of guesswork without a code to look at. Annotative is a great tooll but its also a pain to use your previous lisp code when you're migrating from  a pre-annotative version of cad.

A snippet or a description on what your code does will help a bit to understand why your code behaves that way.

[LyleHardin]

Well, that is the line of the code that does the damage.

I've attached the rest of the code and it should work with the revdate block in the dwg file I attached to my first post.

The revdate.lsp routine simply checks the drawing for the revdate block. If it's not there, it asks you to insert it. If it is there, it updates the filename, date/ time, and user attributes.

I'm thinking of just going with fields. I've embedding fields with this data in our title block. It's amazing how some users don't like that information showing and will remove it. Well, 6 months from now, it takes a while to find the drawing when there is no clue as to when it was done, what the actual filename is and who did it... Bugs the heck out of me!

Thanks for the reply.

Lyle.

[stevor]

If what you say is true, then you have uncovered the biggest bug in autocad yet.

More likely, the 'damage' occurs later, like in the 'RevAall function, or such.

An easy way is to insert pauses into the code, just after suspected operations,

and inspect the dwg at those stages. A code to do so:

 (getsring "\n At stage: ---, Esc to exit, any other key to proceed ")

And be aware that the function 'entupd' my causes changes made to become visible.

[Jeff_M]

This is just plain weird. I don't know how, or why, performing an ssget does this, but I can duplicate what you describe using the drawing and one line of code. Have you submitted a support request with Autodesk through Subscription or the Feedback page? 

[pbejse]

What weird on my part is i 'cant seem to duplicate the "experience". 

<R2009>

[Jeff_M]

That's right, it only occurs in the 2012 products.

[LyleHardin]

Nope. I have not submitted a ticket to Autodesk about this yet. I'm glad you can duplicate it. It lets me know I'm not crazy or that it's in our custom settings or something. Clearly it has something to do with the new feature of being able to extend the leader hook or tail to the text. That's why it only occurs in 2012.

I'll write up a ticket today if I get the chance.

Thanks for following up and duplicating the error, Jeff M.

Lyle

[LyleHardin]

Okay, ticket submitted. I referenced this post.

I experimented with my Beta of 2013 AutoCAD.

The LISP and Mleaders work fine in 2013.

So, whatever it is, appears to be taken care of in the next version.

Doesn't do us much good, though, for another 6 months....

[zalant]

I've checked out the drawing (MleaderHookHiding.dwg) and it appears to be the Width property of the mleader which is the root of the problem.  

Mleader Width Property


If it is non-zero, then executing that piece of script eats away at the Landing Distance until it goes negative and the Landing Line disappears (although I'm not exactly sure why).  If I create a new mleader using the same mleader style, the Width of the new one is zero and I cannot reproduce the behavior of the disappearing Landing Line.  Similarly, if I restore the Landing Distance to .125 and set the Width property of the existing mleader to zero, it then behaves properly.

[zalant]

In doing some further research, I found a couple of other ways to work around the problem behavior, even while keeping the option to extend the landing line to the text turned on.  The following methods are alternatives to setting the width to zero or turning off the leader extension (see above posts).

• Prior to executing the LISP code, set CANNOSCALE in the drawing to a scale which doesn't exist for the mleader in question.  Be sure that ANNOAUTOSCALE is disabled, or this workaround will not be viable.
• Prior to executing the LISP code, set the mleader's justification setting to 'Right'.  If protecting multiple mleaders, use QSELECT to find them and the use the Properties palette to modify all of their justification settings at once.  The errosion of the Landing Distance only seems to occur when justification is set for 'Left' or 'Center'.  

As noted above, this does appear to have been fixed for the next release.  Often, if there is no negative impact, code from newer versions gets culled and made into hotfixes or service packs for the immediately prior versions.  We'll have to wait and see if that happens.  

[LyleHardin]

Thanks for sticking with this Zac. I appreciate the feed back and will look into some of these workarounds.

In the mean time I have told my users to turn off the "Extend Leader to Text" in the Mleader Style.

I also turned off that feature in our templates.... But wait, there's more...

When we use those templates, with "Extend Leader to Text" turned OFF, the new drawing has "Extend Leader to Text" turned ON.

This of course only happens when the Mleader style is set to "Always Left Justify" and is Annotative.

So, the setting "Extend Leader to Text" 'comes back' ON when creating a drawing from a template that is set up with "Extend Leader to Text" turned OFF.

I set DIMSTYLES and TEXTSTYLES through a script file from the pulldown menu. I've not found a good way to do this with MLEADER styles. Is there a command line setting that I can issue in a script file that will 'repair' the MLEADER Style by turning off the "Extend Leader to Text" option?

[zalant]

I checked the behavior with template files and I can confirm what you've found.  Also, I noticed that the checkbox was checked even for non-annotative mleader styles and styles in which I did not specify left justification.  Further, I used the Design Center to bring an mleaderstyle from one drawing into another, and along with that transfer, the checkbox for extending the leader to text became checked in the new drawing, while it remains unchecked in the source drawing.  It also holds for new drawings created via QNEW when DWGs are used as templates.

I did ascertain that this specific issue (checkbox becoming checked again) is currently under review by our software engineers.

Unfortunately, there is no related system or drawing variable which can be modified via the Command line, so at this point it is necessary to go in and uncheck the box.  

However, another alternative would be to save your template file (with that box unchecked) as a DWG file.  Then, make a copy of that file, just as a backup.  When anyone wants to start a new drawing, they could make a copy of that DWG file (named whatever they want).  Of course, by the time you do that, you could just as well uncheck the box in new DWGs created from the template.