Determining extents of a block with LISP

[keithjk]

The following code is a snippet from a routine that I use to determine the size of blocks inserted in our drawings.  To better explain the problem, I modified the code to draw a polyline from the corners of the bounding box around the selected block.

If you open the attached drawing, and run the code below, you will see what the problem is.  The boundingbox for the block on the left is much larger than it should be but the bounding box on the right looks correct.  I believe the code is correct (but I have been known to be wrong!).

I have purged the block, recreated it and tried everything I can think of to erase any hidden entity that may cause my routine to think it is larger than it really is.  I have also found this happens on other blocks from time to time.

Any ideas??

(defun c:kk ()
  (vl-load-com)
  (setq obj (vlax-ename->vla-object (car (entsel))))
  (if obj
    (progn
      (vla-getboundingbox obj 'point1 'point2)
      (setq point1 (vlax-safearray->list point1))
      (setq point2 (vlax-safearray->list point2))
      (setq point1 (trans (list (car point1) (cadr point1) 0) 0 1))
      (setq point2 (trans (list (car point2) (cadr point2) 0) 0 1))
      (command "pline" point1 point2)
    )
  )
)

[Anonymous · Accepted solution]

Spline's causing the issue (see drawing)

Spline is colinear yet has 2 control verticies lying directly on the Spline.

If you change the Spline to "fit" (as opposed to "Control verticies") or remove either one or both of the verticies, extents will be calculated properly.

Not sure why this causes an issues but it does.

[keithjk]

I would have NEVER figured that one out.  Thank you!

[martti.halminen]

Another place where you'll find badly fitting bounding boxes is when you rotate a block on insertion.

- The only way around this I've found so far is exploding the block on insertion and re-building it in situ with another name.

If anybody has better ideas, I'd be interested.

-- 

[Kent1Cooper]

---

@martti.halminen wrote:

Another place where you'll find badly fitting bounding boxes is when you .... 

---

... have Mtext with its defined box width wider than its actual content.  Its bounding box goes to the former, rather than the latter.  To overcome that, there are threads on these Forums about shrinking its defined box width to match the width of its content.

[Jason.Piercey]

I've also had issues with HATCH objects that have been trimmed.  Sometimes the bounding box will be the original pattern extents instead of the newly trimmed extents.

Clipped blocks also don't play nice.  However, there might be a way to determine the clipped extents, I've not tried.

[Anonymous]

---

@keithjk wrote:

I would have NEVER figured that one out.  Thank you!

---

That's not true. You can do it.  You just need to step back from the problem a bit.  Here's how you'd figure it out....

First, I have my own "extents" program that works off of a selection set, not a block. You could easily modify your code to do that from what I've seen. That would also make for a more "flexible" "extents" subroutine you could use in other programs in the future.  From there...

Exploded the block and run the Entents program.  Does the problem persist?

Delete 1/2 the objects and run again. Does the problem prersist?

If not, undo the delete and then delete the other half and run again. Does the problem persist?

Repeat as nessicary until you've identified the problem object(s).

It doesn't take nearly as long as you'd think.

From there, once I identified the spline, I played with it a little. Converting to "Fit", removing any 1 or both of the control verticies or even moving a control vertex off of the spline yielded the proper results.

From there, you can then determine how to solve the issue. If you have control of the block, you can fix it that way, or modify your code to dig into the guts of a block and handle entity by entity or any other number of ways to work around the issue like making a copy of the block, exploding the heck out of it (even exploding the SPLINE which may be work in it's own right) and calculating the extents of the native objects, then deleting them all.