Bug with vla-getboundingbox from entlast causes incorrect calculations

[erichter]

I have an AutoLISP script whose function is to insert all blocks within a folder,and order them sequentially in a descending column in the Y direction starting at (0,0). An earlier version of this script had a prompt for vertical spacing, but this version calculates the position to move the blocks based on the height of the last inserted block. When I run this command for multiple folders, I'll slide the column horizontally and then run for an additional folder.

This script works fine if I only run it once, however, if I had run it previously and am running it an additional time, it is possible for the block positions to get messed up when I run it again. Even more confusing is that the Y positions will be decimals even ever performing a Lee Mac rounding function.

In testing, I can replicate the error consistently depending on the previous import folder, and it seems like the content in the new folder doesn't matter in generating the bug.

Does anyone know what is causing this bug, and how can I avoid it?

For the record, I am using AutoCAD Mechanical 2024.

(defun c:BI ()
(vl-load-com)
(vla-StartUndoMark (setq *DOC* (vla-get-ActiveDocument (vlax-get-acad-object))))
(if (and (setq dpath (getfiled "Open a file in the DXF folder" (strcat (getenv "userprofile") "/Documents/") "" 8))
);; and

(progn
(setq
dpath (substr dpath 1 (- (strlen dpath) (vl-string-search "\\" (vl-list->string (reverse (vl-string->list dpath))))))
dxflst (vl-directory-files dpath "*.d*" 1)
pt '(0. 0. 0.)
);; setq

(foreach dxf dxflst
(command "-insert" (strcat dpath dxf) '(0. 0. 0.) "" "" "")
(vla-getboundingbox (vlax-ename->vla-object (entlast)) 'minpt 'maxpt)

(setq
blkLL (vlax-safearray->list minpt)
blkUR (vlax-safearray->list maxpt)
objht (LM:roundup (+ 3 (- (cadr blkUR) (cadr blkLL))) 1)
pt (list 0. (- (cadr pt) objht) 0.)
);; setq

(command "move" (entlast) "" "" pt)

);; foreach
(command "_zoom" "E" "")
);; progn
);; if
(princ)
(vla-EndUndoMark *DOC*)
)

(defun LM:roundup ( n m )
    ((lambda ( r ) (cond ((equal 0.0 r 1e-8) n) ((< n 0) (- n r)) ((+ n (- m r))))) (rem n m))
)

[ВeekeeCZ · Accepted solution]

1) make sure that OSNAPs are OFF. (osnapcoord 1)

2) localize all the variables.

[erichter]

1. Setting osnapcoord to 1 fixed the issue. Setting osmode to 0 also works, but requires switching back, so I think osnapcoord is more elegant.

2. Localizing the variables doesn't seem to have an effect.

Just curious, can you explain why osnap has such a weird effect here?

[john.uhden · Accepted solution]

@ВeekeeCZ and @erichter ,

What's often simpler is...

(command "_.move" (entlast) "" "" "_non" pt)

[john.uhden]

@erichter ,

In a less brilliant manner than @ВeekeeCZ , I offer my less educated explanation:

The point pt might lie within the aperture so as to pick up an entity, and if your running object snap is set to say endpoint (as it probably often is) then if the point selected is on a curve segment (arc, line, etc.) it will return the closest endpoint of the entity it picked up.  This can be true for any of the object snaps as they might apply.  Turning object snaps off precludes that occurrence.  Inserting "_non" before a point input does the same thing but for only the pt that immediately follows. "non" is short for "none" which is short for "no object snaps."