Visual LISP, AutoLISP and General Customization
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

"Pure" Move command

14 REPLIES 14
SOLVED
Reply
Message 1 of 15
oswaldoe.bustamanter
817 Views, 14 Replies

"Pure" Move command

Hi everyone,

 

I need help with this one.

 

Since I am a beginner, I've been training with easy routines. One of them was to align MTEXT entities with another in the vertical (same x-coordinate for all entities). To achieve that I had to use the move command, but I felt like dirty using it, because since we have access to the list of properties of all entities it is supposed to be easy to change whatever we want. MTEXT entities, in the "10" (identifier of the list, not tenth member) member of the list, have its coordinates stored, the problem is that they are not a "dotted pair" and have special treatment, like you cannot use the SUBST function, well at least I couldn't.

 

Well, with the base problem stated, I am looking now for the "pure" Move command. I mean, the original one, I guess it uses some kind of function to change the values (coordinates) in the list for the entities selected.

 

Thank you for your comments in advance. Best Regards.

 

Oswaldo Bustamante

14 REPLIES 14
Message 2 of 15


@oswaldoe.bustamanter wrote:

.... to align MTEXT entities with another in the vertical (same x-coordinate for all entities). .... MTEXT entities, in the "10" ... member of the list, have its coordinates stored, the problem is that they are not a "dotted pair" and have special treatment, like you cannot use the SUBST function, well at least I couldn't.

....


You should be able to use (subst) for that.  Something like this applied to each one you want to reposition, if its entity data list is in a variable called EntityData:

 

(setq EntityData

  (subst

    (list; new insertion point entry

      10 ; insertion point code

      XCoordinate ; extracted from selected entity to align with

      (caddr (assoc 10 EntityData)); Y coordinate stays

      (cadddr (assoc 10 EntityData)); Z coordinate stays

    ); end list

    (assoc 10 EntityData); old location entry to replace

    EntityData; list to replace it in

  ); end subst

); end setq

(entmod EntityData)

 

If not for one consideration, you could also use (subst) to replace the X coordinate in the insertion point entry:
 

(setq EntityData

  (subst

    (subst ; new insertion point entry

      XCoordinate ; extracted from selected entity to align with

      (cadr (assoc 10 EntityData)); current X coordinate to replace

      (assoc 10 EntityData); list to replace it in

    ); end subst

    (assoc 10 EntityData); old location entry to replace

    EntityData; list to replace it in

  ); end subst

); end setq

(entmod EntityData)

 

BUT you really shouldn't do it that way, because of the one consideration:  in the rare case that the old X coordinate happens to be the same as either the Y or Z coordinate(s), that second (subst) function will replace any other coordinate(s) that is/are the same, as well as the one you want it to replace.

Kent Cooper, AIA
Message 3 of 15
Anonymous
in reply to: Kent1Cooper

Setting the new value for the assoc 10 list will only work if the assoc 71 value is 1, 4, or 7 otherwise the justification is not on the left and the justification point is the assoc 11 list instead of the assoc 10 list.  Check out Developer Help Documentation > Contents > DXF Reference > Entities Section > MTEXT for more association lists that may impact MTEXT justification.

 One easy way to specify a new point list such as the assoc 10 list is (CONS 10 (LIST x y z)) where x, y, and z are reals or symbols that evaluate to reals.  Then you can (SETQ EntityData (SUBST (CONS 10 (LIST x y z)) (ASSOC 10 EntityData) EntityData))

Message 4 of 15
Kent1Cooper
in reply to: Anonymous


@Anonymous wrote:

Setting the new value for the assoc 10 list will only work if the assoc 71 value is 1, 4, or 7 otherwise the justification is not on the left and the justification point is the assoc 11 list instead of the assoc 10 list. ....

 One easy way to specify a new point list such as the assoc 10 list is (CONS 10 (LIST x y z)) where x, y, and z are reals or symbols that evaluate to reals.  Then you can (SETQ EntityData (SUBST (CONS 10 (LIST x y z)) (ASSOC 10 EntityData) EntityData))


Have association-list values relative to the insertion point for Mtext changed since my 2004?  I think you may be confusing Mtext with plain Text.  For me, the (assoc 10) value for Mtext is always the insertion point, regardless of the justification.  It's only for plain Text that there's a difference between the 10 and 11 values based on justification -- if it's ordinary default left-justified, (assoc 10) is the insertion point and (assoc 11) is always '(0 0 0), but with any other justification, (assoc 11) is the insertion point and (assoc 10) is the left end of the baseline [that aspect is also true of left-justified Text, where that coincides with the insertion point].

 

And I don't see any reason, when x, y and z are separate numbers or variables, to use the more complicated (cons 10 (list x y z)), rather than simply (list 10 x y z).  Only if you already have a three-component point list in a variable is there any benefit -- (cons 10 yourList).

Kent Cooper, AIA
Message 5 of 15

Thank you for your help Mr. Cooper. The first code worked great.

 

The first time I tried to do that I was really close to what you wrote on the first code, but I just couldn't figure out the way a value in the list of the entity can be represented by a variable, hope I explained myself.

 

As I told you, I am a beginner, so I can't get the second code, but I will study it and comment when I get it.

 

Talking about what you are discussing now, the justification, by that I guess you mean when the "stretch points" are merged on the upper left corner of the MTEXT entity. I will try to use the routine with that kind of MTEXT and tell you if it worked, since I am using the "10" list element. Best regards.

 

Oswaldo Bustamante 

Message 6 of 15


@oswaldoe.bustamanter wrote:

Thank you for your help Mr. Cooper. The first code worked great.

.... 

As I told you, I am a beginner, so I can't get the second code, but I will study it and comment when I get it.

 

Talking about what you are discussing now, the justification, by that I guess you mean when the "stretch points" are merged on the upper left corner of the MTEXT entity. I will try to use the routine with that kind of MTEXT and tell you if it worked, since I am using the "10" list element. Best regards.

....


You're welcome.  Don't study the second one too hard, since it's not a good way to do it, unless perhaps you just want to understand how a (subst) function can be nested inside another one.

 

The justification is the positioning of the insertion point [the point that INSert Object-Snap will find] in relation to the Mtext content.  It can be at any of nine locations -- it's only at the upper left if the User called for that or didn't call for some other justification [Top Left is the default].

 

The "stretch points" are officially called "grips."  When selected without a command operating, all Mtext entities have grips at all four corners of their definition boxes, and if the justification is not at one of those corners, there is also a grip at the insertion point [the middle of one of the edges, or the middle of the box].  The code puts all of the Mtext entities' insertion points at the same position in the X direction, so if the entities do not have the same justification, they won't necessarily be aligned as to things like the sides of their definition boxes.  If you want differently-justified Mtext entities to have [for example] the left sides of their definition boxes aligned, that can also be done, but not by changing their insertion points; it would require getting their bounding boxes, or changing their justifications.

Kent Cooper, AIA
Message 7 of 15

Thanks again for the explanation Mr. Cooper.

 

Attached is a .txt file that contains the code related to this topic, but it uses the move command, I haven't update de code. Best regards.

 

Oswaldo Bustamante

Message 8 of 15
Anonymous
in reply to: Kent1Cooper

It is true that the assoc 10 list is always the justification point for Mtext, sorry for the mix up.  However, the main point of what I said is very much the truth and has a direct bearing on the results.  You simply cannot line up Mtext left justified unless the assoc 71 value is either 1, 4, or 7.  The OP needs to know this fact.

Also, if the user is trying to assign the exact same x-value to all of his assoc 10 lists then it is very likely that his desired x-value has been isolated.  By some means or another s/he will need to reconstruct the point triplet to include the desired x-value.  I have identified "One easy way..."  to do that but it is certainly not the only way and I understand it is not the way you would do it.  Now do you understand why I used (CONS 10 (LIST x y z))?  I mean and meant no disrespect to you or your posts.Smiley Happy

Message 9 of 15
Kent1Cooper
in reply to: Anonymous


@Anonymous wrote:

....  You simply cannot line up Mtext left justified unless the assoc 71 value is either 1, 4, or 7. ....


It seems you're assuming, for some reason, that they want to line up the left sides of Mtext entities, and maybe to force all of them to be left-justified in order to do that.  But that's not what they asked about.  I don't see anything in the original post to suggest any preference for left- rather than right- or middle-based justification.  They only wanted to impose the same X coordinate on all the insertion points, with no reference to justification at all.  But just in case they do want to do something like that, see the last two sentences in Message 6.

Kent Cooper, AIA
Message 10 of 15
Anonymous
in reply to: Kent1Cooper

Look, Kent, I'm trying to point out to an acknowledged beginner that there are several things to consider when using ENTMOD to affect justification (that would be position to the beginner).  And whether it is TEXT or MTEXT it is all about justification.  That is what is being defined starting with the assoc 10 list but depending upon other assoc lists that have a direct impact upon justification.  I am not trying to outdo you supercede you one-up you, steal your thunder, etc. etc. etc.  I do not want to get into any p'ing contest over whose comments are the best.  But, all I am seeing in your incessant replies regarding nothing more than how wrong I am is "Hey you! bug off! go away! I got ths!"  Until now I haven't criticized anything in your posts.  I left off newsgroups and public forums years ago for this exact reason.  Tony Tanzillo was the King of posting rapers back then.  I hope you are not a student of his.

 

You should learn to be comfortable with the fact that this is a public forum and not be so defensive of certain threads as if they were your personal turf.Smiley Sad

Message 11 of 15
Kent1Cooper
in reply to: Anonymous


@Anonymous wrote:

Look, Kent, I'm trying to point out to an acknowledged beginner that there are several things to consider when using ENTMOD to affect justification ....  I do not want to get into any p'ing contest over whose comments are the best.  But, all I am seeing in your incessant replies regarding nothing more than how wrong I am....


I still think you've fundamentally misunderstood the original question.  They were not looking for anything to affect justification in any way, but only to affect the position of the insertion point in the drawing [note that they talked about using Move to do it], not its position in relation to the Mtext content [which is what justification is about].

 

It's not a question of whose comments are best, but of accomplishing what they're trying to do.  An acknowledged beginner certainly doesn't need to be led down an irrelevant path with suggestions for something different from what they've asked about.  If my attempts to correct your misinterpretation come across as a p'ing contest or being about how wrong you are, well, sorry, but I do think you're wrong in that regard, and for the sake of the acknowledged beginner, as well as for others who may find this thread later looking for a way to do the same thing, I will continue to point out such errors when I notice them.  I sometimes make errors, too, and personally, I would want others to point those out, so that people's requests and questions will be appropriately answered.

Kent Cooper, AIA
Message 12 of 15
Anonymous
in reply to: Kent1Cooper

Kent, What I said is totally relevant to the op, what you are saying regarding what I said is completely irrelevant and down-right ignorant.  I have been an Authorized Autodesk Developer and ADN member since the mid 90's, first through my employer and later in my own right.  I know what I'm talking about whether you understand it or not. I readily acknowledged the one error I made regarding assoc 11 and Mtext justification and I will readily acknowledge any other errors I make; however, there is only one other error to acknowledge in this thread which I will make just this one more time, namely, responding to your "corrections" at all.  Meanwhile, just because you don't understand something that does not mean it is an error.  You should concern your self with your cluttering up discussions with all of your "error corrections" and  attempts to demonstrate your supreme mastery of any subject so that people who find this thread in the future don't have to swim through your swamp of self-aggrandizement to find anything of use.

BTW Don't let the "Registered" date fool you.  I am not a newcomer. Search by user and you will find a few posts I made in this forum in 2003.  Before that I spent my time in AutoCAD related newsgroups.Smiley Mad

"Can't we all just get along?"

Message 13 of 15
Kent1Cooper
in reply to: Anonymous


@Anonymous wrote:

Kent, What I said is totally relevant to the op, what you are saying regarding what I said is completely irrelevant and down-right ignorant. ....


Well....  The complete absence of any reference to justification [left or otherwise] in the OP, and the green check-mark on Message 2, suggest otherwise.

Kent Cooper, AIA
Message 14 of 15

Hi everybody,

 

Well, I am here to make clear some points in the discussion.

 

My first question was all about managing the insertion point for MTEXT entities, on that, Mr. Cooper is right, and that's why I gave him the solution title. But, Why did I wanted to move MTEXT entities referenced to this point?, because usually (and by default also) the justification is "top left", so I consider that the comment about justification Francis did was accurate. Actually, before I started to assemble this routine, I thought about the justification issue, but as I told you, usually we use the default justification. I didn't know there were a value on the list for managing the justification.

 

I am planning to make this routine work with different justifications, or to change a group of MTEXT entities to a certain justification (default top left).

 

I want to thank you all, because the answers were accurate and more important, fast, and that is something that makes this a great community, and makes me feel eager to help whenever I have the opportunity.

Message 15 of 15
Anonymous
in reply to: oswaldoe.bustamanter

If I might and a little soemthing to think about; not just in this discussion, but almost any time you design code; sometimes the dirty ways are really easier all around. I appreciate what you say about your original method being "dirty". I admit I haven't given the coding here a lot of thought. Though I have done a fair bit of code much like this. It is no small undertaking, as I am sure you are finding. Wouldn't doing your move routine really be easier? And in the end isn't that what you are after? I guess what I am trying to say is that yes, elegance has its role, but don't get carried away with it. Apply the KISS principle as much as you can. Steve A Rogers

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report

”Boost