One thing you can do is to work with the Coordinates VLA property, rather than the entity data.
Make it a VLA object stored as a variable:
(vl-load-com); [if needed]
(setq obj (vlax-ename->vla-object (car (entsel "\nSelect a Polyline: "))))
Then:
(vlax-get obj 'Coordinates)
returns, for a [my simple example] 12w x 6h rectangle with its starting lower left corner at 0,0 and drawn counterclockwise:
(0.0 0.0 12.0 0.0 12.0 6.0 0.0 6.0)
That is a list of coordinate values, strung out and undifferentiated, but in order. In the case of a LWPolyline, there are only X and Y coordinates [the Z coordinate is common, and stored as the Elevation property], so there will be two numbers per vertex -- the first two are the X & Y of the first vertex, the next two of the second vertex, etc. In the case of a "heavy" Polyline [2D or 3D], there are XYZ coordinates, so there will be three numbers per vertex. It's not difficult to pull the pairs or triads of numbers apart into separate point lists, and you can play with those and (append) them back together into the undifferentiated list again.
Say you want to move the upper right corner of that rectangle up 1 unit. That means the third vertex, represented by the 12.0 6.0 pair, needs to be 12.0 7.0 instead. You would manipulate the list to change it to:
(0.0 0.0 12.0 0.0 12.0 7.0 0.0 6.0)
Then you can impose that revised list of coordinates back on the Polyline this way:
(vlax-put obj 'Coordinates '(0.0 0.0 12.0 0.0 12.0 7.0 0.0 6.0))
[If your Polylines may ever have arc segments, be aware that the results could be peculiar -- all the above does is replace the vertex locations, but it doesn't change things like arc-segment bulge factors.]
EDIT: But you can also do it with entity data. If 'edata' is a variable holding the entity data, then:
(vl-remove-if-not '(lambda (x) (= (car x) 10)) edata)
extracts just the vertex location entries into a list, such as [for the same example rectangle]:
((10 0.0 0.0) (10 12.0 0.0) (10 12.0 6.0) (10 0.0 6.0))
You can work on the third item so that you get:
(10 12.0 7.0)
On the assumption that vertex locations will all be unique [they certainly should be, or you've been drawing wrong], you could then (subst) that new one in place of the old one, with no risk of its finding the wrong (assoc 10) value:
(entmod (subst '(10 12.0 7.0) '(10 12.0 6.0) edata))
[Same caveat about arc segments.]
But the advantage of the Coordinates VLA Property approach is that it will work on any variety of Polyline, whereas that entity-data approach will work only on LWPolylines. [Something entity-data-based could also be done for "heavy" ones, but it would have to work differently, involving (entnext) to step through vertices.]
Kent Cooper, AIA