Bug catching...

[zph]

Good day!

Take a look at my code below:

---

(defun c:eqspace ( / adoc space basePoint counter ssPnt ssObjects)

(vl-load-com)
(setq adoc (vla-get-activedocument (vlax-get-acad-object)))
(vla-startundomark adoc)
(setvar "cmdecho" 0)

(setq counter 1)
(setq space -0.55)
;(setq space (getreal "\n\033\n  <#>  Spacing distance: "))

(if (setq basePoint (getpoint "\n\033\n  <.>  Select base point"))
 (progn
  (while  (setq ssPnt (getpoint "\n\033\n <.> Select objects reference point"))
  (setq ssObjects (ssget))
  (command "move" ssObjects "" ssPnt (list (car basePoint) (+ (cadr basePoint) (* counter space)) 0))
  (setq counter (1+ counter))
  (princ)
  ) ;while
 ) ;progn
 (progn
  (princ "\n\033\n <!> No initial base point selected <!> \n")
  (princ "\n * Aborting routine * \n")
  (exit)
 ) ;progn
) ;if

(setvar "cmdecho" 1)
(vla-endundomark adoc)
(princ (strcat "\n\033\n\033\n * Routine modified " (itoa (1- counter)) " selection sets * "))
(princ)
) ;eqspace

---

If you look at my test3.dwg, this routine will equally space subsequential selection sets to a defined spacing.  From left to right in text3.dwg, the 2nd and 3rd columns are the before and after.  However, executing this routine on the 1st column has unpredictable results.  If select the base point from the left side, the routine spaces them as intended, but if I choose base points that are located on the vertical line, the results can be that the lines are stacked on top and/or not with consistent spacing.

Why does selecting a base point that is located on an entity that isn't a member of the selection set and also vertical cause this?

Any help?

[hmsilva · Accepted solution]

Hi zph,

try to

(setq osm (getvar 'osmode))
(setvar 'osmode 0)

...

do your code, and

(setvar 'osmode osm)

worked as expected?

Hope this helps,
Henrique

[Kent1Cooper]

Do you have running Object Snap on?  I don't see anything in the routine that turns it off, and it will be applied in the Move command if there's anything Osnappable within Aperture range of the displacement points.  If it works right when you ensure that Osnap is off first, you can either build turning it off into the routine, or just put "none" Osnap calls just before the point designations in the Move command.

[zph]

How do I include the "none" Osnap inside the Move command?

[zph]

Thank you, hmsilva!

Yes, this worked. I am curious of how to include the osnap "none" within the move command though.

[Kent1Cooper · Accepted solution]

---

@zph wrote:
How do I include the "none" Osnap inside the Move command?

---

If you take hmsilva's suggestion, you don't need to, but if you want, instead of turning it off, you can do it for each pick, just as you would when Moving something manually, like this:

(command "move" ssObjects "" "_none" ssPnt "_none" (list (car basePoint) (+ (cadr basePoint) (* counter space)) 0))

When you don't have a lot of Osnappable moments to handle that way, as in this case, it takes a lot less code than saving the Osnap value and turning it off and back on later.  In routines that do a lot more that would be subject to Osnap, it's worth doing it by the OSMODE setting.

[Technically, you don't need more than the first three letters -- "_non" -- and in English-language versions of AutoCAD you don't need the underscore prefix.]

[hmsilva]

---

@zph wrote:
Thank you, hmsilva!

...

---

You're welcome, zph!
Glad I could help

Henrique

[zph]

I like the way you use "need" hahaha.

In this particular routine, I do prefer setting the Osnap within the move command.

Thanks again, Kent!