Author Topic: entity parameter for macro commands  (Read 4010 times)

bdeck

  • Hero Member
  • *****
  • Posts: 815
entity parameter for macro commands
« on: September 14, 2008, 02:50:03 PM »
"<pointxyz [x,y,z]"  is an awkward way to specify an entity to be used in a function, because points are not unique to indiviual entities.
 
A simple "<entity [n]" parameter would make life so much simpler.

Failing that, a macro command to change display order would probably suffice.

Edit:

Oops. I just discovered the move to back command, still awkward, but at least reliable.

 


Thanks, BD

BD
« Last Edit: September 16, 2008, 08:21:45 AM by bdeck »

bdeck

  • Hero Member
  • *****
  • Posts: 815
Re: entity parameter for macro commands
« Reply #1 on: September 16, 2008, 05:05:58 PM »
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.

BD



« Last Edit: September 16, 2008, 06:45:00 PM by bdeck »

Dempsey

  • Hero Member
  • *****
  • Posts: 1892
  • Intel i7-960, 12GB, NVidiaGTX570, Win7x64, DC26.2
    • World of van Vliet
Re: entity parameter for macro commands
« Reply #2 on: September 16, 2008, 06:26:46 PM »
bdeck,

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.

ent is the entity.

BTW, what is the "move to back" command?
Dempsey

bdeck

  • Hero Member
  • *****
  • Posts: 815
Re: entity parameter for macro commands
« Reply #3 on: September 16, 2008, 07:04:01 PM »
BTW, what is the "move to back" command?

Hi D,

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.

BD
« Last Edit: September 17, 2008, 11:47:06 AM by bdeck »

bdeck

  • Hero Member
  • *****
  • Posts: 815
Re: entity parameter for macro commands
« Reply #4 on: September 24, 2008, 11:26:18 PM »
I just discovered another feature.

Trim1 command ( and presumably others ) does not trim the entity chosen.

Instead, it erases that entity and draws a new one with an entity number at the end of the list, thereby corrupting the entire list of entities following the trimmed line.

Surely this is not a behavior anyone has used advantageously.

My vote is to change this behaviour or provide an opt out.

Alternatively, for the majority of us who use entity numbers to manipulate entities in a drawing, the solution is to use movetobackof or movetofrontof to restore the original entity number.

BD 
« Last Edit: September 30, 2008, 05:42:45 AM by bdeck »

bdeck

  • Hero Member
  • *****
  • Posts: 815
Re: entity parameter for macro commands
« Reply #5 on: November 16, 2008, 07:45:39 PM »
Quote
Surely this is not a behavior anyone has used advantageously.

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.

BD
« Last Edit: November 17, 2008, 10:48:09 AM by bdeck »

DrollTroll

  • Kindly Curmudgeon
  • Administrator
  • *****
  • Posts: 4152
Re: entity parameter for macro commands
« Reply #6 on: November 18, 2008, 07:02:45 AM »
bdeck,

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.
25 years with DesignCAD

bdeck

  • Hero Member
  • *****
  • Posts: 815
Re: entity parameter for macro commands
« Reply #7 on: November 18, 2008, 07:54:57 AM »
Hi DT,

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.

Thanks for listening.

Regards,

BD