Special closed polyline filters?

I thought the following was good but it's not:
(ssget "x"
'((-4 . "&")
(70 . 1)
)
)

I'm trying to select only closed polys -- light or heavy. The old ellipses
are okay (pellipse = 1) but only the None and Fit, not the Quadratic or
Cubic.

Can someone help with a proper set of filters?
Len Miller

 

(setq sset(ssget "x" '((0 . "*polyline")(70 . 1))))

 

This seems to work:

(ssget "x" '((0 . "*POLYLINE")(-4 . "<OR")(70 . 1)(70 . 3)(70 . 4)(70 .
129)(70 . 131)(70 . 132)(-4 . "OR>")))

 

(SSGET "X" (LIST (CONS 8 "0")'(0 . "POLYLINE,LWPOLYLINE")'(-4 . "&")'(70 . 1)))

I think Paul T. posted this once.

Bill

 

forget the layer (if you want).

(SSGET "X" (list '(0 . "POLYLINE,LWPOLYLINE")'(-4 . "&")'(70 . 1)))

 

(SSGET "X" (list '(0 . "POLYLINE,LWPOLYLINE")'(-4 . "&")'(70 . 1)))

As long as we're on the filter-optimizing kick, I liked the wildcard usage

(SSGET "X" '((0 . "*POLYLINE") (-4 . "&") (70 . 1)))

 

Interesting, I'm just the opposite. I prefer to specify
each entity type.

 

Interesting, I'm just the opposite. I prefer to specify each entity type.

Sometimes you see some clever tricks to abbreviate filter lists. I liked
this one just because it reduced the verbosity in specifying both flavors of
plines -- spelling them out wouldn't make it any more clear for me.

Wildcards are frequently useful for me in filtering for block names, only
because we use highly consistent naming conventions. When I do a trick like
that, I'll add comments elaborating on my block name assumptions. So
ultimately it doesn't reduce the total amount of text in the lisp, but it
slims down the code itself.

 

The only problem with the wildcards is if Autodesk
introduces new entity types it may cause you some
unwanted selection set filtering.

You may need to go back and revise *all that code*
to make them behave as they were intended. OTOH,
you could also say the same for wanting the new types
included in the selection set.

6 one way, half a dozen the other.

 

6 one way, half a dozen the other.

I agree on both counts. If I'd been using '(0 . "*text*) to include mtext,
God only knows what some of those those functions would have done with rtext
when it appeared. Got any inside leads on new kinds of plines coming down
the pike?

 

"*text" that is

 

If I told you, I'd have to kill you

Seriously, I know nothing about any new polylines.

 

It does, indeed. I created a test drawing with a variety of 16 entities
including plain lines, arcs, circles, regions, heavy polys, and light polys.

Your snippet caught all 9 correct ones. My notes said that okay codes are
1, 129, 131. Not okay are 128, 133.

How did you derive the 3, 4, 131 and 132?
Most Grateful, Len

 

Your code fetched 2 heavy and 1 light polylines of possible 3 heavy and 6
lights. I thought you'd like to know.

Thanks, Len

 

Your code got 5 heavy and 6 light polys of possible 3 heavy and 6 lights. I
suspect the 2 extra heavies were the quadratic and cubic ones.

Thanks, Len.

 

Hi Len,
To tell you the truth, now that I look at it again, I'm not sure how mine
passed all the tests. 4 & 132 should not be included and I don't have a clue
how those got in there..... ;-)
However, 3 should be since you said Fit curves are OK. Fit = 2 + Closed = 1
= 3, which also will include 131 (128 + 3).

--
Jeff
check out www.cadvault.com

 

I looked further and found those bits, listed only under HEAVY polyline
help.

For those lurking:
1 = This is a closed polyline (or a polygon mesh closed in the M direction)
2 = Curve-fit vertices have been added
4 = Spline-fit vertices have been added
8 = This is a 3D polyline
16 = This is a 3D polygon mesh
32 = The polygon mesh is closed in the N direction
64 = The polyline is a polyface mesh
128 = The linetype pattern is generated continuously around the vertices of
this polyline



Therefore (my understanding) 1, 2, 3, 128, 129, 130, 131 - are okay.



But -- when my code contains those numbers my accepted set is now up to 11
instead of 9. The incorrect ones are open polys, one light and one heavy.



I've gone back to your original suggested code, coming up with the right
number I've, one by one rechecked the handles in the Vlide Watch Window,
comparing with the handles at each entity that I've printed on the drawing
next to each. Perfect.



Go figger!

Len



ps: I will be happy to attach my drawing, some 53K, if asked.

 

I'd better clarify. Since my original post I've added two open polylines,
one heavy and one light. However, the original number of 9 acceptable still
applies.

 

This gets open ones...
(ssget "X"
(list
'(0 . "*POLYLINE")
'(-4 . "<NOT")'(-4 . "&=")'(70 . 1)'(-4 . "NOT>")
)
)

This should get closed ones...
(ssget "X"
(list
'(0 . "*POLYLINE")
'(-4 . "&=")'(70 . 1)
)
)

 

It's not pretty (I don't know the streamlined stuff) but I tacked onto your
second example some code to exclude the cubic and the quadratic polys -- and
it finally works (at least for my test drawing), getting 9 qualified
entities:
(ssget "X"
(list
'(0 . "*POLYLINE")
'(-4 . "&=")
'(70 . 1)
'(-4 . "<NOT")
'(75 . 5)
'(-4 . "NOT>")
'(-4 . "<NOT")
'(75 . 6)
'(-4 . "NOT>")
)
)