Text wrap on mtext labels in block unwraps

[kwg06516]

I've noticed that when I paste blocks with mtext labels in them into drawings where the block definition already exists I lose the text wrap setting.  This results in blocks with labels that are all on one line, sometimes sticking outside the original bounds of the block.

1. First time block was pasted.  Text wrap behaved normally.

2. Went back to source drawing, cleared the clipboard, copied same block again and pasted it a second time.  Text wrap is lost.

I've only recently begun working with mtext labels in blocks so I don't know if this is a common occurance or a recent development following an update.  Whatever the case it's annoying and is interfering with my productivity.

[pendean]

These are actual MTEXT objects, not attributes? What do you have the width set for the MTEXT? Is there a hard return between the words (are they on separate lines)?

[kwg06516]

These are multiline attributes that are edited with what looks like an
mtext editor. In some cases the width was set by dragging the margins. I
also tried hard returns. The result is the same either way.

[pothied]

Why are you copying and pasting the same block from an external source multiple times instead of just copying the one that is already in the drawing?

Can you attach the block to this thread so I can test this on my system?

[pendean]

Agreed, your workflow makes no sense.
Post a DWG file, you seem a little confused by what you have and how to use it (assuming it's not a simpler setting problem). Can't replicate your issue here otherwise.

[kwg06516]

Because sometimes these blocks are parts of a group of entities like an arrangement of furniture or equipment being copied between drawings representing different phases or the incorporation of a proposed layout into an as-built master plan once the project is completed. What do you think I should do? Insert every block from the tool pad and recreate these layouts from memory and re-enter every label because Autodesk can't be bothered to write their software properly?!

K. Gatzke

[pendean]

Blaming the software creator for a problem we can't reproduce is hardly helpful to anyone or you.

Post a DWG with the block and the issue in plain view and let's all try to recreate your problem using your methods and workflows.

[kwg06516]

There are two drawings attached representing usual work flow.

Baseplan: a sample plan representing the as-built master for our facility

Cabinets: a sample layout that has been approved and constructed and is now ready to be inserted into the master plan.

I can copy/paste the contents of Cabinets into Baseplan using the clipboard

or

I can insert Cabinets into Baseplan as block.

This is the result either way:

I don't know what to tell you if you don't get that result. 

I also tried attaching by XREF and I get this message when I tried to XREF Cabinets into Baseplan (both as Attach and Overlay)

Command: _XATTACH
** Error: "cabinets" is already a standard block in the current drawing.
*Invalid*

Not a method I ever employ for combining completed projects with the master plan but I gave it a shot just to see what happens.  Am I to understand that XREF never works with two drawings that share a block in common?

[jggerth1]

And XREF file and a drawing file can have block names in common -- what can't happen is an XREF file name that is identical to a block name that's already in the drawing.

An XREF is really a special type of block insertion, so that error message makes sense.  One can't have two different looking blocks that use the same name.

[kwg06516]

I've discovered that when an attribute loses it's formatting there's a change in the label.

The correctly formatted cushion shaped label contains an attribute with the label "COLORED\P\PPLASTIC".

When I copy and paste it from the clipboard the lable becomes "COLORED PLASTIC".

Copying and pasting the block stripped the "\P\P" formatting tags that create the two hard returns.

I understand copying and pasting a block doesn't sit well with some of you but I think I've clearly outlined why I don't care.  I have a work flow that works for me and hasn't caused me any problems until I started using attributes with multiple lines set to YES. 

Since you can't edit a multiline attribute from its label field under properties there is probably extra information I can't see that's being removed.  I know AutoCAD and the clipboard are saving the formatting tags when I copy because the formatting works when the block is pasted into a drawing where it is not already defined.  AutoCAD must be removing them when they're pasted into a drawing where they're already defined.

I want to know if anyone else can reproduce this effect in AutoCAD 2010 running on Windows 7 Enterprise and if they can, why it is happening.