Attribute Definition to Text or MText

[MrMuscl3]

I have multiple drawing files which include hundreds of attribute definitions. To be more clear, these attribute definitions are from blocks that have been exploded. Don't exactly know the reason why someone have used these instead of text/mtext.

Is there a way to convert all these attribute definitions to text or mtext so that the attribute definitions would keep their current values and formats (font sizes for example)?

Would be greatly appreciated if someone has solution for this problem. I need small instructions if this solution includes using of LISP.

My description says AutoCAD LT 2014, but I currently have access to AutoCAD full version. I believe this problem is not possible to solve with LT.

[pendean · Accepted solution]

Try this freebie for use in AutoCAD (not LT) http://cadtips.cadalyst.com/attributed-blocks/convert-attdef-entities-text

[natasha.l · Accepted solution]

Hello @MrMuscl3, 

You can Select All use the: BURST command = Explodes Attributes to Text  or  TXT2MTXT command will convert text to MultiText. 

Please "Accept Solution" if a reply or replies have helped resolve the issue or answered your question, to help others in the community.

[MrMuscl3]

In reply for @natasha.l : I mentioned on the starting post that these attribute definitions are from blocks that have been exploded. Therefore I was not able to use BURST command as suggested. If I understood right, this command can disassemble blocks or block references into elements that these were actually created in first place and retain their original values. Therefore BURST is not able to disassemble attribute definitions which are from blocks that have been exploded.

I also tested the TXT2MTEXT command and it lacks feature to convert individual texts to mtext. If I understood right, this command merges all selected texts to one massive mtext. Therefore this does not suit my needs. Therefore I searched for LISP to change individual texts to individual mtexts from page provided by @pendean. I found LISP from there to achieve this and it actually worked. Here is a link to the LISP

http://cadtips.cadalyst.com/multiline-text/convert-text-mtext-without-changing-justification

I thought that it would be nice to use this for all text elements that were present in the dwg I used for testing. This was not possible because the formations of texts were converted in wrong way. If I understood right, this happens because when converting text to mtext, the command interprets each space that is present in converted text - will be seen as line change (pressing enter). Therefore texts will end up one on the other.

LISP provided by @pendean worked as intended and converted attribute definitions to text elements. The problem mentioned above was not present with these text fields when I converted them into mtext since they were attribute definitions before and therefore these elements can not contain any spaces.

I looked for other LISPs that would not have problem with conversion of texts including spaces but were not able to find one. Then I thought that if I replace the spaces with _ (underlines), the problem would not occur. This is yet to be tested. Please feel free to comment if theres another workaround for this problem!

I hope this answer and thread will be help others having hard time with same problem.

[MrMuscl3]

@natasha.l , @pendean 

Converting spaces on text elements to underlines before the conversion and after converting them back to spaces did not work. The text to mtext conversion does not understand how big the text area should be when converting long text to mtext.

[RobDraw]

I used to have a LISP for this but am having trouble tracking it down. I'm pretty sure it was called something like TAG2TEXT. I'm seeing it mentioned but can't find the actual LISP. I'll keep looking though as I'm sure I'm going to need it again.

Have you tried making the disassociated attributes into a block and then using the burst command?

[MrMuscl3]

@RobDraw: The problem with attribute definitions to text and from text to mtext is actually solved.

Remaining problem is that I would also like to convert all text elements to mtexts and when this is done, there occurs a problem with longer text elements that contain spaces in them. These spaces are interpet to be actual line changes (pressing enter) and therefore these texts end up one on the other. This happens for example when you have 3 single line text rows with small offsets to make it look like it actually is 1 mtext but really is 3 single line texts. I believe the problem is that there is no information on text field about the field size and therefore the converted texts have all same sized text field. And the field size is too small for long texts included with spaces.

Since @Kent1Cooper is the owner and creator of this LISP, I have asked if he could comment this problem and tell us if there was a solution to it.

[Kent1Cooper · Accepted solution]

---

@MrMuscl3 wrote:

.... there occurs a problem with longer text elements that contain spaces in them. These spaces are interpet to be actual line changes (pressing enter) ....

---

Are they really becoming hard returns?  I suspect maybe it's just a matter of slight differences in overall width as applied in the Mtext version compared to as applied in the Text/Attdef version, and that it's just word-wrapping.  It may be affected by the particular font, or by the particular character content.  You can test it easily enough -- if you grab the Mtext width grip and drag it wider, does it "straighten out" into a single line?  [It won't do that if it's really imposing Enters between lines.]

If that's the issue, try adding this to the routine, to force the Mtext version to have no limiting width, so it will never wrap to any additional line(s):

....

      (vlax-put tobj 'InsertionPoint tins); original Text's insertion
      (vlax-put tobj 'Width 0.0); prevent word wrapping
    ); repeat

....

[MrMuscl3]

@Kent1Cooper: Thank you for your fast answer. I currently have no experience editing LISP. I actually used my first one today. So Im afraid to just add this code you provided to just somewhere inside the original code.

And you were right about the outcome. It was word wrapping and extending the mtext field "deleted" the problem. I accidentally described the situation wrong way.

Could you tell me the line number where this code should be added? Im using notepad++ and it shows line numbers.

[Kent1Cooper]

---

@MrMuscl3 wrote:

....

Could you tell me the line number where this code should be added? Im using notepad++ and it shows line numbers.

---

I use plain old Notepad, in which I could get  a line number [it doesn't display them at each line], but just add the code line in black [with or without the blue comment] between the existing lines in the routine that are greyed-out in the excerpt in Message 8.

[MrMuscl3]

@Kent1Cooper: Now, you Sir are a genius

Now the mtext field lenght and height are both defined to 0 if I understood right.

I also noticed that you actually posted only one new line to code and I added new line after line 69 and the new line contained the code you provided: (vlax-put tobj 'Width 0.0); prevent word wrapping

Thank you very much! In case our paths cross someday, I will buy you a beer

I'm having hard time selecting solution for this thread. I hope I can select more than one since many answers were helpful.

[Kent1Cooper]

---

@MrMuscl3 wrote:

....

I'm having hard time selecting solution for this thread. I hope I can select more than one since many answers were helpful.

---

[Yes, you can mark more than one Message as accepted Solution(s).]

[SStabnick]

Your link does not work. I have the same issue you had, therefore, that lisp routine would be awesome to have.

Tried the TXT2MTXT

[Kent1Cooper]

---

@SStabnick wrote:

Your link does not work. ....

---

If you mean the link in Message 4, you can get the same Text1MtextJust.lsp routine >here<.

[The Cadalyst CAD Tips site has been non-functioning recently -- I've contacted them about it, and they tell me they're working on it.]

[pendean]

---

@SStabnick wrote:

Your link does not work...

---

Those links are to a very old website: you'll need to make an effort, just copy/paste the full address without the http:// segment, they work just fine here for me.