Multi-Leader Missing Grips

[ToddRogers-WPM]

Has anyone else ever seen this before?  And if so, do you have a fix?

Problem:  This multi-leader is missing grips.  It's the same multi-leader style as the one to the left with grips...

[scot-65]

A shot in the dark:
Command -Dimstyle "Apply" and select the troubled leader?

Sometimes our dimensions lose their grips except the text grip, and running this fixes the problem. I'm still not sure why this happens in the first place...

???

[ToddRogers-WPM]

No dice.  I have attached the drawing in question...

[zalant]

I did a LIST command on one of the working mleaders and one of the non-working mleaders. The difference appears to be the Z value. For mleaders that work, the Z value is 0 (zero). For those which don't have all the grips, the Z value is 1.0000000E+99.

To fix an affected mleader, first do a LIST on it. Record the X and Y values of the second vertex. Execute the MOVE command, specifying the middle joint as the base point. Then, type in the X and Y values you recorded, and put in a 0 for the Z value. That should get all the grips back for that mleader.

Were there only a handful of them like this, it would be relatively quick. For as many as there are in this drawing, though, it could take quite some time. I tried using the FLATTEN command, but it didn't work. You might be able to track down some LISP routine out there which could do this for all the objects, and that'd probably fix them all up.

[ToddRogers-WPM]

Thanks for the reply @zalant.  Yeah I noticed that too.  Problem is, what caused this to happen?  

[itbemedg]

To quickly move the z to zero, use the change command, select properties, and select elevation, enter 0.

[ToddRogers-WPM]

Didn't work.

[zalant]

So, by using crossing windows, I was able to relatively quickly isolate the "good" from the "bad" mleaders. I placed the bad ones on another layer, then locked and froze the original layer (with the good ones still on it). I selected all the bad mleaders, which then showed a single grip. I got the coordinates for that grip, then used its X,Y values as the desination point for a MOVE command (entering 0 for the Z value). Finally, I thawed and unlocked the original layer and put all the fixed mleaders back onto it. The result is attached to this post.

As to how these mleaders came to be this way, there's no way to know for certain, as I don't know the drawing's history. My best guess would be that the original objects to which the mleaders were object-snapped all had the same non-zero Z value as the bad mleaders.

[ToddRogers-WPM]

Awesome.  Thanks for that.  I am currently working on a lisp routine that seems to be working.  I will share once finished.

[ToddRogers-WPM · Accepted solution]

As promised.  See attached...

[zalant]

I admittedly know next to nothing about LISP. I've loaded up your file and tried MLFL at the Command line, but I'm getting "Unknown command". What should I be doing, instead?

[ToddRogers-WPM]

Did you do APPLOAD to load it?

[zalant]

Weird. I just tried it again, and now it's working fine. Very strange. I had a colleague try it before, and it wasn't working for either of us, between a few different computers. Yes, we were both using APPLOAD, and, while it was loading successfully, it just wasn't being recognized as a command. All good now, though. Oh well. It does take care of the non-zero-Z mleaders quite nicely.

[russ1980]

I had the same problem, I fixed it by selecting the problematic leaders, going to object properties and changing the "Annotative" setting from "No" to "Yes".