entprev?

[Anonymous]

It's easy to find the *next* object in the drawing with entnext, but any easy way to find the *previous* object? Doing an ssget X and scanning until current object is taking 30 seconds on a large drawing.

--J

[Anonymous]

How many entities are in your drawing? I tested a quick lisp on a drawing
with 36000 lines. No performance issues seen.

Ken Hutson

[Anonymous]

Haven't tried, but . . .
(command "undo" "begin")
(entdel(entlast))
(setq x(entlast))
(command "undo")

rs

wrote in message news:5155250@discussion.autodesk.com...
It's easy to find the *next* object in the drawing with entnext, but any easy way to find
the *previous* object? Doing an ssget X and scanning until current object is taking 30
seconds on a large drawing.

--J

[Anonymous]

Bob, I don't think you got the undoing quite right -- you'd need to end the undo group, then do a simple "u" to perform the undo.

Another approach, also untried, would be to use the double entdel trick to restore the last entity.

(setq lastent (entdel (entlast)))
(setq nexttolastent (entlast))
(entdel lastent)

[Anonymous]

Yeah.. that would return the next to last entity in the database.. But I got
the idea the problem was to return the entity drawn prior to a selected
entity?

Ken Hutson

[Anonymous]

II guess you're right. In that case I don't know how you'd avoid stepping through the whole drawing.

I wonder what the purpose would be in finding the thing drawn just before another thing?

[Anonymous]

I have no idea why. Might want to get the handle of the selected entity and
start a loop from there with a hexadecimal counter until the handle of the
next (previous?) entity is encountered from the selection set.

Ken Hutson

[Anonymous]

the purpose behind it all:
an old arc leader function would create its objects, and add the 1005 markers. But I didn't create a link on the arc object to the object being called out (seemed rather silly to do something like that). And then along comes the desire to be able to click on the arc, and slide the callout along the length of the object being called out.
So yeah, file under Always good to prepare for future expansion, or something like that.
thanks for brainstorming with me.

--J

[Anonymous]

I've got a fairly typical drawing here, 12,000 some-odd entities, and a basic loop of:

(setq tempss (ssget "X" (list -3 (list APPNAME))) i 0)
(while (< i (sslength tempss))
(setq entx (entget (ssname tempss i) (list APPNAME))
xdat (cdadr (assoc -3 entx))
) ; setq
(if {condition on xdat and/or entx}
{super secret magic code}
) ; if
(setq i (1+ i))
) ; while

takes a good 30 seconds.
I get a lot of these large drawings, and this seems par for the course.
Is the performance hit in selecting RegApp'ed objects? Or in a drawing not being all clean Lines? Or what?

--J

[Anonymous]

I know I should, but I don't regularly use undo in my little macros; hence the booboo.

If the problem is to find the preceding object to a selected one, Here's a suggestion: An
object's handle never changes. But owing to deletions etc. there will be holes between
handles. So we can't look for (Handle - 1), we need the preceding object, which might be
(Handle -28). A binary search of the database will show the numerical index of the
selected object with an efficiency considerably better than simply examining each object.

How does one do a binary search in a selection set?

rs





You don't know where in the data base your selected object is.
wrote in message news:5155533@discussion.autodesk.com...
Bob, I don't think you got the undoing quite right -- you'd need to end the undo group,
then do a simple "u" to perform the undo.

Another approach, also untried, would be to use the double entdel trick to restore the
last entity.

(setq lastent (entdel (entlast)))
(setq nexttolastent (entlast))
(entdel lastent)

[Anonymous]

no, in this case it would be one after the other.
the 2 objects were created right after each other.
in which case, I bet you're right, I could just look at the handle and come up with an equivalent to (entprev).
hmmmm....

--J

[Anonymous]

I tested the code below on a drawing consisting of 25984 entities. The
entities consisted of 22528 mtext and 3456 lightweight polylines created by
an in-house program which added extended data when they were created. Not
noticing any performance hit.

(defun c:stub (/ ent ss1 count)
(setq ent (car (entsel))
ss1 (ssget "X")
count 0
p nil
)

(while (< count (sslength ss1))
(if (eq ent (ssname ss1 count))
(progn
(setq p (ssname ss1 (+ count 1))
count (sslength ss1)
;do some secret thing to p
)
)
(setq count (+ count 1))
)
)
)

[Anonymous]

Kenneth,

but your code doesn't do anything. of course there will be no performance hit.
The major hit would be adding:
(setq ex (entget (ssname ss1 count) (list APPNAME)))
beyond that, obviously a (cdadr (assoc -3 ex)) and some comparisons don't add anything. it's all the calls to entget that slow it down.

--J

[Anonymous]

IMHO...list processing is list processing. It's the same whether it's
extended data or regular definition data. No different than processing
multiple vertices of a polyline or nested block entities. What is the file
size on disk?

Ken

[Anonymous]

no, I'm saying the performance hit is the entget call.
add an entget call to your loop and tell me it still runs instantly.

--J

[Anonymous]

This one does entget 100 times... just as fast as before. Never said it ran
"instantly". Said no performance hit seen.

(defun c:stub (/ ent ss1 count i)
(setq ent (car (entsel))
ss1 (ssget "X")
count 0
i 0
p nil
)

(while (< count (sslength ss1))
(if (eq ent (ssname ss1 count))
(progn
(setq p (ssname ss1 (+ count 1)))
(while (< i 100)
(entget p)
(setq i (+ i 1))
)

(setq count (sslength ss1))
)
(setq count (+ count 1))
)
)
)

Ken

[Anonymous]

100 times?
try 12,000, that's where the performance hit occurs.
hence, doing an ssget X is unfeasible.

--J

[Anonymous]

I'm with Jeremiah on entget speed. It's one of the slowest things you can do in lisp, and I would naturally expect it to bog down a routine noticeably if it needed to run thousands of times.

For example, on a large enough selection set to see the difference, ssget filtering is way faster than stepping through an unfiltered sset and doing an entget on every member.

Though of course all of this is relative to machine speed, and what you consider to be adequate performance. I do things nowadays that I never would have done in the days of much slower computers, because the performance isn't unacceptable as it once would have been.

[Anonymous]

the sad part is twofold:
1, I got used to ssget being instant, and started adding cool ssget "X" verification routines throughout the system. but with these large drawings, can't do that.
2, I still can't ssget filter for any extended entity data filters, so stepping through the entire drawing is still necessary, unless I want to chop up everything into different application names.

--J

[Anonymous]

Try this

(defun Second2LastEnt (/ LastEnt ss Ent)

(setq LastEnt (entlast))
(setq ss (ssget "x"))
(vl-catch-all-apply
'(lambda ()
(while (setq Ent (ssname ss 0))
(if (equal (entnext Ent) LastEnt)
(exit)
(ssdel Ent ss)
)
)
)
)
Ent
)

--

Tim
"A blind man lets nothing block his vision."



wrote in message news:5157248@discussion.autodesk.com...
the sad part is twofold:
1, I got used to ssget being instant, and started adding cool ssget "X"
verification routines throughout the system. but with these large drawings,
can't do that.
2, I still can't ssget filter for any extended entity data filters, so
stepping through the entire drawing is still necessary, unless I want to
chop up everything into different application names.

--J