odd behavior: execution problem where the command only works when I run it twice

[Anonymous]

Hello experts,

This odd behavior is not logic and difficult to reproduce, but is making a mess in the process.

Below is an attempt to reproduce the problem. (I cannot say when the problem happends, only where) 

When running it manually "command by command" I have notice that sometimes after last "boundary" command the (entlast) result is equal to entED... and (I think) shouldn't be the same. After repeating the "boundary" command (entlast) get a different value. (most of times the code below is working)

(setq entLT (car (entsel "\nSelect Object: ")))
(setq objLT (vlax-ename->vla-object entLT))

(setq OutSidePoint (getpoint)) ; select an OusidePoint

(setq InsidePoint (getpoint)) ; select an InsidePoint

(command "offset" 10 entLT OutSidePoint "") ; offset towards outside

(setq entED (entlast)
          objED (vlax-ename->vla-object entED))
(vla-put-layer objED "ED_TEMP")

(command "_.-boundary" "_non" InsidePoint "")
(if (equal entED (entlast))
     (command "_.-boundary" "_non" InsidePoint "") ; because only works at the second running
)

What am I forgeting here?

Thanks in advance + regards

[dlanorh]

The (entlast) shouldn't be equal to entED. I suspect this is a database update problem where you are assigning entlast before entlast has been updated. You can test by inserting a (command "delay" time_in_millisecs)

or if you want to use a lisp you can use this snippet

;; Reini Urban:
(defun STD-SLEEP (secs / et)
(setq et (+ (getvar 'date) (/ secs 86400.0)))
(while (< (getvar 'date) et) T)
)

[doaiena]

If i remember correct, the "boundary" command is view/zoom dependent. The only way you can reach the second boundary command is if the first one fails and does not create a new entity. I suppose that, depending on the viewpoint and/or type of geometry you are using, when the first boundary command fails, the drawing regenerates and then the second one runs.

Throw in this line before the boundary command and see if it works as expected.

(command "_zoom" "o" entLT"")

[Anonymous]

Hi @dlanorh 

How many seconds/miliseconds its necessary for a database update? Once my routine will handle thousands of polylines I would like to use the minimal necessary wait time.

Hi @doaiena  

The first attempt with zoom worked, I'm still testing on large scale drawings (thousands of polylines).

Thank you both

[doaiena]

The "entlast" assignment happens automatically with every entity creation. It's an operation than happens under the hood and can't be skipped over, in a single threaded environment such as autolisp.

_$ (entlast)
<Entity name: 33acb810>
_$ (command "line" p1 p2 "")      <------ entlast is set here. You can't run the next block of code before this one is done
nil
_$ (entlast)
<Entity name: 33acbbd0>

[Anonymous]

@doaiena  in theory is exactly that and I was expecting not having this issue

but what @dlanorh  mentioned makes a lot of sense, because explain "perfectly" the code odd behavior

and why (entlast) still have the value of the previous assignment

In my experience on programming (other languages) I saw unexplained things happend.

So, this bug/error its not impossible.

[doaiena · Accepted solution]

The problem you are observing is a result of AutoCAD's optimizations. In bigger drawings, acad simplifies geometry, so that your viewport doesnt slow down to a crawl. Some of acad's commands rely on having the geometry on screen and not simplified, in order to work. 

The (entlast) function failed, because the "boundary" command couldn't read the true shape of your geometry and exited without creating a new boundary. So in your drawing the last entity is still the offset you made last, there was nothing new added.

Make a small test for me. Run your code by hand and once you get to the boundary command, PAN the viewport, so that your geometry is not visible on the screen. Then run the line with the "boundary" command and see if the "boundary" command works. Also try the same thing, but instead of panning, ZOOM out a lot, and run the line again.

You'll see that once the geometry is not on the screen, the "boundary" command will always fail. Zooming out will make the "boundary" command fail sometimes, depending on the complexity of your test geometry and the zoom level, other times you'll just get a resulting boundary that is not as expected, because of the shape simplification that the acad optimization algorithm has applied.

[dlanorh]

---

@Anonymous wrote:

Hi @dlanorh 

How many seconds/miliseconds its necessary for a database update? Once my routine will handle thousands of polylines I would like to use the minimal necessary wait time.

---

Impossible to say. It depends on the size of the drawing, the processor speed etc. Pick a number, test it. If it works halve it and try again