problem with ssget function

[Giuseppe Beatrice]

Hello, everyone.
I have a very strange problem with the ssget function.
with the selection option with single point (I am obvious sure that there is only one element that passes for it), I provide from program the coordinates of the point, performing in advance a "zoom all" to be sure that the point is in the screen... At this point I find that the element detected is not what I wanted but one close to it. if I then zoom the element found by ssget changes, and only with a very close zoom finally get the item sought.
precise that I disabled any "osnap", and that the result does not change if I try to select the object with a "_crossing" option and passing it two points (of course very close to each other to intersect only the sought entity).
Can you explain to me the ark? ?

 

[GP.]

attach a portion of the dwg with the incriminated objects and the code line, which we see.

 

[Giuseppe Beatrice]

I attach the portion of code that I "adjusted" with three zoom operations.
In practice I need to find the inserting points of the cable connection block to change the dynamic properties when I insert a junction box, so that the electric scheme merge readable remains.
I attach the test dwg file that I am using.
As you can see, the zoom performs a strong drip of the design, considering its overall dimensions.
the problem with the modified code no longer arises, but if instead I do not carry out such close zoom (pp_prec and pp are both points on the upper unifilare scheme) the ssget function does not return the sought block.

(command "_zoom" "_c" pp_prec 20 "");_ zoom enlarged on pp_prec to allow correct ssget operation
(setq cable_prec (ssname (ssget (polar pp_prec (- (/ pi 2)) 1)) 0) ;_ previous cable entity detected 1 mm below the lamp insertion point
(command "_zoom" "_w" pp pp_prec "")
(command "_zoom" 2 ")
(setq num_inters (ssget "_c" (polar pp_prec (- (/ pi 2) 25) (polar pp (- (/ pi 2) 25)));_ number of intersections to be calculated based on number of entities intersected on line 25 mm under pp and pp_prec
(command "_zoom" "_c" pp 20 "");_ zoom a all to allow ssget operation
(setq cable_corr (ssname (ssget (polar pp (- (/ pi 2)) 1)) 0) ;_ current cable selection with identical cable_prec modes).

 

[GP.]

I'm sorry. I don't think of anything.

Except I know the station. :biggrin:

 

[Giuseppe Beatrice]

Of course, to see that the famous, extreme precision of autocad (I don't remember how many decimals for the identification of a point), here goes completely in the ball, constitutes a bad blow!!

 

[Giuseppe Mauro]

Well I noticed that sometimes (probably to speed up operations) autocad takes into account what is currently viewing on screen.

I make a very banal example. try to insert a net through "pick point" in a very complex area, where there are a sea of elements.
autoca will ask if we really want to sample that area and on affirmative response, it will put us a little and we will get our selection (actually, sometimes wrong)
Try now to approach the area we want to sample, which is completely included in the screen, but trying to eliminate as much as possible other elements. the selection of the area will be infinitely faster and more accurate.

I wonder then whether even the ssget function has the same behavior.
If (as I think) the answer is affirmative, then the zoom extension you do at first is a real autogol.
try zooming around the ssget point before and after recalling ssget, to see the results.

I hope I've been clear (although I don't know how far)

 

[Giuseppe Beatrice]

In fact, that's exactly what I did, with a positive result.
I believe that autocad commetta errors of appreciation of a point even when this is passed extremely precisely by autolisp. are mysteries on which we poor mortals have no influence... and in the end we can also ask no more questions until we can solve with shortcuts.
anyway thanks for the clarification.