Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

comp.cad.autocad AutoLISP FAQ (part 1/2) - general
Section - [7] AutoLISP problems and bugs

( Part1 - Part2 - Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Forum ]


Top Document: comp.cad.autocad AutoLISP FAQ (part 1/2) - general
Previous Document: [6] AutoLISP editors and other tools
Next Document: [8] Sorting with AutoLISP
See reader questions & answers on this topic! - Help others by sharing your knowledge
  For AutoCAD 2000 and unexperienced VLISP users see [0.1].
  There are almost no known serious AutoLISP bugs. The language
  interpreter itself (ACADL.EXE/.EXP, VLISP) works undoubtedly well.
  Some restrictions are based on the AutoCAD, ActiveX or the Proteus
  (DCL) engine. Some support LISP programs (i.e. DDMODIFY.LSP) are
  faulty sometimes.
  For Visual Lisp see the README.txt which lists all known bugs and
  limitations. Crashes with reactors are ACAD bugs.

  Two inofficial buglists are at:
  http://www.cadonline.com/exclusive/bugs/bugwatchlist.htm (the big one)
  http://www.dotsoft.com/buglist.htm (a private and short one)

  * LDATA  by Tom Berger     (VLISP for R14 and A2000)
    In short: Don't use LDATA at all. It may destroy DXF and DWG's 
    in A2000. It is also VERY hard to get rid of them.

  * List Arguments with DOTTED PAIRS Passed from AutoLISP to
    Visual LISP or back may loose the outer parens.
    See the Visual Lisp README (undocumented in Vital Lisp)

  * SINGLE ATOM LISTS returned incorrectly from EXTERNAL APPS
    Visual LISP can not distinguish between a LIST of a single
    atom (element), and a single atom returned from an external
    ObjectARX or ADS application.

  * ENTGET used with LWPOLYLINE, HATCH  (R14 only)
    The Z coordinate (caddr (getval 10 ele)) is a random number and
    often causes a floating point exception because it may too low or
    too high. Workaround: see part 2, Subject [23.1]

  * ENTMAKE VERTEX  by Terry Dotson     (R14 only)
    A problem can occur during the process of using (entmake) to create
    polylines, you must assign the layer to each of the VERTEX 
    definitions (which Autodesk has told us), but you must also assign 
    the layer to the ending SEQEND. Absence of this will cause the SEQEND 
    to end up on the current layer, which can be later frozen. Attempts to
    move this piece of geometry will then cause a EREGEN error and crash 
    in R14 (only).

  * ACAD_STRLSORT: Strange sort order in Windows.
    The chars in Windows are not sorted on its ASCII representation!

      Windows: (acad_strlsort '("-1" "+1")) -> ("-1" "+1"),
      DOS:     (acad_strlsort '("-1" "+1")) -> ("+1" "-1")
      Both:    (mapcar 'ascii  ("-" "+"))   -> (45 43)
    More at http://xarch.tu-graz.ac.at/autocad/docs/strlsort-bug.html

  * AI_PROPCHK
    (ai_propchk) was renamed to (C:AI_PROP) in the R13c3 update
    patch. "The AutoLISP function ai_propchk has been changed to c:ai_prop
    so that it behaves similarly to other commands. This allows pressing
    return to bring back DDMODIFY if selected from the toolbar."

  * Faulty action callbacks in R13 DCL code crash AutoCAD
    There is a bug in R13 where AutoCAD crashes with a Fatal Error if
    an error occurs in AutoLISP code during an action callback from a
    scroll bar in a dialog box.  For instance, if you try to evaluate a
    null function during the callback, AutoCAD crashes instantly.
    Technically, this isn't a bug in the AutoLISP interpreter, but we
    would still call it an AutoLISP bug.

  * You cannot rely on bitvalue 64 in flag 70 in symbol tables anymore
    since R13, but in all previous releases. Inserted blocks may have 
    64 not set.

  What else? See the unofficial AutoCAD buglist compiled by Steve
  Johnson for more faulty AutoLISP programs and behaviours, at
  http://www.cadonline.com/exclusive/bugs/bugwatchlist.htm

  * Protected LISP Files
    In pre-c4a R13 protected LISP files didn't stay protected in
    memory. In our opinion, this problem needs to be made known to all, so
    developers don't inadvertently assume their protected code is
    safe from prying eyes. This FAQ topic caused a major problem in
    moderated CompuServe's AutoCAD Forum.

  * Limited number of open selection sets
    They are intermediatly stored in temporary files. Get rid of not
    needed selection sets with setting the symbols to nil and run (gc),
    the garbage collector, which actually closes those files then.
    The maximal number depends on the operating system, i.e. in DOS
    of the FILES= value in CONFIG.SYS. R13 improved the number.

  * Numbers: range, accuracy, numerical precision
    Integer numbers are internal long fixnums (signed, 32-bit), but the
    communication from AutoLISP to AutoCAD accepts only 16-bit short
    fixnums, in the range -32768 .. +32767, because AutoCAD needs only
    short fixnums.
    Floating point numbers are doubles (64-bit IEEE). All internal
    AutoLISP and AutoCAD numerical calculations work with this double
    format, which should be sufficient. At least the first 14 decimal
    places are exact.
    A common problem is the confusion betwen the actual number (exact)
    and the rounded string representation. The number which is shown on
    the command-line is always the rounded string which takes care of
    LUPREC and DIMZIN.
    However with geometric comparisons there often occur round off errors,
    so that it's wise to compare points with a small fuzz factor 
    [1e-12..1e-6].
      (equal pt1 pt2 1e-6)      ; 0.000001 rounding error tolerance
    instead of (equal pt1 pt2), esp. with angles.
    See also http://www.autodesk.com/support/techdocs/td30/td301207.htm

    VB: It was also reported lately, that with certain automation
    controllers loaded, numerical accuracy and locale issues (`, vs `.)
    had undesirable sideeffects. A solution and explanation of this 
    problem is pending. (Mostly in `, as decimal delimiter countries 
    such as Germany)

  * ACOMP's (EQ) strictness
    With [5.1] ACOMP's compiled code you have to take care that the
    (EQ) behaviour in BI4's is much stricter than in plain AutoLISP. In
    AutoLISP (eq "1" "1") is T where in ACOMP's compiled code it's nil.

  The following are not real bugs, that make AutoLISP crash or return
  false results. They are just bad language implementations.

  * AND and OR should return the value of the not-NIL argument
    instead of T. See http://xarch.tu-graz.ac.at/autocad/docs/and-bug.html
  * MAX and MIN should handle string types too, because < and >
    accept and process strings types too.
  * see ACAD_STRLSORT above.
  * for stack overflow errors see [14]

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA




Top Document: comp.cad.autocad AutoLISP FAQ (part 1/2) - general
Previous Document: [6] AutoLISP editors and other tools
Next Document: [8] Sorting with AutoLISP

Part1 - Part2 - Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
rurban@xarch.tu-graz.ac.at (Reini Urban)





Last Update March 27 2014 @ 02:11 PM