change all points of an object
As with your other thread about Polylines specifically, MOVE will do this without all the shenanigans. Is there some reason not to do it that way?
Kent Cooper, AIA 
@Anonymous wrote:
.... some objects have only the 10 DXF code defining its point, some 10 and 11, and some with many 10s?
....
Further thoughts, if MOVE isn't the answer for some reason....
Splines can have many 10s and many 11s.
Dimensions and Multilines are defined using further such locational code numbers -- 12, 13, etc., up as far as 16 in the case of some Dimensions.
Left-justified Text has its insertion point stored in the 10 slot, and its 11 slot is always 0,0,0, no matter where the Text is located. I was expecting that a generic routine that altered all 10- and 11-code entries for any kind of object by the same amount might cause an error, or at least give unexpected results. But in a quick experiment, it seems that substituting different coordinates into the 11 slot in that situation is simply ignored.
But it certainly would be possible for a routine to find all such locational entries, calculate new coordinates for each based on a specified displacement, and (subst)itute replacements in for them all. [I'm even willing to take a shot at that, if there's some valid reason not to just MOVE things.] But it would not be without its possible problems. For instance, if a routine does that with a given [let's say] Polyline vertex, and that results in its being moved to the same location as a later vertex in the same Polyline, then when it gets to processing that later vertex, (subst) will reposition not only the intended vertex entry but also the previous one that ended up in the same place, moving it yet farther from its original location. MOVE can't have that problem.
Kent Cooper, AIA
@Anonymous wrote:
... you could use the vla-move command as follows:
Given e is bound to an ename, p1 is bound to a point list, and p2 is bound to a point list
(vla-move (vlax-ename->vla-object e) (vlax-3d-point p1) (vlax-3d-point p2))
....
If you have ... an angle in radians and distance instead of 2 points, then get point p2 by:
(setq p2 (polar p1 ang dist))
....
If you're going to Move it after all, rather than replace locational entries in entity data, the (command) function is a lot easier. No dealing with VLA object conversion, variants, 3D points when you're operating only in 2D, etc. Given two known points:
(command "_.move" e "" p1 p2)
[with "_none" Osnap calls before those points if running Object Snap might be on]. Given a known distance and angle [original concept, Post 1]:
(command "_.move" e "" '(0 0 0) "@YourDistance<YourAngle")
[again accounting for Osnap if necessary] which will take the angle in degrees if those are your current angle units [no radians conversion required], and with no need to know or calculate any points at all [that '(0 0 0) can be anywhere -- (getvar 'viewctr), or "@", or...].
Or, using the first-"point"-is-really-displacement approach:
(command "_.move" e "" (polar '(0 0 0) YourAngle YourDistance) "")
[which will want the angle in radians].
Kent Cooper, AIA
@john.uhden wrote:
Another way would be to wblock and insert exploded at a new coordinate; no DXF codes needed :]
That and using Move and other possibilities [such as by way of the Clipboard -- no creation of an external drawing file involved] have the advantage of being able to do it to any number of objects together, not just one. But I hesitate to delve any further into the whole thing without hearing back from @Anonymous about whether there's some reason to want to manipulate entity data to do it, rather than use one of those more direct methods.
Kent Cooper, AIA