NENTSELP

[jdanes]

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

 

[Rudy Tovar]

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: ?

 

[John Uhden]

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. :/

 

[jdanes]

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.