Get selection defined by polyline doesn't always work

[JBW_AIScripts]

I created a script that counts the number of blocks inside shapes in a selection en masse using Lee Mac's "Entity to point list" script in a polygonal window crossing selection. It works great except for some polylines that refuse to capture anything in the selection. I tested it and the "Entity to point list" function works just fine. If offending polylines are exploded and then recreated individually with the join command, they work like normal.

I need help debugging the script so it captures the selection of blocks inside all polylines. My only idea for how to do that is to explode polylines when they come up with a "0" selection, run the "join" command on the results, and check the resulting polyline again.

Attached is my script and a test document with mostly nonworking polylines and one working for a control.

Thanks to anyone who can help!

[Kent1Cooper]

I think those Polylines that don't work all have coincident vertices and therefore zero-length segments, which is known to cause all kind of problems with various AutoLisp operations.  [For example, both the "A" and the "C" outlines have their vertices 1 & 2 in the same place, but it's not the same in all of them.  The outer and inner outlines of the "o" each have three vertices in the same place.]

OVERKILL fixes that, but does odd things to the shape of the "T" [and perhaps less noticeable odd things to other shapes].

BUT I don't understand how it's supposed to work.  The only defined command in the routine asks only for selection of Blocks, not Polylines.  What is the step-by-step User procedure supposed to be?

[JBW_AIScripts]

Thanks for the quick reply! Could one potentially make a function that eliminates coincident vertices from the point list? I want to leave the original shapes unchanged, but I don't care if the selection point list is slightly different.

[Kent1Cooper]

[I added a paragraph at the end of my earlier Reply while yours was coming in -- see that first.]

There are certainly routines out there to eliminate coincident vertices in Polylines.  Whether any do it to a vertex list only rather than to the Polyline itself, I couldn't say.

[JBW_AIScripts]

My bad, I accidently messed up the filtering on the main selection. I had it looking for more specific filtered shapes along with blocks and was careless adapting the code for the debug. Attached is a new version that should work with the example.

The basic idea is the user selects all the blocks they want counted and all the shapes they want checked for the number of blocks they contain. The program makes a sublist of blocks and tests against that to find if it is a containing shape.

[Kent1Cooper · Accepted solution]

So now for me, it works after OVERKILL, though not fully until I run OVERKILL a second time on the "A" outline.  And there's the "T" alteration issue....

I'll let you Search for routines to fix coincident vertices -- one would hope there's something out there that does it without changing any shapes as OVERKILL can.  I did something once called PLFixClose.lsp that does it when there are two coincident vertices at the start/end location [i.e. when a Polyline was drawn around all the way back to the start location and then Closed, rather than Closed from the last location other than the start], but that's not the situation in those of yours that I looked at, though it's close for the "o" outlines.

[JBW_AIScripts]

Thanks for your help. I think I can figure it out from here!

[Sea-Haven]

Just a comment from past experience when using SSGET "CP" pts you need to close the point list, if you say use a rectang you get 4 points but if you look at the list of points you have a "U" I always re-add the last point to the list of points so it becomes closed.

(setq co-ord (mapcar 'cdr (vl-remove-if-not '(lambda (x) (= (car x) 10)) (entget (car plent)))))
(setq co-ord (cons (last co-ord) co-ord))