CompuServe Thread

Larry, I have/had ACAD configured to do an automatic AUDIT following a DXFIN, IGESIN, or DXBIN (check your #8 system options in the configuration menu – item #9). Enabling this feature will cause ACAD to automatically fire up the AUDIT function after any drawing import commands is executed. Note: this is the equivilant of typing "AUDIT N " from the command line in ACAD. What I found upon doing the DXFIN was that there were linetype errors being reported (in varying numbers – depending on which file I was trying to DXFIN) immediately following my DXFIN. However, the drawing *looked* fine on the screen (meaning that the data *appeared* to have translated successfully – except for those dang error messages – which did not go away. Hence I manually tried to have AUDIT fix the errors, and…*nothing*…hello CPU, are ya there? hello? nope. *click*<off>*click*<on>…etc.,. This drove me CRAZY because I at first thought, "oh great…QEMM or something bit the dust again…" so I tried tweaking & removing *everything* from the configuration – until finally I had DOS 5, command.com, and ACAD as the ONLY things in the boot config – and STILL it hung the CPU. Hmmm…Methinks I have an ACAD problem here…I said to myself. Then I restored my original configuration and RELOADED ACAD from the masters…same thing. Then I seriously looked at what was in the DXF file, and what the diferences were between an AES-generated DXF file verses an ACAD-generated DXF file. There were many, but after careful (and time-consuming) analysis, I reduced it to the CONTINUOUS linetype data in the LTYPE table as being the culpret in causing the AUDIT hanging. I was sebsequently able to manually change the offending line in the AES DXF files and import them without further errors. Therefore, even for me this bug is minimal in it's effect because I can work around it if need be. *HOWEVER* this doesn't excuse ACAD's system-killing in the least bit. It's an ACAD bug – no doubt about it. Mark <see my last reply to Duff> Burns – TKLP Inc.