Release 13 Bug List
Steve Johnson


Contact Details

CompuServe:  Steve Johnson [Bug TM] 100251,2544
Internet:    100251.2544@compuserve.com
Postal:      cad nauseam
             PO Box 303
             Leederville  WA  6903
             Australia

Note: Steve's old CIS ID of 100036,1061 will not be used after 30 June.


Revision History

28 November 1994  Autodesk begins shipping AutoCAD Release 13
16 December 1994  Autodesk begins shipping patch 13a
14 January 1995   Autodesk begins shipping patch 13c1
10 February 1995  Initial posting: items 1-117
19 March 1995     Second posting (updated for 13c1): items 118-164
28 March 1995     Autodesk begins shipping patch 13c2
 2 April 1995     Autodesk begins shipping patch 13c2a
14 April 1995     Autodesk begins shipping patch 13c2b
28 April 1995     Third posting (updated for 13c2b): items 165-211
15 June 1995      Fourth posting: items 212-255

The versions of Release 13 which have been made available to date are 
shown in this Revision History.  If an item is listed as existing in 
13c2, you can safely assume it also exists in 13c2a and 13c2b, with the 
exception of bug 168 which exists in 13c2 but in neither 13c2a nor 
13c2b.  Version 13c3 will ship shortly after this fourth version of the 
list is published.


Introduction

The following list of AutoCAD Release 13 bugs and corresponding 
workarounds was compiled from a combination of problems I have 
personally encountered, from messages posted on the ACAD forum of 
CompuServe, and from information passed to me by other people too 
numerous to mention.  I would like to acknowledge the work done on this 
list and its Release 12 predecessors by Mike Dickason, the former Bug 
TM.  I would also like to thank those CompuServe ACAD Threadmasters, 
Autodesk product support staff and other forum members who helped track 
down some of these little insects.

I am not an employee of Autodesk, nor did I compile this list to 
discredit Autodesk.  Any program of the size and complexity of AutoCAD 
will contain bugs.  This is not an official nor a complete list of R13 
bugs.  It is meant to be used as an informative list to help other users 
who might be encountering similar problems.  There may be some argument 
about whether all of the items on this list constitute bugs.  I have 
included some items which, while technically not bugs, would be 
considered bugs by some users.  If you know of any bugs which are not 
included on this list, I would be interested in hearing about them, 
solely for the purpose of keeping the list up to date.  I welcome any 
other comments, suggestions and corrections.

Each item in the list starts with a number.  Bug numbers appended with + 
are either new to this posting, noted as fixed for the first time in 
this posting or updated from the previous posting to include additional 
information.  Numbers appended with - are also updated from the previous 
posting, but only with different version information or some other 
trivial change.  Next, an indication is provided of which version or 
versions of AutoCAD are known to contain the bug.  Bugs which do not 
occur in the current version of AutoCAD are marked as FIXED.  Bugs which 
have featured in a CADALYST Bug Watch column are marked with BW.  After 
that comes a tiny description of my opinion of the status of the 
problem.  Next comes the bug description proper, and finally any known 
workarounds are described.


The first two versions of this list contained fixes claimed by Autodesk 
for the different patches.  From the third posting onwards, such 
information was no longer included in the list.


Legal Stuff

Apology:  Sorry about this, but this list is increasingly becoming hot 
property and it needs to be made clear who owns it and what it can be 
used for.  This section will also answer some of the questions I 
regularly get asked about distribution of the list.

Copyright:  Steve Johnson, 1995.  Most of items 1-16 and parts of the 
introduction by Mike Dickason.

Distribution:  Permission is hereby granted for this list to be copied, 
distributed and/or reproduced intact by Autodesk personnel, AutoCAD 
dealers, AutoCAD and Autodesk user groups, AutoCAD users and AutoCAD 
bulletin boards.  Such distribution must be without fee of any kind, 
other than the cost of materials or normal bulletin board on-line 
charges.  AutoCAD user groups may also reproduce parts of the list for 
distribution to members, providing the source and copyright is 
acknowledged.

Disclaimer:  The information in this list is provided free of charge and 
on an "as is" basis.  Although all information is checked before 
inclusion in the list and every effort is made to ensure accuracy, any 
document of the size and complexity of this one may contain errors.  No 
responsibility or liability can be assumed for any loss or damage which 
may result from any inaccuracy or omission or from the use of the 
information in this list.  No warranties, express or otherwise, are made 
with respect to the information in this list.

Trademarks:  All brand names, product names or trademarks belong to 
their respective holders.  If you've read all that without falling 
asleep, well done.  Now for the interesting stuff.


Bugs Start Here

1.	[Common 12-13c2]  Undesirable behaviour.
If you use WBLOCK <dwgname> * to purge a drawing, and the drawing 
contains Xrefs, Release 13 resets all Xref layer visibility, colour, and 
linetype settings to the values in the external drawings, even when 
you've changed some of these values and set VISRETAIN to 1 to keep the 
changes.

Workaround: Use the PURGE command instead of WBLOCK * (note that, 
because of block nesting, you sometimes have to go through several PURGE 
cycles in order to purge everything).  Alternately, if your changes to 
Xref layers are minimal, simply reapply them after purging with WBLOCK *


2.	[DOS 12-13a, FIXED 13c1]  Bug.
Where an AutoCAD drawing has text entities which consist of spaces, and 
these lie outside the normal drawing extents, AutoCAD gets confused when 
performing a ZOOM Extents.  First, it zooms to the extents including the 
invisible text, then forces a redisplay to the smaller extents which do 
not include the text.  A subsequent ZOOM E does the reverse: ie. it 
zooms first to the small extents, then redisplays to the larger extents 
(possibly regenerating in the process).  Further ZOOM E commands 
alternate between big/small and small/big.  The following script 
demonstrates the problem:

PLINE 0,0 8410,0 8410,5940 0,5940 C
ZOOM E
TEXT 8000,5000 25 0 X
(entmod (subst (cons 1 " ") (assoc 1 (setq eg (entget (entlast)))) eg))
SCALE C 0,0 8410,5940  0,0 .1
ZOOM E

The (entmod) in the above script changes the text to a space.  This 
could just as easily be done with DDEDIT.  When the script has run, 
issue a few successive ZOOM E commands and watch what happens.  The 
problem does not occur with text entities containing null strings.

Workaround: turn QTEXT On, then ZOOM E and erase the empty text boxes.


3+	[Common 12-13c2]  Bug.
There is a problem with using "Auto" in menu macros for building 
selection sets.  Given the menu line:

	[Copy Multiple]^c^cSelect Au \Copy P  Mul \

AutoCAD's implied windowing is activated for the first screen pick, 
after that you have to physically type "W" or "C" to get a selection 
window.

If you change the menu line to:

	[Copy Multiple]^c^cSelect \Copy P  Mul \

AutoCAD's implied windowing is never activated.  Several of the R13 
Windows toolbar menu items including the variations on ARRAY use this 
method, and therefore implied windowing does not work on these items.

Finally, if you change the line to:

	[Copy Multiple]^c^cCopy \

AutoCAD's implied windowing is only activated after the fourth pick.  

The only known workaround is to replace the menu macro with a lisp 
routine.


4.	[Common 12-13c2]  Bug.
Create a visible attribute on layer 0.  Create a block called TEST which 
consists solely of the attribute you just defined.  Make a new layer 
called HOWCOME and insert the TEST block onto this layer and enter "THIS 
IS TEXT" at the attribute value prompt.  Freeze layer 0.  The attribute 
value of "THIS IS TEXT" is still visible on the screen, as it should be 
since anything created on Layer 0 is supposed to take on the properties 
of the insertion layer.  Now try to select the block using any command, 
including DDATTE, ERASE, MOVE, COPY, etc. and you will not be able to.

The only known workaround is to THAW Layer 0.


5.	[DOS 12-13c2]  Undesirable behaviour.
With FILEDIA=1, if you have a repeating menu command such as  
[Nothing]*^C^CINSERT NOTHING  which attempts to insert a non-existent 
block, the ACAD displays a text message stating that the block can't be 
found, then repeats the command as it should because of the '*' prefix.  
At this point, if you hit any key other than ^C, ACAD will enter an 
infinite loop attempting to insert a non-existent block.  At this point 
the only way out is to re-boot the computer, losing any work since your 
last save.

No known workaround.


6.	[Common 12-13c2]  Bug.
If you perform a Dview Twist on a drawing, then plot with a window, the 
coordinates of the window corners displayed in the new plot dialogue box 
do not match the actual coordinates that were picked.  Regardless of 
what the plot window shows, the actual coordinates picked are used for 
generating the plot.  This appears to related to the variable "TARGET", 
which changes after a DVIEW, but never seems to be set back to its 
default value (ie. start a new drawing, look at the value of TARGET, 
then do a Dview Twist 300, Dview Twist 0, and then look at TARGET again 
and it is different).

No known workaround.


7.	[Common 12-13c2]  Bug.
When using the Shift to Add feature for building selection sets, the 
Window, Crossing, Previous, Last, etc. selection options add to the 
current selection set instead of replacing it as documented.

No known workaround.


8.	[Common 12-13c1, FIXED 13c2]  Bug.
After restoring a PCP file which has a default plot file name which 
contains a path, any PCP files saved (during the same editing session) 
will contain the default plot file name with path that was originally 
read in, instead of the current default plot file name.


9.	[Common 12-13c2]  Inadequately implemented feature.
The TRIM with Fence option does not work correctly with polylines or 
splines which cross the trimming boundary more than twice.

The only workaround is to keep repeating the TRIM command or Fence 
option until all of the polyline or spline is gone.


10.	[Common 11-13c2]  Bug.
If you create a custom linetype that consists of a repeated sequence of 
two or more dots, AutoCAD doesn't display or plot the linetype 
correctly.  For instance, suppose you create a "3-dot" linetype (a 
sequence of 3 closely spaced dots, followed by a wide space, followed by 
3 more dots...) by adding the following linetype definition to ACAD.LIN:

	*3DOTS,... ... ... ... ...
	A,0,-.25,0,-.25,0,-.5

When you draw random line segments with this linetype, in some of the 
segments the dot groupings are incorrectly spaced or contain the wrong 
number of dots.

Although there is no completely effective workaround, drawing polylines 
with linetype generation turned on minimises the problem.  The first and 
last sequences of dots are still wrong, but the remaining dots are fine.  
To turn on linetype generation, set the system variable PLINEGEN to 1 
before drawing the polylines.  Use the Ltype gen option of the PEDIT 
command to change existing polylines, or the R12 bonus routine PLUD if 
you have it.


11.	[DOS 12-13c2]  Bug.
With only the DOS version of AutoCAD, the "alignment=right" DCL command 
does not work for text.  Instead, it displays the text as left 
justified.

No known workaround.


12.	[DOS 12-13c2]  Amusing buglet.
There is a problem with any command which uses the File Dialogue box to 
allow for file selection.  When you change the file search pattern so 
that it matches enough file names to require the slider bar to be used 
then slide the bar to the bottom of this list it jumps back to the top 
of the list.  To see this, load a drawing with enough blocks to enable 
the sliders in a list box.  Call DDINSERT and pick Block to get a 
listing of the blocks.  Change the Pattern specification to anything 
that will retain the sliders (or just delete the "*" and enter it 
again).  Then slide the list to the bottom and release - it goes back to 
the top of the list.  It happens whenever you change the Pattern 
specification.

Workaround: it will work correctly if you do it a second time.  It only 
happens the first time after changing the Pattern specification.


13.	[Common 12-13c1, FIXED 13c2]  Bug.
ATTEXT limits the field length to 99 characters even though an attribute 
can hold 256 characters.  The problem isn't with the 256 character limit 
on input to an ATTDEF, but the fact that the ATTEXT command won't allow 
a field with of greater than 100 characters, ie.  the extract format 
'POINT C101000' generates an error and the attribute extract doesn't 
work.


14.	[Common 12-13a, FIXED 13c1]  Bug.
VPLAYER can freeze Xref'd layers, but doesn't thaw them when the Xrefs 
are detached.  If a DXFOUT is performed, the DXF file VPORT entity 
information references Xref'd layers, which yield an invalid DXF file 
upon DXFINing into an empty drawing.

Example operation:

a)  Create a drawing, called CHILD, with two layers, ONE and TWO.  Place 
a circle on each layer.  Save the drawing.
b)  Create a drawing, called PARENT, and XREF Attach CHILD.
c)  Set TILEMODE to 0 (switches to paper space).
d)  Create a viewport using MVIEW.
e)  Use VPLAYER to freeze CHILD|ONE in the new viewport.
f)  Detach the CHILD Xref.
g)  DXFOUT the PARENT drawing to PARENT.DXF.
h)  Use the NEW command to create a new drawing, specifying No 
Prototype.
i)  DXFIN PARENT.DXF.  An error, "Invalid layer name in 1003 group on 
line <line_number>" is reported.

VPLAYER WON'T remove the invalid layer once the Xref has been detached - 
it's only removed when the drawing is loaded into the drawing editor.

Workarounds: i) detach the Xref(s), save the drawing, reopen the 
drawing, then DXFOUT; or ii) erase the VPORT, create a new one of 
exactly the same size (and model space view), then reset all the OTHER 
VPLAYER settings.


15.	[Common 12-13c2]  Inconsistent behaviour.
The "0" layer controls the visibility, colour and linetype of any 
objects placed on the DEFPOINTS layer.  This isn't a real problem, once 
you're aware of it, but it does conflict with the expected operation of 
AutoCAD, where objects placed on the DEFPOINTS layer, and coloured and 
linetyped BYLAYER are expected to take on the visibility, colour, and 
linetype of the DEFPOINTS layer, not the "0" layer.


16.	[Common 12-13a, FIXED 13c1]  Bug.
A general protection exception will occur when using DDRENAME to rename 
200+ layers and the wildcard capability of DDRENAME.

No known workaround.


17.	[Common 13c2]  BW  Bug.
The BOUNDARY (BPOLY) dialogue box has a "Boolean Subtract Islands" 
toggle which should delete islands from the boundary.  This option is 
greyed out when the command is invoked, with no way of making it 
available.

No known workaround: modifying ACAD.DCL does not help.


18.	[Common 13a, FIXED 13c1]  Bug/omission.
The 3DSOLID entities SPHERE and TORUS do not respect the CENter object 
snap.

Workaround: draw construction lines or points before creating these 
solids, or use grip editing to locate entities on the centres.


19.	[Common 13c1, FIXED 13c2]  Bug/omission.
Geometric tolerance entities support only the INSertion point and 
INTersection object snaps.

No known workaround.


20.	[DOS 13a, FIXED 13c1]  Minor irritant.
The LIST command on 3DSOLID entities is not formatted correctly for a 
80-column DOS screen: the bounding box coordinates wrap around.

No known workaround.


21+	[Common 13-13c1, FIXED 13c2]  Omission.
The DXFIX program mentioned in the documentation (CR-746) is not 
provided with R13.  If it were provided as documented, it would be a 
nonsense inclusion, because it converts R12 DXF files to R10 DXF files 
and R13 provides no mechanism for creating R12 DXF files.  This poses a 
problem for users who need to communicate with other packages which do 
not yet support the more complex R13 DXF format.

Workaround: use the SAVEASR12 command in R13, then read that drawing 
file into R12 or AutoCAD LT and create a DXF file from there.

Fix: An updated version of DXFIX was made available at the same time as 
c2.  Download the files DXFX13.TXT and DXFX13.EXE from library 2 
(Drivers and Updates) of the CompuServe ACAD forum.


22.	[Win 13c1, FIXED 13c2]  BW  Bug.
The AutoLISP function (getfiled) is supposed to display an image preview 
in the dialogue box when "dwg" is passed as the extension argument.  
Although the image preview tile appears, under Windows no image previews 
are displayed in the tile.  One Autodesk-suppled routine this affects is 
DDINSERT.  See items 23 and 158 for similar or related problems in DOS.

No known workaround.


23.	[DOS 13c1, FIXED 13c2]  Bug.
The OPEN command in DOS does not display an image preview in the 
dialogue box when the length of the drive and directory string exceeds 
the length available to display it (35 characters on my system).  The 
same applies to the AutoLISP function (getfiled) when "dwg" is passed as 
the extension argument.  See item 22 for similar problem in Windows and 
item 158 for further DOS (getfiled) difficulties.

No known workaround.


24+	[Win 13a, FIXED 13c1]  Bug.
The OPEN command in Windows automatically turns on the "Read only" 
toggle in deeply nested directories.  If the length of the drive and 
directory string exceeds the length available to display it (29 
characters on my system, but it varies), an ellipsis (...) is used, and 
it is this which triggers the bug.  Also, when attempting to SAVE such 
drawings, a warning dialogue "This file already exists.  Replace 
existing file?" is incorrectly issued.  Item 195 has identical symptoms 
but a different cause.

Workarounds: use shorter directory names or move the drawings up the 
directory path.  Alternatively, turn off the "Read only" toggle at the 
time of opening.  If you have done none of these, set the system 
variable DWGWRITE to 1 (this makes the current drawing not read-only) or 
save the drawing under a different name.  One possible workaround which 
effectively disables read-only mode is to set DWGWRITE to 1 in ACAD.LSP, 
or in the menu items which perform saves.


25.	[Common 13c1, FIXED 13c2]  Bug.
If the previous drawing was opened in read-only mode, any NEW drawing 
started will also be read-only.

Workarounds: set the system variable DWGWRITE to 1 (makes the current 
drawing not read-only) or save the drawing under a different name.


26.	[Common 13a, FIXED 13c1]  Bug.
DIMDIAMETER or DIMRADIUS dimensions do not edit correctly if they have a 
DIMLFAC setting other than 1.  When such a dimension has its text grip 
edited or stretched, the distance between the defining points (ie. the 
arrowheads on a diameter or the arrowhead and the centre on a radius 
dimension) is multiplied by the DIMLFAC of that dimension.  eg. if a 
diameter has a DIMLFAC of 2, the dimension will double in size each time 
the text is grip edited.  The text value and the size of the arrowheads 
and text all remain the same.  Once one of these dimensions has been 
grip edited, the DIM UPDATE command has unexpected results, such as 
modifying the dimension text to match the distance between the defining 
points, then moving the defining points proportional to the DIMLFAC, as 
per the original grip editing bug.

No known workaround.


27.	[Common 13c1, FIXED 13c2]  BW  Bug.
Cancelling at a certain point in the DIM Leader command crashes AutoCAD.  
The following sequence will do it: DIM LEADER <pick> <pick> [Return] 
[Esc].  In DOS, this causes an "INTERNAL ERROR: Page fault (or Null 
pointer) exception", and in Windows a "FATAL ERROR: FATAL ERROR: 
Segmentation violation".

Workaround: use the LEADER command directly at the "Command:" prompt 
rather than via the DIM command.


28.	[DynaText]  Bug.
The DynaText on-line documentation facility gets stuck in a loop while 
reading the disk under different circumstances.  Triggers include using 
the Help facility and trying to view a graphic.


29.	[13a and 13c1 Patches to 13]  Bug.
The 13a and 13c1 patches do not work if the fields in the 
personalisation screen for "Company" and/or "Dealer" have been filled 
with as many characters as possible.  The patch installation routine 
reports a message "error ept0036: Old File not found. However, a file of 
the same name was found.  No update done since file contents do not 
match.  Installation not complete."

Workaround: reinstall AutoCAD using a copy of the backup you made of the 
installation disk (you did make a backup before you used it, didn't 
you?), and this time don't use all of the characters in "Company" and 
"Dealer".


30.	[Win 13c2]  BW  Bug.
In the Windows menu file, Alt Tablet 3 has 2 menu items containing "+\".  
This gets incorrectly stripped down to "\" in the ACAD.MNS file, and the 
menu items therefore do nothing.  Each item actually just pauses for 
user input, instead of typing "+" and then pausing.

Workaround: modify the Windows menu file lines to each contain "X^H+\" 
(not including the quotes) instead of "+\".  In 13c2, the lines to 
modify are 5894 and 5895 in ACAD.MNU and 6199 and 6200 in ACADFULL.MNU.


31.	[Common 12-13c2]  BW  Bug/limitation.
In AutoLISP DCL edit boxes, a string limit of 111 characters is imposed 
when the $value variable is used in a callback function, rather than 255 
characters.

Workaround: use (get_tile) instead of $value.


32.	[Common 13c2]  BW  Bug.
When an anonymous block (eg. dimension, hatching) is no longer 
referenced (eg. after explosion), the block references are supposed to 
be automatically purged as the drawing is opened.  This purge is not 
happening in R13, leading to files which build up in size over time.

Workaround: the anonymous blocks (eg. *D1 or *X234) may be PURGEd 
manually.


33.	[Common 13c2]  BW  Bug.
When a text entity is generated in an AutoLISP routine using (entmod) or 
(entmake) for non-left-justified text, it was common practice prior to 
R13 to set the 11 point to the desired location, and set the 10 point to 
0,0,0.  AutoCAD would then use the 11 point and update the 10 point.  
R13 does not do this.  The upshot is that existing AutoLISP routines 
which create or modify text may place the text incorrectly, often at 
0,0,0.

Workaround for programmers: set both 10 and 11 points to the same value 
before using (entmod) or (entmake).


34.	[Common 13c1, FIXED 13c2]  BW  Bug.
The MONOTXT font file is supposed to be equally spaced, but is not in 
R13.  Instead, it is identical to the proportionally spaced TXT font 
file.  See item 208 for a similar problem in reverse.

Workaround: the R12 .SHX file should work if you have it and don't mind 
breaking your licence agreement.


35.	[Common 13a, FIXED 13c1]  Bug.
Performing an MLEDIT on MLINES with Zero (centre) justification crashes 
AutoCAD.  In DOS, MLEDITing an open MLINE pair causes an internal error, 
and in Windows a "FATAL ERROR: FATAL ERROR: Segmentation violation".  
Top and Bottom justification work as expected.

No known workaround.


36.	[Common 13c2]  BW  Bug.
The DDUCSP (UCS Presets) command is implemented as an AutoLISP routine, 
and this does not handle undo and running object snaps correctly.  If 
you have a running object snap set, use the DDUCSP command, then undo, 
your running object snap will be turned off.  The same applies to the 
system variable CMDECHO being turned off after this and other Autodesk-
supplied AutoLISP routines and an undo.  However, this does not matter 
to normal users and would matter only extremely rarely to programmers.

No known workaround.


37.	[Common 13c2]  BW  Bug/feature deficiency.
MTEXT entities in drawings created in R13 and saved in R12 format 
default to using the STANDARD text style rather than the style of the 
original entities.  This occurs even in the common, simple case where a 
single style has been used for all of an MTEXT entity.

Workaround: if you usually use a common text font (eg. ROMANS), define 
the STANDARD text style to use that font.


38.	[Windows 13c2]  BW  Minor bug.
In Windows, the Object Properties toolbar contains a popup list for 
selecting the current linetype.  If this is set to BYLAYER, the display 
does not change to reflect the linetype of the current layer.  If you 
pop the list up (down?), the correct linetype is displayed on the list, 
but even picking the BYLAYER item does not correct the display.

Workaround: if you think it is worth it, pop up the list and choose some 
other linetype, then choose BYLAYER again.


39+	[DOS 13-13c1, FIXED 13c2]  Bug/feature removal.
The AutoLISP function (setfunhelp) and the ADS function ads_setfunhelp() 
cause crashes in DOS versions 13 and 13a, and was temporarily removed 
from DOS version 13c1 until it was fixed in 13c2.  Transparent help from 
AutoLISP was not available at all in DOS 13c1.

No known workaround.


40.	[CG-398]  Documentation error.
The documentation for the AutoLISP function (dictnext) is wrong.  The 
correct syntax is (dictnext ename [rewind]).  The only valid ename 
passed to (dictnext) and (dictsearch) is the return from (namedobjdict).


41.	[Win 13c1, FIXED 13c2]  Bug.
When the SAVEASR12 command is used in Windows, the menu name is stored 
in the R12 drawing with a ".mnc" extension.  When the drawing is read 
into R12, a "Wrong file type" error is issued and the user must reselect 
the menu file.

No known workaround.


42.	[Common 13c1, FIXED 13c2]  Bug.
When the R13 XREF Overlay option has been used in a drawing, the 
SAVEASR12 command does not correctly translate the external references.  
Each Xref appears as a piece of text which specifies the Xref path.  If 
the file is listed in R12, it is shown as an "External definition" 
rather than an "External reference".  If you subsequently save and open 
the drawing in R12, it complains that the file is not a master drawing 
and does not resolve the Xref.

Workaround: the XREF Reload option makes the Xrefs appear correctly and 
list as "External reference", but they cannot be selected until the 
drawing is saved and opened again in R12.


43.	[Common 13c1, FIXED 13c2]  BW  Bug.
MTEXT and dimensions now use Unicode symbols to allow the inclusion of 
special characters like diameter symbols.  However, in dimensions, the 
old %% symbols (eg. %%c for diameter) are still allowed to provide 
compatibility with earlier versions.  The bug is that this feature has 
become case sensitive, eg. %%c works, but %%C does not.

Workaround: don't use upper case.


44.	[Common 13c1, FIXED 13c2]  BW  Bug.
If you insert a drawing using the * prefix, then undo this operation, 
AutoCAD crashes with a general protection exception in DOS or unhandled 
exception in Windows.

Workaround: insert without the *, then explode and purge the block.


45.	[Installation 13a]  Bug.
When installing R13 on a network, the installation program complains 
that it is unable to create some subdirectories, and does not perform 
the installation.

Workaround: create these directories manually, or use the batch file 
provided in the file R13DIR.ZIP in the CompuServe ACAD forum library.


46.	[Common 13 onwards, half FIXED 13c1]  Bug/incompatibility.
Binary DXF files created by previous releases of AutoCAD cannot be 
imported into R13, and vice-versa.  Only workaround is to use another 
conversion format.  The fix in c1 allows early binary DXF files to be 
read in R13, but R13 binary DXF files will never be able to be read by 
earlier releases of AutoCAD.

No known workaround.


47.	[Win 13c1, FIXED 13c2]  Bug.
When using the SAVEAS command in Windows, the message which indicates 
that the drawing is being saved shows the wrong filename.  It shows the 
old name, not the new name under which the drawing is actually being 
saved.

No known workaround.


48.	[Common 13c2]  Limitation.
MTEXT entities have an arbitrary limit of 100 lines of text.  All lines 
beyond 99 will be placed on the last line.

Only workaround is to split the text into more than one entity.


49.	[Common 13c2]  Design flaw.
By default, R13 associative dimensions do not have a separate grip on 
the text as they did in R12.

This can be worked around by setting the DIMFIT system variable to 4, 
but there is still no way of moving the text significantly away from the 
dimension line without a leader line being drawn automatically between 
the text and the dimension line.


50.	[Win 13c2]  Design flaw.
The OPEN drawing preview screen in Windows uses white as its background, 
rather than the same background as the drawing area.  This makes many 
drawing previews hard to read.  The same applies to BMP files created 
using BMPOUT.

No known workaround.


51.	[Common 13c1, FIXED 13c2]  BW  Bug.
When using Pick Point in DDATTDEF, Middle justified text is always 
placed at 0,0 instead of where you place the pick point.

Workaround: edit line 529 of the file DDATTDEF.LSP.  The line in the 
file is:

	(command "_j" "_m" "1,1,1")  ;;pt

Change it to:

	(command "_j" "_m" pt)


52.	[Common 13c2]  Incompatibility.
The BMPOUT command creates compressed BMP files which cannot be read by 
several common packages, including Windows Paintbrush.

Workaround: read and write the R13 BMP files using a more forgiving 
translation package, or use an alternative transfer mechanism instead, 
such as copyclip and paste.


53.	[Win 13a, FIXED 13c1]  Abnormal performance degradation.
Drawings which contain text in styles defined with bigfonts suffer badly 
under R13 Windows, even if none of the bigfont characters are used.  The 
drawings appear to be thrashing all the time, despite sufficient memory.

Workaround: change the bigfont text to a style which does not use 
bigfonts.


54.	[FIXED by new Matrox driver]  Not an AutoCAD bug.
This is a bug in a third party driver which AutoCAD shows up.  Running 
R13 Windows under NT 3.5 using the Matrox board and driver causes some 
graphics problems.  When using tabbed dialogue boxes (eg. PREFERENCES), 
the dialogues often appear blank.  This problem does not occur using 
other Windows software on the same systems.

Workaround: boot up under VGA long enough to make a drawing of which 
buttons are where, then when using the Matrox driver use the Tab key to 
move around in the dialogue.  As you move, each button, edit_box, etc. 
will appear properly.

Fix: contact Matrox for driver 2.10.015 or later.


55.	[Win 13c2]  Design flaw.
The background of the Windows MTEXT editor does not match the graphics 
background.  It is usually white, which makes editing light-coloured 
text a little difficult.  In 13c2, white text is displayed as black, 
which if not accurate, is at least readable.

No known workaround.


56.	[Common 13-13c1, FIXED 13c2]  Design flaw.
The stacked fractions feature of R13 was not made optional on dimensions 
using fractional units.  These dimensions are often not readable when 
plotted.  13c1 introduced a partial workaround whereby the size of the 
text can be specified using the DIMTFAC variable, but it was still not 
possible to turn stacking off completely until 13c2.

Workaround: at least one third-party routine has been written to unstack 
these fractions.  This can be downloaded from the CompuServe ACAD forum.


57.	This was a duplicate of item 21 and has been removed.


58.	[Common 13c1, FIXED 13c2]  BW  Bug and documentation error.
According to Autodesk, the documentation relating to the STLOUT command 
is actually incorrect in stating that STLOUT should respond to the 
FACETRES system variable.  STLOUT does not normally respond to FACETRES 
nor is it supposed to.  The number of facets you get on a cylinder will 
vary depending on the drawing extents and size of ACIS object relative 
to the extents of the drawing.  However, in 13c1 there was a handy bug 
that caused STLOUT to indirectly respond to FACETRES if a hide or shade 
was done after FACETRES was set, but just before the STLOUT.  In 13c2, 
Autodesk changed the software to match the documentation and STLOUT now 
does respect FACETRES.


59+	[Common 13c2]  BW  Bug.
The SAVE command always performs a SAVEAS in R13, ie. if you save under 
a different name it not only creates a different DWG file, it also 
changes the name in memory of the current drawing.  This is contrary to 
both the documentation and the behaviour of previous releases.  The SAVE 
and SAVEAS commands are documented as separate, different commands in 
both the command reference and the on-line help.  The SAVEAS command is 
indicated as being the one which invokes the Save Drawing As dialogue 
and which renames the current drawing.  The SAVE command is supposed to 
invoke the Save Drawing dialogue if the drawing is named, but that 
dialogue appears not to exist.  Any QSAVEs you perform subsequent to 
such a SAVE will overwrite the wrong drawing.

No known workaround other than performing two SAVEAS commands to save 
under the desired name, then reset the current drawing name.


60.	[Win 13a, FIXED 13c1]  Bug.
To create stacked alternate units dimensions in R13 (eg. millimetres 
above, inches below), set up the alternate units, set the vertical 
justification to centred, use the Text option when placing the 
dimension, then enter "<>\X[]" (not including my quotes).  The automated 
way of doing it is to set suffix text of "\X" for the primary units.  
These methods work as expected in R13 DOS, but in R13 Windows, always 
leave "\" behind the upper dimension.

No known workaround.


61.	[Common 13a, FIXED 13c1]  Bug.
When using DDEDIT on dimensions, whatever format string has applied to 
the dimension seemingly makes no difference: the text editor almost 
always has "<>" as its default text.  Say you have a dimension which 
uses a format string entered at the time of dimension creation, you 
DDEDIT it but do you nothing in the editor.  When you return to the 
drawing, your dimension will lose its format string.

No known workaround.


62.	[Common 13a, FIXED 13c1]  Bug.
When using DDEDIT on dimensions, if you apply a format string of 
"<>\X[]" in the text editor, the resulting dimension has a gap in the 
dimension line.  The same format string applied at the time of creation 
leaves a solid dimension line.  If you DDEDIT the previously DDEDITed 
dimension (the one with the format string of "<>\X[]"), the text editor 
contains two lines: one has "<>" on it, the other "[]". It seems that 
"\X" is being interpreted somewhere as "\P".

No known workaround.


63.	[Win 13c2]  Oversight.
In Windows, the Properties icon for the DDMODIFY command loads in the 
lisp routine (ai_propcheck), then does DDMODIFY if required.  The 
problem is you can't repeat the command by pressing Enter (it repeats 
the command before that).

Workaround: define a C:XXX command function for (ai_propcheck).  This 
will allow users to hit Enter to repeat the command.


64+	[Common 13c1, FIXED 13c2]  BW  Bug.
In R13, the system variable SAVENAME is broken.  In DOS, it is always 
the empty string "", and in Windows it sometimes contains a drawing name 
but usually the wrong one.

Workaround: the DWGNAME and DWGPREFIX variables contain similar 
information.


65.	[IGD-22]  Documentation error.
The Installation Guide for DOS states that R12 ADI 4.2 drivers are 
incompatible with R13.  This is not true: many drivers will work 
faultlessly.


66.	[CG-548, CR-214, CR-235]  Undocumented or missing entity or 
documentation error.
The Customization Guide gives DXF group codes for an entity called a 
BODY, and the Command Reference shows the dialogue box that appears when 
you use DDMODIFY on a BODY entity.  There is no other reference to BODY 
other than a statement under EXPLODE.


67+	[Common 13 onwards]  Bug fix causing compatibility problem.
R13 corrected a bug or "difference" with R12 .PFB font handling, where 
character height was based on the typesetter's "cell height" instead of 
the draftsman's "caps height".  This has the effect of making almost all 
.PFB fonts about 30% larger in R13, so the appearance of such text in 
R12 drawings will change in R13.

Workaround: change the individual text heights to what they should have 
been, ie. reduce the height of each entity.  Various AutoLISP routines 
can be used to make this less difficult, including CHTEXT.LSP which came 
with R12.


68.	[Win 13a, FIXED 13c1]  Bug.
In .MNU files, the ***ICON section of previous releases has been renamed 
***IMAGE, but the old form is supposed to still work in R13 (CG-113).  
In Windows, this does not work.

Workaround: change ***ICON to ***IMAGE.


69.	[Common 12-13c2]  Limitation.
In DCL dialogue boxes, it is not possible to create multiple-selection 
list boxes which allow the selection of large numbers of items.  The 
limit is 87 items, assuming the that they are picked consecutively 
starting with item 0 (the first in the list).  The interface is dealing 
with a 255 character limit, so that restricts how many can be selected.

No convenient workaround.


70.	[Common 13a, FIXED 13c1]  Bug.
When trimming splines, sometimes the spline sections which should be 
removed are left behind.  The spline is correctly broken, but the 
trimmed section remains in place.

Workaround: erase the remaining spline sections.


71+	[Common 13c1, FIXED 13c2]  BW  Bug.
The LEADER command places the arrow at the wrong point if ORTHO is on.  
Rather than being placed at the point picked, it is placed at a point 
orthogonal to the point picked in relation to the last point picked in 
the drawing, or to the edge of the screen if no points have been picked 
during the drawing session.

Workaround: turn ORTHO off before picking the first point, then turn it 
on again.


72.	[Win 13c2]  Inconsistent behaviour.
COPYCLIP can be invoked transparently, but it does nothing.

Comment: this was done deliberately to prevent the word COPYCLIP being 
entered accidentally at a text prompt when a user was trying to cancel a 
command.

Workaround: don't do that, it doesn't work.


73.	[Common 13c1, FIXED 13c2]  Bug.
On diameter or radius dimensions, the diameter or R symbol ceases to be 
displayed if the dimension text is changed.  For example, a radius 
dimension is drawn, and its the default text is "R5.00".  If DDEDIT is 
used to change the text from its default "<>" to "APPROX <>", then the 
dimension appears as "APPROX 5.00", not "APPROX R5.00" as it did in 
earlier versions of AutoCAD.

Workaround: include the symbol explicitly in the text, eg. "APPROX R<>".


74.	[Common 13c2]  Bug.
Drawing a tangent FROM a spline-based ellipse (or any spline curve) does 
not work.  Instead, a seemingly arbitrary point on the ellipse is 
chosen, which is actually tangential to the last point drawn.  The same 
applies to the PERpendicular object snap.

No known workaround.


75.	[Common 13c2]  Documentation error.
In the HELP facility, it states that PURGE can only be run before the 
drawing database is altered.  This is not true in R13.


76.	[Common 13c1, 13c2, part FIXED 13c2]  Bugs.
In the ASE sample AutoLISP program \ASE\SAMPLE\ASESMP.LSP, the standard 
function names COND and TYPE are used as variables.  This is very bad 
programming practice and can cause subsequent innocent AutoLISP programs 
which correctly uses these functions to crash.  This has been fixed in 
13c2.  Similarly, in DDMODIFY.LSP the standard function name TYPE is 
used as an argument to a function.  This remains unfixed in 13c2.


77.	[Common 13a, FIXED 13c1]  Bug.
Geometric tolerancing frame grips are not properly aligned on the right 
side of the frame (they are typically further right than they need to 
be).

No known workaround.


78.	[Common 13c1, FIXED 13c2]  Bug.
If the units are set to architectural and the LENGTHEN command is used 
with the Percent option, the percentage default displays using feet and 
inches (eg. 8'-4"), rather than as a percentage.  If you enter a feet 
and inches number, it is rejected with a "Requires numeric value" 
message.

Workaround: you can enter the required percentage in the conventional 
manner.


79.	[Win 13c1, FIXED 13c2]  Bug.
Under Windows, the OPEN command's Find File/Search option does not work 
with wildcards other than *.dwg.  When wildcards are used, no drawings 
are listed even if there are some which match the wildcard 
specification.

No known workaround.


80.	[Win 13c1, FIXED 13c2]  Bug.
The Color dialogue in the Windows MTEXT dialogue does not allow use of 
the colour BYLAYER (the option is greyed out).  Same applies to BYBLOCK.

Workaround: using an AutoLISP routine or similar, you can change a 
section of mtext to colour 256 for BYLAYER, and this seems to work 
correctly.  For example, the following mtext uses colour BYLAYER for the 
word BROWN:

	{THE QUICK }{\C256;BROWN}{ FOX}

At least one third-party routine has been written which will allow you 
to do this.  This can be downloaded from the CompuServe ACAD forum.


81.	[Win 13a, FIXED 13c1]  Inconsistent behaviour.
After you type in a value in the text height field in the MTEXT editor, 
unless you press Enter, the value does not appear to be accepted.  
Normal dialogue box behaviour is to have the value of the field accepted 
when you leave the field by clicking somewhere else.  The value you type 
is actually used by the editor, but the old value is incorrectly 
displayed.


82.	[Common 13c2]  BW  Bug.
When using the DIMANGULAR command, if the angle is small enough for the 
text to get in the way of the arrowheads, the arrowheads flip through 90 
degrees such that they are placed along the extension lines rather than 
perpendicular to them.

No known workaround.


83.	[Common 13a, FIXED 13c1]  Bug.
Use DIMDIAMETER and pick a circle.  Now type "A" for Angle option, then 
press Esc (we changed our minds).  Even though we cancelled, R13 still 
draws the dimension.

No known workaround.


84.	[Common 13c1, FIXED 13c2]  Bug.
Using either DIMCONT or DIMBASE on an angular dimension that goes 
anticlockwise will generate a clockwise dimension.

No known workaround, other than to edit the dimensions after creation.


85.	[Common 13c1, FIXED 13c2]  Design omission.
The R13 semi-associative dimension leaders do not provide any mechanism 
for user-defined arrowheads, ie. DIMBLK is no longer respected for these 
entities.  The DDIM command rather unsportingly leads you to believe 
this can be done, but lets you down when you actually draw a leader.

Only workaround is to use a 3rd party routine which has a more open 
architecture than AutoCAD, but this means the leaders will be non-
associative.


86.	[CR-743]  Documentation omission.
There is no description of the USERR, USERI and USERS system variables, 
although they still exist and work as in previous versions of AutoCAD.


87.	[Common 13c2]  Bug.
The AutoLISP function (textbox) and the ADS function ads_textbox() do 
not honour the new RTF style text properties.  The two function calls 
below should return the same values, because both describe the word 
Hello with the two 'l's underlined.  Using a TXT style and height of 
1.0,

	(textbox '((1 . "He%%ull%%uo")))

returns ((0.0 -0.2 0.0) (4.0 1.0 0.0)), but

	(textbox '((1 . "He\Lll\lo")))

returns ((0.0 0.0 0.0) (5.66667 1.0 0.0)).  No known workaround.

No known workaround.


88.	[Common 13c2]  Limitation.
The FROM object snap is disabled when dragging objects.

Workaround: turn DRAGMODE to OFF or ON rather than AUTO.


89.	[Win 13c1, FIXED 13c2]  Incompatibility.
When running the Windows version of R13 under Windows NT (not a 
supported operating system for 13c1), attempting to customise the 
toolbar icons using the icon editor causes a crash.

Only workaround is to use it under plain old Windows 3.X.


90.	[CR-675]  Undocumented behaviour.
If you use the WBLOCK command, specify the name of an existing file and 
then cancel the command, the specified drawing file is erased from the 
disk.  AutoCAD has worked like this as long as anyone can remember, but 
this behaviour is not documented and something as important as this 
should be pointed out.


91.	[DOS 11-13]  Apparent lock-up.
When AutoCAD DOS runs out of disk space for its temporary files, it 
seems to lock up.  There is neither disk activity nor any error 
messages.  Sometimes AutoCAD will come back to the world of the living 
after a long sleep.

Only workaround is to make more disk space.


92.	[Common 13c2]  Bug.
The AutoLISP function (entmod) does not work immediately when applied to 
the LAYER table.  Changes to the visibility and/or colour of a layer 
entry do not take effect in the drawing after an (entmod), an (entupd) 
or even a REGEN.

Workaround: use (command "LAYER" "") after the (entmod), then REGEN.  
Alternatively, use (command "LAYER") for everything.


93+	[Win 13c1-c2]  BW  Bug.
In 13c1 onwards, Windows attempting to change the Preferences System 
Font setting does not have any effect on the command or text windows.  
It does change the font used by the screen menu and the text under the 
Autodesk logo when a drawing session starts.  

Workaround: if you install 13c0, then change the font prior to 
installing the c1 and c2 patches, your chosen font will be retained.


94.	[Common 13c2]  Bug.
In complex linetype definitions with text, if the X and Y offsets are 
omitted or set to 0, the text is supposed to be elaborated (drawn) using 
the centroid of the text (CG-42).  Instead, the lower left corner of the 
text is used.

Workaround: provide explicit offsets to place the text in the right 
spot.


95.	[Common 13c2]  BW  Bug.
The new R13 dimension leaders do not respect the dimension line and 
leader colour setting in a consistent way.  If you set the DIMCLRD 
variable in a dimension style, this automatically updates the colour of 
dimensions, but not leaders.  New dimensions respect the DIMCLRD 
setting.

Workaround: DIM Update updates existing leaders in 13, 13a and 13c2, but 
not in 13c1.


96.	[Common 13c2]  BW  Bug.
Dimension leaders do not respect the dimension text colour setting in a 
consistent way.  If you set the DIMCLRT variable, this is respected by 
dimensions drawn using the DIM Leader command in 13, 13a and 13c2, but 
not in 13c1, nor by the LEADER command from the "Command:" prompt in any 
version.  It is not possible to fix them with DIM Update, as R13 leader 
text is drawn as a separate MTEXT entity, rather than being associated 
with the leader as stated in the written documentation.

Workaround: use the CHPROP command to set the colour of the MTEXT 
entities.


97.	[Common 13c1, FIXED 13c2]  Bug.
Dimension leaders created with the DIM Leader command do not use the 
current dimension text style setting DIMTXSTY.  Instead, the STANDARD 
text style is used.

Workaround for 13c1 only: use the LEADER command directly at the 
"Command:" prompt rather than via the DIM command.  See item 198 for a 
similar bug in 13c2 with the LEADER command.


98.	[Common 13c2]  Bug.
Dimension leaders created with the DIM Leader command have badly aligned 
text in which the baseline of the text coincides with the leader line.

Workaround: use the LEADER command directly at the "Command:" prompt 
rather than via the DIM command.


99.	[Common 13c2]  Strange conversion.
Dimension leader lines created with the LEADER command get converted to 
several individual single-segment 3DPOLY entities when the SAVEASR12 
command is used, rather than a single PLINE or several LINE entities 
which would seem to make more sense.

Workaround: explode the 3DPOLY entities if you need LINE entities for 
editing reasons.


100.	[Win 13c1h, FIXED 13c2]  Undocumented restriction.
Although R13 Windows runs under Windows NT and provides several 
significant advantages in that environment, this is only true for 
US/Canada versions of R13.  R13 versions with a dongle (hardware lock) 
do not run, despite the fact that dongled R12 Windows could run using an 
NT driver from Rainbow, the makers of the AutoCAD dongle.

Workaround: move to North America or wait for the real NT version of 
R13.


101.	[Common 13c2]  BW  Bug or irrational behaviour impairing 
performance.
Use the BHATCH or BOUNDARY (BPOLY) command with the "Pick Points <" 
option while any blocks with attributes are even partly visible on the 
screen.  Each visible block will regenerate and in 13c1 or earlier each 
attribute (even if off-screen) will change to display the tag (rather 
than the value) of the attribute and the drawing remains in that state 
after the command is finished until the next regeneration.  This 
explosion can be extremely time-consuming.  The command attempts to 
explode everything in sight, even 3DSOLID entities which cannot be 
exploded, resulting in a warning message for each visible 3DSOLID 
entity.  In some cases, a mysterious message "make_edge failed in 
TCODE_VERTEX" is displayed, although this does not seem to do any harm.

Workaround: if possible, zoom in such that blocks with attributes are 
not visible.


102.	[Common 13c1, FIXED 13c2]  Bug.
The DDCHPROP dialogue box has two edit boxes: one for linetype scale and 
one for thickness.  If either of these properties is not the same for 
every entity in the selection set, the edit box is set to "Varies".  
When this occurs, the command refuses to perform any specified changes 
and the command must be cancelled.

Workaround: use the CHPROP command instead.


103.	[Common 12-13c2]  Inconsistent behaviour.
Any AutoLISP error issues the equivalent of a single cancel to AutoCAD.  
If some entities are pre-selected and gripped, and you enter the name of 
an unknown function, eg. (foo), then the entities become unselected but 
remain gripped.  Similarly, if AutoCAD is in a command situation which 
requires more than one cancel to terminate completely, eg. LAYER Color, 
then entering (goo) will only half-cancel out of the command.

No known workaround.


104.	[Common 13c2, CR-325]  Bug/documentation error.
The EXPLODE command does not explode groups or 3D solids, contrary to 
the Command Reference and on-line help.

Workaround: the GROUP Explode option can be used on groups, and 
SAVEASR12 performs an explosion of sorts on 3D solids.


105.	[Common 13c1, FIXED 13c2]  Bug.
The AutoLISP function (entmake), and presumably the ADS equivalent 
ads_entmake(), fail when the 48 code (linetype scale) is included in the 
entity list.

Workaround: use (entmake) without the 48 code, then use (entmod) with 
the 48 code.


106.	[DOS 13c2]  Inconsistent behaviour.
When a command is used in DOS which issues a long list to the text 
screen, a "Press RETURN to continue:" prompt is issued.  AutoCAD's 
response to actions performed by the user at this prompt differs from 
AutoCAD's normal response to user actions.  Use of pointing device 
buttons for either return or cancel is ignored.  Almost any key is 
accepted as [Return], including [Esc].  [Ctrl-C] must be entered at the 
keyboard to cancel the listing.


107.	[Common 13c2]  Bug/limitation.
The ELLIPSE entity does not respect the THICKNESS property.

Workaround: the EXTRUDE command can be used to thicken an ellipse after 
creation, but extruded ellipses do not respect the TANgent object snap 
at all.  You can create old-style polyline ellipses if you set the 
PELLIPSE system variable to 1 first, and these will respect THICKNESS 
property.


108.	[Common 13c2]  BW  Bug.
The GREEKC and GREEKS text font files do not contain any alphabetic 
characters except "R".

Workaround: the R12 .SHX files should work if you have them and don't 
mind breaking your licence agreement.  Alternatively, the files are 
available in the CompuServe ACAD library 2 as GREEK.ZIP.


109.	[Common 13a, FIXED 13c1]  Bug.
Associative hatching.  If you draw a boundary, hatch it, erase the 
hatch, rehatch using different scale, then stretch the boundary, it 
brings back the erased pattern as well.

Workaround: use HATCHEDIT instead of recreating the hatch.


110.	[Common 13c2]  Bug/design flaw.
In the MLSTYLE command, the Rename option will only allow you to rename 
unreferenced styles.

No known workaround.


111.	[Common 13c2]  Bug/design flaw.
In the MLSTYLE command, the Load option will not allow you to load a 
MLSTYLE if it already exists in the drawing.  This is inconsistent with 
other loaded definitions in AutoCAD, such as linetypes.  The message is 
just "Invalid name" with no explanation of what is going on.

No known workaround.


112.	[Common 13c2]  Bug/design flaw.
In the MLSTYLE command, the Save option simply appends the current 
MLSTYLE to the specified .MLN file with no regard to whether the style 
name already exists.  It should really check if the style exists and ask 
the user if they want to overwrite it.  This makes the file larger than 
necessary and provides potential for confusion if users try to maintain 
the file.

No known workaround other than manually editing the file to remove all 
but the last version of each style.


113.	[Common 13c2]  BW  Bug/design flaw.
In the MLSTYLE command, once you have defined a style and selected Add, 
there is no mechanism for going back and saving any additional changes 
you might need to make.  For example, if you define an MLSTYLE, select 
Add and then realise you want a different colour, you can select the new 
colour, see it update in the dialogue box, but there is no Update or 
Redefine option.  Selecting Add just gives the message "Invalid name".

Workaround: it is possible to Save the changes out to a file, and if the 
MLSTYLE is unreferenced, you can purge it then reload the saved version.


114.	[UG-47]  Documentation error.
When describing how to use the MLSTYLE dialogue box to add a new style, 
the User Guide gets it all wrong.  Basically, if you do the opposite of 
what the UG tells you, you will be on the right track.


115+	[Common 13c2]  Bug.
The AMECONVERT command for converting R12 AME models to R13 does not 
work correctly.  It fails to convert some very simple models and is 
almost useless on models of moderate complexity.  An example of a model 
which fails to convert is the R12 AME sample drawing ENGINE.DWG.

No known workaround.


116.	[CG-551, CG-559]  Documentation errors.
The MLINE and MLINESTYLE DXF specifications in the documentation are 
completely wrong.


117.	[DOS 13c2]  Bug.
R13 DOS does not understand the ".mnc" extension to the menu file name 
which R13 Windows prior to c2 saved in the DWG file.

Workaround: opening and saving the drawing in 13c2 fixes the problem.


118.	This was a duplicate of item 89 and has been removed.  Nobody 
mentioned this "deliberate mistake", so you people out there are 
obviously not paying attention.


119.	[Win 13c2]  Incompatibility.
The Windows version of R13 does not run under OS/2 (not a supported 
operating system) at the time of writing.  This is because the version 
of Win32s used with AutoCAD is more recent than that used in the latest 
version of OS/2.

No known workaround.


120.	[Common 13c1, FIXED 13c2]  Bug.
The following steps cause R13 to crash:

a)  Open the drawing or start a new drawing.
b)  XREF Attach any drawing.
c)  XREF Detach *
d)  XREF Overlay
e)  When the dialogue box pops up to pick the overlay, hit [Esc] to 
cancel the dialogue box.

A fatal error occurs with the message "!scandr.cc@2117:eWasErased".

No known workaround.


121.	[Common 13c2]  Bug.
In the BHATCH dialogue box, the ISO Pen Width popup list and the Scale 
edit box interact strangely.  For example, using the ISO15W100 pattern 
and setting the pen width to 2.0mm results in a scale of 4.71E+99.


122.	[Common 13c2, CR-240]  Documentation omission.
The DDSELECT command has a toggle for Object Grouping, but this is not 
described in the on-line help and although the dialogue box is shown 
correctly in the Command Reference, the toggle is not described in the 
supporting text.


123.	[Common 13c2]  Omission.
The DDSELECT command has a toggle for Object Grouping, but none for 
associative hatching.  That is, DDSELECT controls bit 0 of the PICKSTYLE 
system variable, but not bit 1.


124.	[Common 13c1, FIXED 13c2]  Documentation omission and bug.
The AutoLISP function (ssgetfirst) is not documented.  It returns a list 
of two selection sets which contain entities which are selected at the 
"Command:" prompt and/or gripped.  It returns garbage or bogus selection 
sets if there is no gripped and/or pickfirst set.  (sslength) will 
return nil if it is given one of these garbage picksets.


125.	[Win 13c2]  Bug.
In R13 Windows, the Snap, Grid, Ortho, etc. areas at the bottom of the 
screen no longer always work.  After a period of normal operation, 
double-clicking on these areas causes various toolbars to come up or a 
[Return] to be issued.

No known workaround.


126+	[Win 13c1, FIXED 13c2]  Design flaw.
When using AutoLISP-based commands (eg. RECTANG), the Windows object 
snap toolbars do not work.

No known workaround.


127.	[Win 13c2]  Bug.
In AutoLISP-based dialogue box functions, any error after (load_dialog) 
and before the dialogue box is dismissed will crash AutoCAD.

Workaround: use an error handler which includes a call to (term_dialog).


128.	[Common 13c2]  Bug.
If an attribute is created on a visible layer, stuck into a block, and 
then the block was inserted in an invisible layer, the attribute obeys 
the visibility of the original layer, not that of the block it is in.

No known workaround.


129.	[Common 13c2]  Arguably correct but undeniably stupid 
behaviour.
If you draw an MLINE back over itself (ie. change the direction by 180 
degrees), the MLINEs shoot off to near-infinity.  Although this can be 
considered geometrically correct, it is counter-intuitive and could have 
been avoided with a little careful programming.


130.	[CR-7]  Documentation error.
Describing wild-card characters, the Command Reference incorrectly 
states:

	` (apostrophe)  Escapes special character ...

Page 40 of User's Guide is correct:

	` (Reverse quote) Escapes special character ...

Both manuals actually show a reverse quote, but the Command Reference 
describes the symbol incorrectly.


131.	[Common 13c1, FIXED 13c2]  Bug.
The -BHATCH and -BOUNDARY commands (command line versions) do not work 
with the definition of a new boundary set.  When you try to define a new 
boundary set for these commands, they ignore the selected boundary set 
and use everything visible instead.

Workaround: use the dialogue box driven versions of these commands.


132.	[IGW-6]  Documentation error.
The Installation Guide for Windows recommends 40MB minimum disk swap 
space (ie. Windows permanent swap file).  This should be 64MB.


133.	[DG-Index and CR-Index]  Documentation error.
The index page numbers are one page out for many of the system variables 
in the Command Reference.  For example, the SAVENAME variable is listed 
as being on page 733, but is actually on page 734.


134.	[DG-Contents]  Documentation error.
The Documentation Guide contents listing is completely wrong.  It is 
actually the Installation Guide for DOS contents listing, accidentally 
transplanted.


135+	[DynaText]  Unreasonable restriction.
Certain items of documentation (eg. ADS and DXF) are not provided in 
printed form, and only CD-equipped users are provided with this 
information.  This can be accessed using the extremely slow DynaText 
system, which only works under Windows.  Although this has a Print 
option, attempting to print any section with more than a handful of 
pages is forbidden by the program.

Workaround for DXF: Autodesk has provided a Windows help file system 
which documents the DXF codes and is available from the CompuServe ACAD 
forum.


136.	[DynaText]  Bug.
On some systems, the DynaText facility displays the text using very 
large characters which causes successive lines of text to overlap.

Partial workaround: use View Reduce several times until the text becomes 
readable.  This does not help with the oversized section titles on the 
left of the screen.


137.	[Common 13c2]  Bug/omission.
The CIRCLE command's TTR option does not work with XLINE or RAY objects.  
The printed documentation does not indicate any restriction on the type 
of objects which can be used, and it is illogical to disallow the use of 
these construction entities for placement of a circle.  Attempting to do 
so invokes the message "*Requires a TAN object-snap and selection of 
Circle, Arc, or Line.", which is misleading in two ways: i) the TAN 
object snap is automatically provided by the command, so informing the 
user that one is required is unhelpful; and ii) polylines may also be 
used to define a TAN object snap.

No known workaround.


138.	[Common 13c2]  Bug/omission.
The PERpendicular object snap works FROM neither XLINE nor RAY objects.

Workaround: pick the other point first and draw perpendicular TO the 
object.


139.	[Common 13c2]  Changed behaviour.
The AutoLISP function (arx) and (ads) returns its strings in mixed case, 
rather than upper case like the (ads) function has returned in previous 
versions of AutoCAD.

Workaround: use (wcmatch) to compare strings rather than (=).


140.	[Common 13c2]  BW  Bug.
The PostScript plot driver does not plot dots.

Workaround for Windows only: use the system printer driver instead of 
the Autodesk-provided driver.


141.	[Common 13c2]  Bug.
When MLINEs are exploded, the resultant lines take on the current layer 
and linetype, rather than the linetypes assigned to the individual lines 
in the Multiline Properties section of the MLSTYLE dialogue box, and the 
layer on which the MLINEs are drawn.  No such problem applies to 
colours.

No known workaround.


142.	[Common 13c2]  Undesirable behaviour.
R13 complex linetypes display text upside down under different 
circumstances, eg. when drawing a line from right to left.

A partial workaround is to edit the entities, eg. swap the line 
endpoints.  Another possibility is to create a duplicate version of each 
linetype with a different text orientation and use that on some 
entities.  Neither workaround will solve all linetype text orientation 
problems, such as circles.


143.	[UG-17, DOS 13c2]  Documentation error and inconsistent 
behaviour.
The User's Guide states "Press [Esc] to end the command.  This key also 
cancels any command in progress."  In R13 DOS, this is not true.  There 
are many places in AutoCAD where a [Ctrl-C] must be entered at the 
keyboard to cancel a command, eg. hatch pattern fill, array fill or a 
regeneration.  In fact, pressing [Esc] under these circumstances 
prevents any subsequent [Ctrl-C] from working until the command is 
finished.  Other places where [Esc] does not perform in the same way as 
[Ctrl-C] are when a text-screen listing is displayed, and when 
configuring AutoCAD.


144.	[Common 13c2]  Bug.
The Pull-down menu item "File > Management > Unlock File..." does not 
immediately invoke the unlock file dialogue box.  Instead, it merely 
invokes the FILES command, leaving the user to pick the "Unlock file..." 
button.


145.	[Common 13a, FIXED 13c1]  Bug.
Some ADS applications invoke a sequence of events which causes AutoCAD 
to incorrectly rename the current drawing file to "_X" (no extension) 
when saving.  Any existing DWG file is lost, and after a second save, 
any existing BAK file is lost, too.  The trigger is the application 
using the ads_ssget() function when called with an RQSAVE.


146.	[Win 13c2]  Incompatibility.
The feature of dynamically swapping ***POPx menu sub-sections and 
invoking them with $Px=* does not work in R13 Windows.  It works in R13 
DOS, worked in previous releases of AutoCAD, and its demise was not 
announced.  For example, (menucmd "P2=*") pulls down menu section 2 
under R13 DOS and earlier releases of AutoCAD, but does nothing in R13 
Windows.  This problem does not occur with POP0.


147.	[CR-330, Common 13c2]  Documentation error/bug.
The Command Reference states "You can extrude ... splines..." and shows 
a picture of a spline-like object being extruded using a taper angle.  
The EXTRUDE command fails to extrude splines if a taper angle is 
applied.


148.	[Win 13c1, FIXED 13c2]  Bug.
In Windows, global attribute editing is broken.  If you use the ATTEDIT 
command and answer N to the next two prompts, the command will not find 
any attributes to modify even if there are some in your drawing which 
match what you enter at the next three "specification" prompts.

Workaround: answer Y to the "Edit only attributes visible on screen? 
<Y>" prompt and select the whole drawing with a window or crossing.


149.	[Win 13c2]  Bug.
The Windows menu sub-section swapping mechanism does not work between 
sections.  For example, you cannot swap a ** section located under 
***POP2 into the ***POP5 section.

Workaround: make sure the ** section you want to use is located in the 
section you want to use it in.


150.	[Win 13c2]  Bug.
In Windows, menu sub-section swapping does not work in the ***BUTTONS 
and ***AUX sections.

No known workaround.


151.	This was a duplicate of item 146 and has been removed.  Nobody 
mentioned this one, either.


152.	[Common 13c2]  Bug.
When using the WBLOCK command to create external blocks without 
previously defining the block internally (ie. by pressing [Enter] at the 
"Block name:" prompt), the entities are written to the new drawing file 
in the order they were created, rather than the order they were 
selected.  This differs from earlier releases and can cause significant 
problems with attributes coming out in the wrong order.

Workaround: use the BLOCK command first, as this command respects the 
selection order, then use WBLOCK to write the block definition out to 
disk.


153.	[Common 13c2]  Bugs.
The AutoLISP dialogue box function (set_tile) must not be used between 
(start_list) and (end_list), as it causes all kinds of problems.  
Similarly, a (set_tile) between a (start_image) and (end_image) will 
corrupt the image being drawn.

Workaround: don't do that.


154.	[Common 13c2]  Design flaw.
If you use the MLEDIT cut options on a multiline, the STRETCH command 
does not work on the resultant gap in the entity.  Thus, if you use a 
multiline to draw a wall, cut it with MLEDIT and insert a door block, 
you will not be able to stretch the door and gap around at the same 
time.

Workaround: use the MLEDIT weld option to remove the gap, then recreate 
the gap in a different place.


155.	[Win 13c1]  Bug.
If you use the Windows aerial view to perform a zoom while a 
regeneration is in progress, this can cause R13 to crash.

Workaround: don't do that.


156.	[Win 13c2]  Bug.
If you repeatedly load a menu under Windows, the Windows Resources 
memory gets used up and AutoCAD reacts rather ungracefully by making 
parts of the menu disappear.

Partial workaround: you can prevent AutoCAD from automatically loading 
the menu associated with each drawing.  Use the PREFERENCES command, 
pick the Misc section tab and make sure "Use menu in header" is turned 
off.


157.	[UG-323]  Documentation error and limitation.
The User Guide shows an example of a radius dimension where the 
dimension line is drawn from the arrowhead and through the centre of the 
arc to the dimension text.  It is not possible to create such dimensions 
with R13.


158.	[Common 13c2]  Bug.
The AutoLISP function (getfiled) does not display the correct drawing 
preview when called with a default drawing.  For example, (getfiled "" 
"/acadr13/common/sample/chroma" "dwg" 0) will select the correct drawing 
(CHROMA), but in DOS the drawing preview will be of the last drawing in 
the directory list (TRUETYPE on my system) and in Windows no drawing 
preview is displayed at all.

No known workaround for programmers: users have to pick a drawing for 
the image to be displayed.


159.	[Common 13c2]  Incompatibility and bugs.
In previous releases of AutoCAD, text which was created with the Align 
or Fit justifications included trailing spaces when determining how to 
size the characters.  In R13, trailing spaces are treated as if they are 
not there.  If a drawing from R12 contains such text, it initially 
retains its original appearance in R13. If DDMODIFY is used on such 
text, the non-trailing space characters expand to fill the gap, even if 
you make no changes.  You can move such text around without changing its 
appearance, but if you undo the move, the text will expand.

No known workaround.


160.	[Common 13c2]  Abnormal performance degradation.
Many disk-based operations in R13 (notably SAVE) are very slow.  Such 
operations often take around 10 times longer than in previous releases 
of AutoCAD.


161.	[Common 13c1, FIXED 13c2]  Bug.
Hidden line removal plots often corrupt R13 solid model drawings.  If 
you create a 3D model, create a paper space viewport with the hideplot 
facility turned on, then plot, the drawing may become corrupt and may 
cause ACIS errors when used later.

Workaround: save your drawing before any operation involving hidden 
lines, and open it (discard the current drawing) immediately after the 
suspect operation.  See item 162 for a related problem.


162.	[Common 13c1, FIXED 13c2]  Bug.
Certain combinations of copying R13 solid model objects and hidden line 
removal plotting will cause save times to become extremely long.  This 
is not related to item 160: this problem is much worse than that and 
triggered by specific circumstances.  The following script will 
reproduce the problem:

CIRCLE 2,2 1
EXTRUDE Last  1 0
VPOINT 1,-1,1
ZOOM .3x
COPY Last  0,0 0,1
UNION Previous Last

COPY Last  0,0 2,0
TILEMODE 0
MVIEW Fit
MVIEW Hideplot ON Last

QSAVE                   (this save should be very quick)
PLOT                    (you take over from here)

Once the plot has been performed, a further save will be very slow.  The 
file size will also grow from 12KB to 197KB.

See item 161 for a related problem and workaround.


163.	[Common 12-13c2]  BW  Bug.
The RECTANG command (actually an AutoLISP routine associated with the 
menu) does not deal with running object snaps correctly.  To see this, 
set an ENDpoint running object snap, and draw a rectangle, locating one 
corner on the MIDpoint of a line.  The result is non-rectangular.

Workaround: turn your running object snap off and use object snap 
overides instead.


164.	[Win 13c1, FIXED 13c2]  Bug.
Create or modify a .MNU file containing an item such as this:

	[Thing]*^C^CINSERT THING

This works in DOS, but in Windows, everything after the [Thing] label 
gets lost in the translation from a .MNU to a .MNS file.

Workaround: add the missing information to the .MNS file.


165+	[Common 13c2]  Incompatibility and incompletely implemented 
command.
In R12, drawing views could be deleted only with the VIEW Delete 
command.  In R13, although PURGE does not provide a specific option to 
purge views, if the All option is used then all views in the drawing 
will be offered for purging.  This means that AutoLISP routines which 
purged all other unreferenced items but not views in R12 will now also 
purge views.  The same applies to user coordinate systems: there is no 
UCS option in PURGE, but PURGE All will offer them for purging.

Workaround: rewrite the routine to purge each of the specific item types 
in turn, rather than using the All option.


166.	[UG-248]  Documentation error.
The User's Guide contains an illustration which implies that spell 
checking can be performed within the Windows Mtext editor.  This is not 
correct: the SPELL command must be used instead.


167+	[Common 12-13c2]  Bug.
At the Dim: prompt, the AutoLISP-based command RECTANG can be entered as 
a normal command.  Although this command seems to work at first, no 
rectangle will be drawn.  The standard Autodesk utilities (ai_trans) and 
(ai_transd) could have been used by the Autodesk programmers to solve 
this problem.


168.	[Win 13c2 only, FIXED 13c2a]  Bug.
In Windows, attempting to calibrate or configure a tablet which uses 
WinTab causes the cursor to lock up and prevents the points being 
picked.  This is the only bug fixed by 13c2a.


169.	[Win 13c2]  Incompatibility.
Microsoft Windows for Workgroups Mail and R13 do not mix.  If Mail is 
running with your computer acting as a post office when you use R13, 
AutoCAD will crash.  In some cases, you can be dumped to DOS without 
warning.  Only workaround is not to use Mail.


170.	[Common 13c2]  Bug.
If you insert a block with an attribute that was created in AutoCAD R12 
or earlier (or created using R13's SAVEASR12 command) into a R13 drawing 
and then try to (entmod) or ads_entmod() that attribute, R13 will crash.

No known workaround.


171.	[Common 13c2]  Bug.
Take a drawing which contains a block created in R10 or earlier, and 
redefine the block in R13 using INSERT NAME=.  The insertion point of 
the redefined blocks is shifted by the distance between the defined 
insertion point and the 0,0,0 point of the old drawing in which the 
block was defined.

Workaround: if you go into each block drawing in turn and change the 
base to 0,0,0 (don't move the entities).  Redefined insertions in the 
main drawing will now work correctly.  However, this workaround is 
useless if you wish to use these blocks in other drawings, because the 
origin point will be in the wrong place for those drawings.  A more 
sensible workaround may be possible with an AutoLISP routine.


172.	[Common 13c2]  BW  Bug.
In a paper/model space drawing, if you are in model space and you insert 
another drawing using the INSERT *NAME method, the entities are inserted 
into paper space instead of model space.

Workaround: insert the drawing without the *, then explode and purge it.


173.	[Win 13c2]  Untidy behaviour.
In Windows, during a DTEXT command, if you pan or zoom using the aerial 
view or scroll bars, any text entered so far during the command will 
vanish and a copy of the DTEXT cursor will be left behind on the screen.  
The text comes back when you hit the final enter to finish the command 
and the cursor will vanish at the next redraw.


174.	[Win 13c2]  Undesirable behaviour.
The Windows Mtext editor will perform word wrapping, but that shown in 
the editor will not always match the word wrapping which occurs in the 
drawing.  The Windows text font used in the editor is only an 
approximation of the text font used in the drawing.  Therefore, the word 
wrapping can only be used as a rough guide to the final appearance of 
the text.

No known workaround.


175.	[Win 13c1, FIXED 13c2]  Strange behaviour.
On some Windows systems, the menu file loads slowly, but moving the 
pointing device around makes it go quicker.  With a little rodent 
wiggling practice, it is possible to speed up and slow down the 
percentage loaded bar at will.


176.	[Common 13c2]  Incomplete protection against silly programmers.
If an AutoLISP or ADS programmer modifies a pface mesh polyline header 
entity and changes the 70 code from its normal 64 or 192 to 128, AutoCAD 
should reject this operation as it makes no sense at all.  However, R12 
transformed the polyline into a 2D polyline and R13 transforms it into a 
2D polyline with no vertices.  Attempting to AUDIT the drawing in R13 
causes AutoCAD to crash.

Workaround: don't do that, it's not a very sensible thing to do.


177.	[Common 13c2]  BW  Bug.
AutoCAD gets its extents calculations wrong when scaled-down blocks 
contain the new R13 leader entities.  For the purpose of calculating the 
extents, AutoCAD is treating each leader arrowhead nested inside a 
scaled-down block as if the block were at full size.  The following 
script will reproduce it starting from a no-prototype blank drawing:

LEADER 0,0 1,1


None
ZOOM Extents
SAVE LEADBUG
NEW LEADBUG2=
INSERT LEADBUG 0,0 0.01  0
ZOOM Extents

No known workaround other than exploding the block.


178.	[Common 13c1, FIXED 13c2]  Untidy conversion.
When an R13 drawing containing dimensions and MTEXT entities is saved 
using the SAVEASR12 command, any Unicode sequences for degrees, diameter 
and plus/minus symbols are left as Unicode sequences rather than 
converted to their R12 equivalents.

No known workaround.


179.	[Common 13c2]  Bug.
If an associative hatch boundary is edited using the FILLET or CHAMFER 
commands, the hatch does not update.  In the case of a boundary made of 
individual objects (eg. LINEs), any attempt to edit the boundary later 
will remove associativity from the hatch.

Workaround: for a boundary where the filleted object is a polyline, the 
hatch will be updated correctly by the next edit done on the boundary.  
The hatch can be updated without actually changing the boundary if a 
null edit is performed (eg. move or grip edit an entity using zero 
displacement).


180.	[Common 13c2]  Bug.
Make a polyline, PEDIT Spline it and create a block definition 
containing this polyline.  Insert the block using unequal scale factors.  
Explode the block.  The result is not a polyline, but individual line 
segments.  Also, the line segments contain not only the splined section 
of the polyline, but also a variation on the spline frame which has the 
first vertex moved to the last vertex point.  

Partial workaround: the first vertex can be grip edited into place if 
required.


181.	[Common 13c2]  Bug.
Use the MINSERT command using any block, and create a second block that 
contains the minserted block.  Insert the second block using unequal 
scale factors and explode it.  The minserted block changes shape: it 
seems to change such that the X scale factor is 1.

Only workaround is to erase and re-insert the minserted block.


182.	[Common 13c2]  Incomplete command implementation and bug.
Draw some objects using the LEADER and MTEXT commands and create a block 
definition containing these objects.  Insert the block using unequal 
scale factors.  Explode the block.  The leaders and mtext objects are 
not exploded, but instead are placed into an anonymous *E block.  
Attempting to explode this block does not work manually, and attempting 
to do so using AutoLISP crashes AutoCAD with a Null Pointer or Unhandled 
Exception error.

No known workaround.


183.	[Win 13c1 unlocked, FIXED 13c2]  Incompatibility.
Using 13c1 Win under both Windows and NT (not a supported operating 
system for c1) causes problems when switching from one environment to 
another.  The ACAD.CFG file gets messed up and you need to reconfigure 
AutoCAD and re-enter the authorisation code.  Workaround: you can 
maintain two different ACAD.CFG files in different directories, one for 
each operating environment.  To point AutoCAD at the appropriate 
directory, in the Program Manager's Program Item Properties dialogue 
box, add a /c item to the Command Line item, eg. C:\R13\WIN\acad.exe /c 
C:\R13\NT


184.	[Common 13c2]  Bug.
The UCS Object (formerly Entity) option does not allow an ellipse object 
to be used to specify a user coordinate system.  If one is selected, the 
strangely worded and incorrect message "OBJECT object does not define a 
coordinate system" is displayed.

No known workaround.


185.	[Win 13c2]  Bug.
In R13 Windows, there seems to be a limit of 999 pull-down menu items.  
If this limit is exceeded, no warnings are given but all sorts of 
strange things happen.  One symptom is the greying out of all pull-down 
menu items when the menu is loaded a second time.  Another symptom is a 
second regeneration occurring every time a drawing is loaded, this 
regeneration cancelling any user prompts in an (S::STARTUP) AutoLISP 
routine.  Also, DIESEL expressions in the menu labels are displayed 
rather than evaluated, resulting in very wide menu items which do not 
work properly.

Only workaround is to reduce the number of menu items.


186.	[Win 13c1, FIXED 13c2]  Missing facility.
Windows programmers have found that R13 does not honour the DDE message 
WM_ACAD as R12 did and as the DDE.TXT file suggests it does.  Actually, 
WM_ACAD has been permanently removed.

Workaround for R13 before c2: find the AutoCAD window by using 
GetWindowText() and looking for "AutoCAD -", then find the child drawing 
graphics window by using GetWindowText() and looking for "UNNAMED" or 
".DWG".  This window accepts WM_CHAR messages.  

Workaround for 13c2 and later: use WM_COPYDATA as described in the c2 
README.WRI, under AutoCAD Developer's Guide, PART I - ADS.


187.	[Common 13c2]  Bug.
Under some circumstances, associativity is removed from hatching when it 
should be possible for it to be retained.  Draw a circle and a larger 
rectangle such that the circle intersects the rectangle.  Draw some 
associative hatching using a point where the two objects intersect.  
Scale the circle and the hatching objects together such that the shape 
of the intersecting area does not change.  The associativity will be 
lost.

Workaround: if you do not select the hatching itself during the editing 
operation, associativity will be retained.


188.	[DynaText]  Limitation and documentation error.
The DynaText on-line documentation facility does not allow searching 
across multiple documents, even though the help file suggests it can.


189.	[Common 13c1, FIXED 13c2]  Bug.
If you dimension in paper space using a negative DIMLFAC setting, the 
dimension text and arrows are always thrown outside the extension lines, 
even when there is plenty of room inside.

No known workaround.


190.	[Common 13c2]  Bug.
If you use the command-line interface to plot, if you plot to a file you 
are prompted for the file name.  If the file already exists, you are 
prompted "The specified file already exists. Do you want to replace it? 
<N>".  If you enter Y or YES, a file called Y.PLT or YES.PLT is created, 
rather than the filename you specified.

Only workaround is to delete any plot file with the same name as that 
you wish to create, before using the PLOT command.


191.	[NT 13c2]  Bug/incompatibility.
Using R13 NT, the Autodesk-provided plotter drivers do not work.

One workaround is to use the system printer instead.  Another workaround 
is to make sure that if you wish to use a given LPT port, make sure that 
LPT port is NOT used by the system printer.  If that is not adequate for 
your needs, another workaround is available:

a)  From an MS-DOS box, issue the following command:

	net use lptX \\ComputerName\ShareName /persistent:yes

where lptX is the logical port you wish to use, ComputerName is the 
network name of the computer with the printer and ShareName is the 
resource name.

b)  Create a batch file containing:

	copy %1 lptX /b
	del %1

where lptX is the logical port you wish to use.

c)  Set your environment variable ACADPLCMD to "PLOT.BAT %s".

d)  In the PLOT command, plot to file and set the plot file name to 
AUTOSPOOL.

This will create a plot file, copy it to the appropriate port and then 
delete the file.


192.	[Common 13c2]  BW  Bug.
If an AutoLISP routine is run containing a call to (ssget "F"), and then 
a transparent command is executed (eg. 'ZOOM), AutoCAD will crash.

No known workaround, unless the AutoLISP routine can be rewritten to use 
(ssget "C") instead.


193+	[CG]  Documentation errors.
According to AutoCAD documentation since R11, the block table's 70 field 
has a 64 bit which indicates whether the block is referenced or not.  
For normal blocks, this is dysfunctional.  The 64 bit is actually only 
used for Xrefs.  Also, the R13 documentation states that the 8 bit is 
not used, which is not true.  It is actually used to indicate if the 
Xref is an overlay.

One way of determining if a block is referenced is to (ssget "X" '(2 . 
"BLOCKNAME")) the drawing for references to the block.  As this does not 
cater for nested blocks, the block definitions would need to be scanned 
too, which would make the routine very slow.


194.	[IGD-6]  Documentation error.
The Installation Guide for DOS recommends 8MB minimum RAM.  R13 will not 
run successfully and reliably with this little RAM.  12MB is the 
official minimum, although even that is on the low side.


195.	[Win 13c2]  Bug.
The OPEN command in Windows automatically turns on the "Read only" 
toggle when a file is selected in a directory containing a dot, eg. 
C:\MY.DIR\MYFILE.DWG.  The same applies to any command which opens a 
file to read using a dialogue box, such as DXFIN and DDINSERT.  The 
problem does not occur if no dialogue box is used, eg. with OPEN when 
FILEDIA = 0.

Workaround: set DWGWRITE to 1 before saving.  See item 24 for 
alternative workarounds.


196.	[Win 13c2]  Incompatibility.
R10 DXF files ($ACADVER = AC1006) may contain a DWGMGR table section, 
and if such a file is read into R13, DXFIN reports an "Error in APPID 
Table".

Workaround: using a text editor, remove the 8 lines which look like 
this:

 0
TABLE
 2
DWGMGR
 70
    0
 0
ENDTAB


197.	[CG-250]  Documentation omission.
The (ssget) documentation in the Customization Manual contains nothing 
on the use of "G" as an argument to the (ssget) function.  Calling 
(ssget "G") results in a "Enter group name: " prompt on the command 
line.


198.	[Common 13c2]  BW  Bug.
Dimension leaders created with the LEADER command do not use the current 
dimension text style setting DIMTXSTY.  Instead, the current text style 
setting TEXTSTYLE is used.

Workaround: use the old R12 Leader command at the "Dim:" prompt rather 
than at the "Command:" prompt.  See item 97 for a similar but now 
defunct bug.


199.	[Win 13c2]  Bug/untidy behaviour.
In Windows, start a regeneration of a large drawing and cancel it before 
it finishes.  Aerial zooms will now not work until you do another 
regeneration.  Do a ZOOM Window.  While the prompt "About to regen - 
proceed" is displayed, the crosshairs will only move within an invisible 
rectangle defined by the corners of the window points you picked.


200.	[Common 11-13c2]  Bug.
The (entnext) and ads_entnext() functions can return the entity name of 
an attribute of a block deleted with (entdel) or ads_entdel().  If you 
(entdel) a block insert with attributes and then use (entnext) to get 
the next entity after the one that preceded the block, you are given the 
attribute of the deleted block, not the next undeleted entity.  To 
reproduce this:

a) Define two blocks, one without attributes and one with a single 
attribute, then insert the block without attributes and the block with 
attributes.

b) Get the entity names:

(setq
  block1 (car (entsel))   ; pick the block without attributes
  block2 (entnext block1)
  attrib (entnext block2)
)

c) Delete the block with attributes:

(entdel block2)

d) Now, (entnext block1) returns attrib, instead of nil

The same applies whether the block has been erased using (entdel) or 
ERASE.

No known workaround.


201.	[Common 13c2]  BW  Bug.
The LEADER command draws arrowheads using the style of the parent style 
rather than the leader style.  This bug was introduced by 13c2.

Workarounds: use DIM Leader instead or create a special parent style 
just for use with leaders.  Alternatively, use the DIMSTYLE Restore 
command to set the current dimension style to the $7 leader child style 
before drawing new leaders.  If you use the latter workaround, you can 
then use DIM Restore to update the existing leaders.


202.	[Common 13c2]  Changed behaviour causing loss of functionality.
If file locking is enabled and the WBLOCK command is used with the * 
option to write a purged version of a drawing out over itself, this does 
not work and an "Unable to unlock file" message is issued.

Workarounds involve using different filenames for the drawing.


203.	[Common 13c2]  Bug.
Sometimes, after using ATTEDIT command once on an attribute, attempting 
to use ATTEDIT a second time on that attribute does not work.  In fact, 
it becomes impossible to select the attribute at all.

Workaround: a plain REGEN does not fix this, but a ZOOM Extents or 
toggling TILEMODE does.


204+	[Win/NT 13c2]  Bug.
On some systems, the Preferences > System > Color... > Monochrome 
Vectors toggle keeps being turned on.  This seems to be related to the 
resolution and number of colours the Windows screen driver is configured 
to use.  If you select a Windows setting which uses many colours, you 
may find AutoCAD's colours are all white.  Some people report the toggle 
being turned off when changing screen resolutions, whereas others report 
it being off every time they start up AutoCAD.  This seems to have been 
introduced by 13c2.

The workaround of manually changing the toggle has been reported as only 
allowing AutoCAD to use 16 colours.


205.	[CR-705]  Documentation error.
The Command Reference states that if the DELOBJ system variable is set 
to 0, objects used to construct other objects are deleted, and they are 
retained if DELOBJ = 1.  This is the wrong way round.


206.	[13 onwards]  Changed behaviour.
In R12 Windows, the Copy/Paste mechanism used the insertion base point 
of the drawing as the insertion base point of the block containing the 
copied entities.  In R13, this is no longer the case.  A point at the 
lower left corner of the extents of the selected entities is used 
instead.


207.	[Common 13c2]  BW  Bug.
If you EXPLODE an MTEXT object (possible from 13c2 onwards), the 
resultant TEXT objects take on the current text style, rather than the 
style of the original object.

No known workaround.


208.	[Common 13c2, to be fixed in 13c3]  BW  Bug.
The TXT font file is supposed to be proportionally spaced, but is not in 
13c2.  Instead, it is identical to the equally spaced MONOTXT font file.

Workaround: the R12 .SHX file should work if you have it and don't mind 
breaking your licence agreement.  See item 34 for a similar problem in 
reverse.


209.	[Common 12-13c2]  Irrational behaviour impairing performance.
If you preselect some objects with highlight on, then issue a command 
such as MOVE, the objects will unhighlight and then highlight for no 
good reason.  With a large selection set, this can take a long time, 
particularly on Windows.

Only workaround is to turn highlighting off.


210.	[Win 13c2]  Bug.
Using the function ads_arxloaded() from a non-ARX ADS program produces 
strange results.  After the call, the program stops and returns control 
to the command prompt.  The next time the ADS program is used, execution 
continues from the point it left off.

No known workaround other than compiling the ADS application as an ARX 
application instead.


211.	[UG-547]  Documentation error.
The User's Guide states "You can open AutoCAD drawings in AutoCAD LT and 
vice versa.  You do not need to perform a conversion to preserve the 
data."  This is wrong.  You can read R13 DWG files in neither AutoCAD LT 
R1 nor R2.  You need to use the SAVEASR12 command in R13 to create DWG 
files which LT can understand.


New Bugs Start Here

212+	[Common 13c2]  Drawing error.
In the sample drawing COLORWH.DWG, the solid which is supposed to be 
colour 130 is actually colour 120.

Workaround: if you need this drawing to be correct for test plots or 
similar, you can manually change the colour of the entity to 130.  This 
is easier if you turn off layer LINES first.


213+	[Common 13c2]  Bug.
The PURGE command allows text styles to be purged, even if they are used 
by Mtext objects.  If this is done, the Mtext objects using the purged 
styles will vanish after the next regeneration.  They remain in the 
drawing database, but have no style associated with them.  Recreating 
the purged styles does not fix up the problem.

No known workaround, but if an Mtext object uses a font for only part of 
the object, R13 manages to work out how to display the part-object 
because it uses the font file directly, rather than through a style.


214+	[Win 12-13c2]  Inconsistent behaviour.
If the R13 Windows COPYCLIP or CUTCLIP commands are used, selected 
objects which are off-screen at the time the command finishes do not 
seem to be stored in the clipboard.  An image of the selected objects 
clipped to the current zoom level is visible in the clipboard viewer 
instead, and this is what gets pasted into other applications such as 
Word for Windows.  However, pasting the same clipboard contents into 
AutoCAD reveals that all of the selected objects were stored.

Workaround: transparently zoom out before pressing the final enter at 
the "Select objects:" prompt.


215+	[Common 12-13c2, to be fixed in 13c3]  Bugs.
Create a block in paper space, and include a viewport object.  If you 
insert and explode this block in paper space, then erase it and undo, 
R13 crashes with an unhandled exception error.  If you insert and 
explode this block in paper space at a scale other than 1, using MVIEW 
ON will either fail to work or will crash R13 with an unhandled 
exception error.  If you insert and explode this block in model space, 
you get a paper space viewport in model space, which a very strange 
thing to have.  AutoCAD should not let you do this.  If you grip edit 
the object, it will vanish but still be there with only its grips 
visible.  If you erase the object and then undo, R13 crashes with an 
internal error message "!dbvport.cc@286: eNullObjectId".  R12 acted in 
the way described above with the exception of the crashes.

No known workaround.


216+	[Common 13c2, to be fixed in 13c3]  Bug.
If you grip edit an angular dimension while in a UCS not parallel to 
that of the dimension, very strange things happen.  To see this, run 
this script from a blank drawing:

UCS X 45
DIMANGULAR  1,1 3,3 1,3 2.5,5
UCS W

Next, select the dimension and pick the grip with the text on it.  As 
you drag the grip around, you will see the dragged image of the 
dimension do strange things.  When you pick a point, the edited 
dimension will look nothing like the dragged image.

No known workaround.


217+	[Common 13c2]  Bug.
The TOLERANCE object respects the DIMCLRD and DIMCLRT colour settings 
when new tolerance objects are created.  However, if you save and open a 
drawing containing such tolerances, these settings are no longer 
respected and the objects revert to using the general entity properties 
on which they were created.

Workaround: you can use DIM Update to force selected objects to use the 
current settings, but this only works for the current drawing session.


218+	[Common 13c2]  Bug.
Unreferenced registered application IDs (appids) can be removed using 
the PURGE command.  Unlike other table entries, appids cannot be purged 
at any time.  The following script illustrates this:

(regapp "PURGE_ME_IF_YOU_CAN")
PURGE AP

The newly created appid will not be available for purging, despite it 
being unreferenced.  The appid is actually there, and this can be 
checked with (tblnext).

Workaround: if the drawing is saved and reopened, then the unreferenced 
appid can be purged.


219+	[DOS 13c2]  Bug.
Create a drawing called FRED and save it.  Immediately use the NEW 
command, and pick the "New Drawing Name..." button.  Select the FRED 
drawing.  You can then OK out of the command and start a new drawing 
without the normal warning being issued about overwriting an existing 
drawing.  If you then save the new drawing twice, the old FRED.DWG and 
FRED.BAK files will be overwritten with almost no hope of getting them 
back.  This warning is only missed out if the current drawing name is 
the same as that selected in the file dialogue box.

Workaround: this bug emphasises the importance of making proper off-
machine backups.  To prevent the NEW command from missing out this 
warning, type the new drawing name into the edit box rather than picking 
the button.


220+	[Common 13c2]  BW  Bug.
Create a drawing CHILD which has a complex linetype defined using a 
reference to a shape file, eg. LINETYPE Load * LTYPESHP.  You don't have 
to actually use the linetype, just having it loaded is enough.  Start a 
new drawing PARENT and make sure VISRETAIN is set to 1.  XREF Attach 
CHILD and save PARENT.  Next time you open PARENT, AutoCAD will crash 
with an error "!smio.cc @1528: eNullObjectId".  There is no problem with 
complex linetypes using text, and no problem with shapes which are 
loaded and inserted in the traditional manner.

Workaround: purge all shape-based linetypes from any drawings likely to 
be used as Xrefs.  Alternatively, make sure you have VISRETAIN set to 0 
at all times when using Xrefs containing such linetypes.


221+	[CR-718]  Documentation omission.
The DIMZIN system variable controls the supression of zeroes in 
dimensions and in the AutoLISP conversion performed by the functions 
(rtos) and (angtos).  The effects on imperial dimensions of setting 
DIMZIN to values from 0 to 3 are documented in the Command Reference, 
but the effects of adding 4 and/or 8 to the value are not.  In decimal 
values, adding 4 supresses leading zeroes and adding 8 supresses 
trailing zeroes.  Adding 12 supresses both leading and trailing zeroes.


222+	[Common 13c2, to be fixed in 13c4]  BW  Bug.
Stacked fractions have a rather poor appearance with many text fonts, 
such as the commonly used ROMANS.  The line between the numbers is too 
far to the left and the fraction as a whole seems to be right justified 
rather than centred.

Workaround: one font which seems to work well in stacked fractions is 
TXT.  Unfortunately, that font is pretty ugly, which defeats the object 
of using it.


223+	[Common 13c2, to be fixed in 13c3]  Bug.
Define a text style which uses a .PFB font file and draw some text at a 
non-orthogonal angle (say 45 degrees) using that style.  Draw a box 
around the text so you know the area it should fit into.  Perform a 
PSOUT, then PSIN the same file.  The imported image of the text will no 
longer fit into the box: it will be smaller and at the wrong angle.  In 
my test drawing, the image is about 10% too small and the angle is about 
10 degrees out.

No known workaround, other than using another font.  TTF fonts work 
correctly.


224+	[Win 11-13c2]  BW  Minor bug.
If AutoCAD is configured to use monochrome vectors, the Autodesk logo 
displays as a solid white or grey square.

No known workaround.


225+	[Common 13c2]  Inconsistent behaviour.
If R13 is configured to use monochrome vectors, the display is black and 
white, and the MSLIDE command creates a black and white slide file.  
However, the COPYCLIP, WMFOUT, BMPOUT and PSOUT commands all export 
images or files with colours.  This is inconsistent with earlier 
versions of AutoCAD for Windows.

No known workaround.


226+	[Common 13c2, to be fixed in 13c3]  Bug.
Use the DDIM command, pick Annotation, then Units.  Set the units to 
either Architectural or Fractional (not stacked).  The Precision popup 
lists show the precision using either Scientific or Decimal units 
respectively.

Workaround: only the display is wrong, and the popup list can still be 
used to select the precision if you know the position in the list of the 
desired precision.  Alternatively, you can use the stacked version of 
the units type you want, select the precision you want, then switch the 
units to the non-stacked version.


227+	[Common 13c2]  Bug.
The dimension line increment variable DIMDLI is not respected when 
drawing continuous dimensions.  The documentation (UG-304) indicates 
that DIMDLI should affect continuous dimensions, and it did so in 
previous versions of AutoCAD.  Drawing continuous dimensions with more 
than one successive very small dimension now creates a rather messy 
result.

Workaround: none known other than editing the dimensions after creation 
or drawing the dimensions individually.


228+	[Win 13c2]  Removed feature.
In versions of R13 prior to 13c2, the Windows object snap toolbar 
buttons would change the running object snap setting if picked when no 
command was running.  This feature was removed in 13c2 in order to fix 
item 126, and now AutoCAD issues an "Unknown command" message instead.  
The buttons now only work as object snap overrides.

No known workaround.


229+	[Win 13c2]  Microsoft bug.
If you use the Microsoft mouse driver version 9.00 or 9.01, use of 
Win32s applications (including AutoCAD) can invoke GROWSTUB errors.  
This is not an AutoCAD bug, but it looks like one because it happens 
when AutoCAD is run.  Although some people find the system works fine 
after the dialogue box reporting the error is dismissed, others have 
found it makes Windows unstable.

Workaround: you can disable the use of the 9.0x driver by editing the 
WIN.INI file.  Change this line in the [windows] section:

	load=c:\mouse\pointer.exe

to this:

	load=

Alternatively, if you have version 9.01 of the driver, you can patch it 
to version 9.01b.  The file HD1061.EXE is available from the libraries 
of the Microsoft or ACAD CompuServe forums, and is a self-extracting 
archive which contains a replacement POINTER.DLL file and instructions.


230+	[Common 13c2]  Bug.
The DDATTDEF command does not create an attribute definition if AUNITS 
is set to anything other than 0, ie. if angular units are not set up for 
decimal degrees.

Workaround: edit the DDATTDEF.LSP file (eg. in the R13\COM\SUPPORT 
directory) and change line 575 from this:

           (command (distof rot))

to this:

           (command (angtof rot))


231+	[Common 13c2]  Bug.
The MONOTXT font in R13 is poorly spaced.  For example, the word "this" 
appears as "thi s" because the extra space around the "i" is all placed 
to the right of the character, rather than being equally spaced on both 
sides.

Workaround: the R12 MONOTXT.SHX file works if you have it and don't mind 
breaking your licence agreement.


232+	[NT 13c2]  Abnormal performance degradation.
Compiling a menu file under NT can take several minutes rather than 
several seconds under Windows.

Workaround: moving your pointing device during compilation has been 
reported to speed things up.  Mouse manipulation may make menu 
maintenance more manageable.


233+	[Common 13c2, CR-723]  Bug/documentation errors.
The HPBOUND system variable works in the opposite way to that documented 
in the Command Reference and on-line help.  If you set HPBOUND to 0, 
BHATCH and BOUNDARY create regions.  If you set it to 1, these commands 
create polylines.  The Command Reference also indicates that HPBOUND is 
a real saved in the drawing, but it is really an integer which is always 
set to 1 at the start of each drawing session.

Workaround: do the opposite of what the documentation tells you.


234+	[Win 13c2]  Bug.
If you issue the NEW command and specify a filename, that filename gets 
added to the File pull-down menu immediately rather than when the file 
is saved.  Therefore, if you don't save the drawing, the menu item does 
not work correctly.  AutoCAD attempts to open the non-existent drawing, 
fails, and invokes the OPEN dialogue box.

No known workaround.


235+	[Win Render 13c2]  Incomplete interface.
The Render application (the window invoked if you select a destination 
of Render Window) contains a toolbar, but the buttons do not have tool 
tips and the window provides no help facility to explain their 
functions.

Workaround: press the buttons and work out what they do.  They are Open, 
Save (as BMP: R12 also allowed WMF format), Print (invokes a dialogue 
box), Copy (image to Clipboard) and one on the end which looks like a 
tube yoke or a fork in the road invokes the Windows Render Options 
dialogue (same as File > Options...).


236+	[Win 13c2]  Restriction.
The RENDER dialogue box indicates the number of bits being used for the 
rendering, but does not provide any mechanism for changing the setting 
from 8 bits when rendering to a window or viewport.

Workaround: to perform a 24-bit render to a window, first perform an 8-
bit render to window, then press the button that looks like a tube yoke 
to invoke the Render Options.  From there, set 24-bit colour and pick 
OK.  Switch to the AutoCAD window and repeat the RENDER command.  There 
does not seem to be a mechanism to allow 24-bit rendering to a viewport.


237+	[Common 13c2]  Untidy programming.
The RENDER command returns nil to the command line if the Cancel button 
is picked in the dialogue box.


238+	[Common 13c2]  Incompatibility.
The AutoLISP (entmod) function does not always work in R13 in situations 
where it did work in R12.  For example, if an AutoLISP function invokes 
the LINE command, picks two points and then attempts to (entmod) the 
line which was just created, nothing will happen.  If another point is 
picked or the command is finished off, then the line will be modified 
correctly.

Workaround: rather than modifying entities as they are created, routines 
could store the entity names in a list and modify them once the command 
is complete.


239+	[CR-739, Common 13c2, to be fixed in 13c4]  Documentation 
error/bug.
The TEXTFILL system variable is documented in the Command Reference as 
being saved in the drawing.  Actually, it is not saved anywhere.  When 
AutoCAD is started up, it is set to 0.  Its value can be changed 
manually and is retained when opening new drawings, but is lost when 
exiting AutoCAD.


240+	[Common 12-13c2]  Bug/undefined behaviour.
The AutoLISP function (rtos) accepts up to 3 arguments: a number to be 
converted to a string, a units mode and a units precision.  These last 
two arguments correspond to the system variables LUNITS and LUPREC.  
Although these system variables are restricted to values of 1 to 5 and 0 
to 8 respectively, (rtos) does not check the arguments to ensure they 
are correct.  Therefore, it is possible to specify a unit value over 5 
(which is just treated as 5), and precision over 8 units as shown in the 
following example:

	(rtos (/ 2 3.0) 2 16)

which returns "0.6666666666666666" which is close but not identical to 
the "0.6666666666666667" you might expect.  However, using a precision 
over 16 does not increase precision beyond 16 decimal places.  Also, the 
precision decreases as the number on the left of the decimal point grows 
larger.  Thus,

	(rtos (+ 1000 (/ 2 3.0)) 2 16)

returns "1000.666666666666" which is only 12 decimal places.  This 
pattern is followed for all precision values over 8.

Workaround: stay within the approved but not directly documented limits 
for these values, or write your own conversion function.


241+	[Common 13c2]  Documentation omission.
Mtext has a facility which is not documented.  If you draw a dimension 
with stacked fractions, explode it and list the text, you will find it 
is MTEXT with contents such as this for 3'-3 1/4":

	\A1;3'-3{\H1.000000x;\S1/4;}"

This uses the \A inline command which controls flow alignment.  It 
accepts an integer parameter:

	\A0;  baseline
	\A1;  centred
	\A2;  topline

Autodesk provides a fax-back document (967) which describes this 
facility and provides examples.  See item 242 for a problem when editing 
Mtext objects which use the \A code.


242+	[Win 13c2]  Bug.
The \A flow alignment inline command described in item 241 is not 
recognised by the internal Mtext editor.  If you draw a dimension with 
stacked fractions, explode it and DDEDIT the text, then make a minor 
change, the alignment will change from baseline to centred.

Workaround: use an alternative editor.


243+	[Common 13c2]  Bug/design flaw.
Draw a non-horizontal dimension with DIMFIT set to 4 (see item 49).  
Grip edit or DIMTEDIT to change the dimension text location, and the 
text will always flip to be horizontal, regardless the settings of 
DIMTIH and DIMTOH.  This occurs even if the leader mentioned in item 49 
does not appear.  The following script demonstrates the problem:

DIMFIT 4
DIMTIH 0
DIMTOH 0
DIMALIGNED 1,1 @3<30 @1<120
DIMTEDIT Last @0.5<120

Workaround: you can use DIMTEDIT with the Left or Right options to move 
the text to a limited degree.  You can also use the DIMTEDIT command to 
specify a fixed angle for the text.  See item 244 for a problem with 
this in some situations.


244+	[Common 13c2]  Bug.
Run the script shown in item 243 to create an aligned dimension with its 
text moved such that it has a leader.  Now use DIMTEDIT to attempt to 
change the angle:

 DIMTEDIT L Angle 30

The text angle will change, but the dimension will look very untidy.  If 
DIMTAD is 0, there is a large gap in the dimension line.  If DIMTAD is 
1, the horizontal part of the leader line remains in place as if the 
text were still there and interferes with the text.

Workaround: with DIMTAD=0, subsequent edits will mend the gap in the 
dimension line.  No known workaround for the DIMTAD=1 situation.


245+	[Common 13c2, to be fixed in 13c4]  Bug.
When specifying a font file in the STYLE command, the dialogue box 
allows you to pick a file.  If the file is in the ACAD path, the drive 
and directory is supposed to be stripped off.  This mechanism is not 
working in R13, meaning that a specific path is stored in the drawing 
file, which can lead to problems when sharing drawings between offices.

Workaround: use the Type It button and type the filename without the 
path.


246+	[Win 13c2]  Amusing buglet.
In some file dialogue boxes (eg. those for DXFIN, DXFOUT and PLOT), the 
filename edit box only displays lower case characters, regardless of the 
status of the Caps Lock or Shift keys when you enter the name.  Other 
file dialogue boxes (eg. NEW, OPEN) do not have this problem.

Workaround: who cares?


247+	[Common 13c2]  Bug.
Background: In R10, a system variable called FLATLAND existed which was 
a temporary conversion aid in AutoCAD's move from mostly 2D to full 3D.  
This variable has been gradually deprecated and disabled.  In R13, the 
variable is still there, but is not documented and should be permanently 
set to 0.  AutoCAD will accept 1 as a value without reporting an error, 
but ignores the input and leaves the value unchanged.  All this is as it 
should be, although arguably AutoCAD should let you know what is going 
on if you try to set FLATLAND to 1 as it did in R12.

Bug: If you OPEN, INSERT, XREF Attach or Overlay an R10 drawing which 
has its FLATLAND set to 1, the FLATLAND is set to 1 in R13, which should 
not be possible.  If you then attempt to draw a line from 1,1,1 AutoCAD 
will reject the point with a "2D point or option keyword required" 
message.  There is obviously some old redundant FLATLAND code in R13 
which still works.  Unfortunately, AutoCAD will ignore all attempts to 
set FLATLAND to 0, so you will just have to draw in 2D.  This applies to 
other drawings you may start or open in the same session which have 
nothing to do with this problem.  The problem does not occur with a 
DXFIN of the same R10 drawing.

Workaround: if you get out of AutoCAD and back in again, FLATLAND is set 
back to 0.  In the case where you insert a FLATLAND=1 R10 drawing, the 
problem will not be retained in the drawing.  However, if you reopen an 
offending R10 drawing, or an R13 drawing which externally references 
such a drawing, the problem will return.  You can solve this by saving 
the flat R10 drawing in R13 and getting out of AutoCAD.


248+	[Win 13c2]  Inconsistency.
In a paper/model space drawing, using the scroll bars to move around the 
drawing only affects paper space, regardless of whether you are in paper 
or model space at the time.  This is inconsistent with other AutoCAD 
display controls and different from the way R12 worked.


249+	[Common 13c2]  Bug in AutoCAD and/or Netware.
When using R13c2 on a Novell Netware 3.12 or 4.01 network, the OPEN 
command automatically turns on the "Read only" toggle when a file is 
selected on a network drive in any directory other than the root.

Workaround: set DWGWRITE to 1 before saving.  See item 24 for 
alternative workarounds.

Fix: it may be possible to fix this by obtaining updated VLMs from 
Netware, but I am unable to confirm this.


250+	[Win 13c2]  Bug.
In Windows, in the ***IMAGE section of the .MNU file, if a slide name is 
provided which is not embedded in a slide library, the slide image does 
not display.  Thus, these menu items work in R13 DOS but not in R13 Win:

[slide]^C^Cinsert thingy
[slide,Thingy]^C^Cinsert thingy

Workaround: you need to create a slide library to place the slide(s) 
into, and adjust the menu item(s) accordingly:

[buglib(slide)]^C^Cinsert thingy
[buglib(slide,Thingy)]^C^Cinsert thingy


251+	[Win 13c2]  Bug.
In Windows, a .MNU file which contains ***IMAGE section items like this:

[e:/bug/slide]^C^Cinsert thingy
[e:/bug/buglib(slide)]^C^Cinsert thingy

has the path stripped out during compilation, such that the .MNS file 
contains this instead:

[slide]^C^Cinsert thingy
[buglib(slide)]^C^Cinsert thingy

Workaround: 


252+	[Win 13c2]  Bug.
In Windows, a .MNU file which contains an ***IMAGE section item which 
contains the double quote/inches symbol character in the description, 
thus:

[buglib(slide,Thingy 6")]^C^Cinsert thingy

has the description stripped out during compilation, such that the .MNS 
file contains this instead, and the slide name is displayed instead of 
the description:

[buglib(slide)]^C^Cinsert thingy

No known workaround.


253+	[Win 13c2]  Bug.
In Windows, a .MNU file which contains an item like this:

[]

will generate an error during compilation like this:

ERROR ->  Menu Syntax Error Line: 375.

despite the fact that such items worked fine in earlier versions of 
AutoCAD and R13 DOS.  Such menu items are removed from the .MNS file.

Workaround: insert one or more spaces into the menu item, thus:

[ ]


254+	[Common 13c2]  Bug.
The AutoLISP (findfile) function is not reliable in a multi-user and/or 
multi-tasking environment.  If a file is being written to at the time 
(findfile) is called, it  will be unable to open the file and will 
return nil.

No known workaround.


255+	[Common 13c2]  BW  Bug.
Draw two dimensions which use a text style based on a .PFB or .TTF font 
file.  Stretch or grip edit one dimension onto another, using an object 
snap to locate the "to" point.  AutoCAD will usually crash, although 
sometimes it will not.  The type of crash ranges from an "Unhandled 
exception" which allows you to save your changes, through a "Page fault 
(or Null pointer) exception" which does not allow you to save changes, 
to an immediate exit to DOS without warning or a non-recoverable lock-up 
of the entire Windows system.

Other than using .SHX fonts for dimensions, one possible workaround is 
to use grip editing to precisely locate the "to" point rather than an 
object snap.


End Of List
