Bug Watch June 2004

Bug Watch celebrates ten-plus years with a look back at the top ten AutoCAD bugs.

Bug Watch was hatched in January 1993, when Mark Middlebrook and Mike Dickason were on the case with Release 12. In June 1995 I took over the then-illustrious positions of Bug Threadmaster on the CompuServe ACAD forum and creator of the enormous Unofficial Release 13 Bug List. I was lucky because Release 13 gave me much more material than I could ever use. Bugs are much harder to come by these days, although I haven't run out of material yet.

Back in 1995, both Cadalyst and Cadence recognized that Release 13's bug problems would be a significant issue for readers. Within 24 hours of each other, both magazines offered me jobs writing about bugs. I took the Cadalyst offer, but now that the two magazines have merged, I suppose you can say that Cadence got me in the end.

This month and next, Bug Watch will take a look back over the years with a Top Ten of AutoCAD bugs. I found it impossible to give them a rank from 1 to 10, so instead I gave each bug its own award. So, ladies and gentlemen, without any further ado, I give you part one of the Cadalyst 20th Anniversary Bug Watch Awards.

Most contrived bug title award
This category had the strongest competition. All of the following had a chance:

Take me to your leader
Underlining undermining
(grread) is not good
Scroll, bah!
Accelerator break
Solid crock
Foot phut
Undo doo-doo
Dim block head
Gripe edit
Grown of arc
Enter at your peril

I'm particularly fond of "Asterisk? The gall!," but the winner has to be this awful pun on a Star Trek theme from September 1996:

Space, no line at front here (DOS, Windows 13c4)
The \L mtext mechanism for underlining does not work correctly on mtext that begins or ends with spaces. Such spaces are simply not underlined. For example, create the following mtext:

Space,\L the final \l frontier

The spaces before "the" and after "final" are not underlined.
Workaround: Either explode the mtext (it's converted to text and a line), use text with the old %%u technique, or replace the spaces in mtext with underscores.

You may be interested to know that AutoCAD 2005 still doesn't show such spaces as underlined. They're shown as underlined in the mtext editor, but not in the drawing itself.

Most disastrous data-destroying bug award
In this category, the spoils (pun intended) are shared among several bugs associated with the ISAVEPERCENT system variable. First, s a little history. One source of criticism for Release 13 was that it was very slow to save drawings. Release 13c3 introduced the ISAVEPERCENT system variable to control an incremental saving mechanism, which meant that only changes were saved, rather than the whole drawing every time. Unfortunately, this went a little wrong. There were drawing corruption issues, which were reported as "Visretain Violation" in October 1995. A c3b patch to the c3 patch was introduced to fix this, and then another drawing corruption issue was discovered in c3b. Autodesk reported the problem like this:
AutoCAD R13c3b has been found to crash with "INTERNAL ERROR: !smio.cc@ 541" when you have a drawing containing external references with non-CONTINUOUS linetypes, and:
  - Incremental save is on (ISAVEPERCENT>0)
  - VISRETAIN=1
  - An xref/reload or xref/path had been performed
  - The drawing is saved and reopened
  - A layer setting is changed
  - The drawing is saved again
The drawing is corrupted by the save and will fail when reopened.
At the time, I thought that the patch to fix that one would be called c3c or maybe c3b1, but I was wrong. It was actually called c3a (are you confused yet?), which unfortunately also removed the fix for the first drawing corruption problem. The first specific ISAVEPERCENT disaster reported in Cadalyst was this one, from December 1995:

The quick and the dead (DOS, Windows 13c3)
If you have the new performance-enhancing Save variable ISAVEPERCENT set to anything other than 0 (the default is 50), purge a drawing a couple of times, and then save, the drawing can be corrupted. If so, the next time you try to open it, AutoCAD crashes with: an
INTERNAL ERROR: !dbattr.cc@401: eWasPermanentlyErased."
Bug introduced by c3.
Workaround: None known. The safest thing to do to avoid this problem is to set ISAVEPERCENT to 0 and learn to live with the slow saves.
As it turned out, that was rather good advice. The above problem was fixed by the c4 update, but this one from January 1996 was not:

Save misbehave (DOS, Windows 13c3)
Set ISAVEPERCENT to a value greater than 0 and ISAVEBAK to 0. Open a drawing called Kermit and make some changes to it. Next, use the Save command and specify drawing Gonzo. With the exception of the problem described above, everything works fine so far. Now use the Qsave command, which should save to KERMIT.DWG. However, it saves to GONZO.DWG instead. If you now get out of the current drawing, your changes to Kermit will be lost without warning.
Workaround: A second Qsave will save to Kermit. Alternatively, any drawing action after saving GONZO causes the subsequent Qsave to save correctly to Kermit.
But something worse was afoot. In September 1996, we asked this question:
Are parts of your drawings going AWOL? Some Release 13 users report that parts of their drawings disappear between saves and opens.
These particularly nasty problems increased after the c4 update. I didn't see any reports of the same problem from users of the final Release 13 version, c4a. But that doesn't mean the bug wasn't there, because everybody in the know had set ISAVEPERCENT to 0 by then and would never have seen the bug anyway.

A minor postscript to this issue cropped up in Release 14, as reported in September 1998:

Time crime (14)
The incremental save mechanism that was introduced in Release 13c2 has something of a checkered history. It significantly speeds up many saves, but can cause significant file size blowout. More importantly, it has caused enough drawing file corruption problems to make many people consider it untrustworthy. This month's problem sounds trivial when compared with drawing corruption, but it can still cause loss of work. When the incremental save mechanism is turned on, the system date and time is not updated during many saves. This is a problem because it can interfere with all sorts of procedures, such as automated file archiving. It also means that you won't be able to tell with any certainty which of two drawings has been most recently worked on without opening both drawings.
Workaround: Turn the incremental save mechanism off by setting the ISAVEPERCENT system variable to 0.

Comedy award
The award for faux pas funniness goes to a Release 13 double act. First, from Mark's final Bug Watch in March 1995, we had the amusing spectacle of a font file that failed to perform the duty that was its sole reason for existence:

Monotxt isn't (DOS, Windows 13c1)
R13's MONOTXT.SHX is supposed to be a monospaced font, but isn't.
Workaround: Use MONOTXT.SHX from R12 (for example, copy \ACADR12\FONTS\MONOTXT.SHX to your drawing directory or \ACADR13\COMMON\FONTS directory).
Here's the punchline, as reported in the July 1995 issue:

Déj