News:

DesignCAD 2016 and DesignCAD 3D Max 2016 now available for sale. New features include an insert manager for managing a drawing's symbols, block, and images; and the ability to add custom properties to any entity or drawing.https://www.turbocad.com/designcad/

After playing with it a bit, I see that using move-to-back is a mixed blessing.

While it does make the <pointxyz parameter unambiguous for selecting entities in a macro function, changing the display order also changes the entity number, creating a new record keeping requirement to track entities of interest.

The necessary coding is nontrivial, even for an experienced user who would prefer to spend his time on more productive pursuits.

Unless someone has a better idea, it is time for an <entity [n] parameter.

The parameter could be used alone or as a constraint to the <pointxyz[] parameter, depending on the function.

I am with you on this. The fact that selecting entities using PUTATTR do require a >SetHandle before I can do a reliable >Move is of course crazy.

I am now working on a new version of my PushApart.d3m using >PointSelect. As you said there is no guarantee that the right entity/object is selected when entities/objects share the same point. DT pointed me to >ID_SELECT_NEXT to select the next entity/object until the right entity(ies) is/are selected.

From my view we should not fiddle with existing good working function interfaces; I don't trust the programmers to tell the truth. I much rather have a new BasicCAD function along the lines of:

SELECTENTITY type, ent

If type is 0 then select only entity ent, and if type is 1 then select all entities related to ent, e.g. all group entities, or all solid entities, and in such a way that the in that way selected entities can be moved without having to set a handle first.

It changes the display order, (therefore the entity number), to the bottom of the list.

The <pointxyz parameter (used by functions such as >parallel and >Inersect2 to identify the entities to be used as operands) works only on the lowest entity number sharing the xyz point.

The only clearly reliable way I can see to make your entity work with the Intersect2 function is to use the movetoback function to change each selected entity number to 1 (the others push up).

Once the entity number is changed, if you need to change it back you could use the movetobackof command or the movetofrontof command. But those commands both use the <pointxyz parameter also. So you are trapped in an endless spiral.

The only way I can see to restore the original entity numbers is with a "towers of hanoi" stacking process, using movetoback.

On further consideration, putting trimmed entities at the end of the list appears to be a strategy for dealing with the issue of entities (such as polylines or boxes) often being split into two separate entities during a trim operation.

Perhaps an option to award the original entity number to the trimmed segments, while pushing remainder segments (if any) to the end of the entity list would be better.That would make it easier for the programmer to separate the wheat from the chaff.

Otherwise, with a little planning (and a lot of extra code), it appears possible to identify the renumbered entities, and restore their numbers if desired, in basiccad.

if implemented, your entity parameter would almost certainly have to be used in the pointxyz parameter, a la<pointxyz [x, y, z, entid]since for many commands it matters WHERE you place the point on the entity.

An entity constraint, either within the pointxyz command or preceeding it, would greatly expand the power of BasicCad.

And if no match is found, it should move the cursor to the nearest point on the specified entity, regardless of distance. That would make it even more powerful. ( It would also eliminate the need to use query ent_points prior to every pointxyz [x,y,z,ent] command )

BTW, a selected-item-only constraint to pointxyz might also be useful.