NENTSELP

We are using a routine to interactively select object in a drawing using
NENTSELP. There is a huge problem with NENTSELP in very large or congested
drawings or drawings with large xref attachments. The function gets very
bogged down and can take 20-40 seconds to return a value. Our assumption is
that NENTSELP is reading far too deeply into complex objects in the drawing
screen. Is there a means to filter out objects to NENTSELP or a system
variable to prevent it from reading so much uneeded entity information in
the drawing screen ? Or is this just a harsh fact of life with NENTSELP ?

Thanks

Jesse Danes

 

What exactly are you using the function for?

You mentioned xref files, but what information are you gathering and
settting?

Is 'NENTSELP' being used with a point? (nentselp <point>)?

Or are you defining the point after the actual function? (nentselp)Select
Object: ?
--

AUTODESK
Authorized Developer
www.Cadentity.com
MASi

 

My guess is that you are using (nentselp) within a (grread) loop. If that's the
case, then you should expect a delay. But 20-40 seconds seems extraordinarily
excessive. Could be that:
(a) the drawings *are* really monsters, or
(b) the PC's are dinosaurs, or
(c) the code within the (grread) loop may be somewhat inefficient, or
(d) some of the above, or
(e) all of the above. :/

 

the function is indeed being used within a GRREAD loop. NENTSELP is being
used to
identify objects located at points returned by GRREAD. The loop itself is
rather lengthy
but is structured within COND statements. The drawings where this delay
occurs *are*
monsters. When tested on smaller drawings the routine appears to run quite
smoothly.
I am running a PIII 451, so by typical standards this probably is a
dinosaur, atleast I am
counting on this to be the case.

In any event, I've tested the NENTSELP function alone in some of these large
drawings
by simply typing ...

(setq pname (getpoint));; select point close to obect
(nentselp pname)

The result is the same, a lengthy delay for a returned value. The GRREAD
loop and
nested function calls are about as efficiently written as they can be all
considered and
don't appear to be accounting for much of the delay time at all.

An interesting observation, within the GRREAD loop when the cursor is moved
in an
area outside or away from an xref, it pans smoothly. When it's moved within
a certain
distance of an xref or congested drawing area, it begins to slow down.
xref's or other
drawing objects seem to make no difference, either way.