×

AutoCAD

Bug Watch: Battman Bylayer Bug is Bread and Butter to the Bugmeister

14 Nov, 2004 By: Steve Johnson

---

Oh, no! There's trouble in Gotham City. Terrible Battman puns, and they're headed our way!

Holy Color Calamity, Battman! (2002 to 2005 SP1)
The Battman command (Modify / Object / Attribute / Block Attribute Manager) allows you to do all sorts of neat stuff with attributes. For example, you can choose a block's attribute and change its color, thereby affecting that attribute in all blocks of that name in the drawing. But hold on, something's wrong, Battman! If you change attributes to use a color of Bylayer, it appears to work. But that's just someone at Autodesk being a bit of a Joker. The color is actually changed to a specific, hardwired value that happens to match the color that Bylayer happens to be at the time of the command. If you later change the color associated with the attribute's layer, the attribute doesn't change color as it should.
Workaround: None known that will stop Battman from messing up, but you can fix things up after the fact using the Refedit command. In AutoCAD 2005, that's Modify / Xref and Block Editing / Edit Reference In-Place, but the wording is slightly different in earlier releases. Use Refedit on one insertion of the block, change the color to Bylayer, then use Refclose and save the changes. To fix up the other block insertions in the drawing, use Battman again and click on the Sync button.

Holy Mirroring Mayhem, Battman! (2002 to 2005 SP1)
Insert a block with attributes. Make sure the MIRRTEXT system variable is set to 0, then mirror the block. The attributes will come out the right way around, as expected. Now use the Battman command and make any kind of change to one of the attributes. That attribute will then flip itself in the mirrored block, such that it is the wrong way around, unlike all its little friends.
No known workaround.

Block Lock Shock (2002 to 2005 SP1)
If a block contains any attributes on locked layers, the Eattedit command (and double-click editing) acts as if the whole block is locked, preventing you from editing those attributes that are not locked.
Workaround: You can use the Properties window in AutoCAD 2004 and later to edit the unlocked attribute values. Unfortunately, this also allows you to attempt to edit the locked values. If you do so, your editing efforts will just be discarded without warning. The old Ddatte command behaves correctly in this situation. It will allow you to edit the unlocked attribute values after you pick OK in a slightly pointless alert box. The locked attributes are correctly grayed out. If you still want to use Eattedit because of its extra features, you will first need to unlock the layers of all attributes in the block.

Table Trouble 1 (2005 SP1)
Submitted by Drew Beattie
At the Command prompt, pick a cell in one of AutoCAD 2005's new table objects. Start typing, and the text will end up in the table cell. Well, some of it will. If you type reasonably quickly, you will see that AutoCAD has ignored the second character you typed.
Workaround: None known other than typing slower.

Table Trouble 2 (2005 SP1)
When editing text in a table, you are automatically moved onto the next cell when you press Enter. If the next cell is off-screen, AutoCAD thoughtfully pans down so you can see what you're doing. A problem with this is that it doesn't respect the locked status of viewports. If you are editing a model space table through a locked paper space viewport, and AutoCAD decides to pan down while editing table cells, it will mess up your viewport. If you have paper space dimensions associated with model space objects in that viewport, the dimensions will be left behind by the pan. They do not appear to be attached to the objects any more, but they are still associated. They should fix themselves up after you unlock your viewport and pan it back to where it came from.
Workaround: Try using the new Maximize Viewport feature when editing model space objects.

Still Active Bug is Still Active (2005 SP1)
After playing with the Table Trouble 2 bug, AutoCAD gave me a spurious message: "AutoCAD cannot close DWGNAME because there is a command still active. Please complete the command and try again." I hoped I had seen the last of these after installing AutoCAD 2005 SP1, but it seems there are still some circumstances that trigger this problem. If you know of some exact steps to reproduce this, please let me know at steve.johnson@cadalyst.com.