Black Box 4/BlackBox.cdr/textinfo/autolisp.arj/AUTOLISP.TXT

Text File | 1988-09-17 | 32.2 KB | 670 lines

--------------------

"AutoLISP Notes"
Technical notes about the AutoLISP inplementation from a lecture
presented at AutoCAD Expo '88 by Greg Lutz, Senior Programmer, Autodesk,
Inc.

AutoLISP is logically a separate application, communicating with AutoCAD
through a rigidly defined protocol.

Communication linkage is called the "far call" mechanism, largely for
historical reasons.

*    Strictly synchronous, each end waiting on the other.
*    A packet-passing protocol.
-      Packets normally 512 bytes, smaller for some message types.
-      Packets have a function code in a fixed location.
-      Remainder of packet format is defined by function code.
*    The means for passing the packets is different on different machine
     implementations.

-    On MS-DOS and Macintosh, true coroutines, with each party actually
     calling the other.

-    On Unix, the two parties are separate processes and pass the
     packets through a pipe.

-    On Unix, packet passing is augmented by signalling for efficiency
     in some cases.

Memory usage:

*    Classic LISP:  all objects are stored in fixed-size "nodes".
*    AutoLISP nodes are 10 bytes in size.  Node storage is acquired from
*    Storage for strings is the only other significant drain on heap space.
*    Nodes are never explicitly returned to the heap.  When an attempt
     to obtain new node or string space from the heap fails, "garbage
     collection" is performed.  This is a process which returns all
     "inaccessible" nodes to the free list.
*    Each data type listed in the AutoLISP Programmer's Reference
     corresponds to a different node type, as represented by a 1-byte field
     in the node itself.  Lists are the commonest type.

*    All heap storage, including that for built-in symbols, is released
     and re-initialized upon entry to the Drawing Editor.

The "atom list":
*    "Symbols" are just another data type.
*    Symbols distinguished by the fact that anytime one is created, it
     is added to the list called "ATOMLIST".
*    All built-in symbols come first on the atomlist.
*    All symbols referenced in LISP expressions are looked up on the atomlist.
     They can never be removed.  But you can redefine atomlist (at your own
     risk) to get rid of symbol definitions.
*    A new symbol is created by appearing as the first argument to the
     QUOTE or DEFUN function.  SETQ implicitly invokes QUOTE.

--------------------

           AutoLISP Extensions  Releases 9 and 10
          (notes from a lecture presented at AutoCAD Expo '88)
          by Duff Kurland, Autodesk, Inc., Sausalito, California

"Tools For The Golden Age Of Engineering"

AutoLISP Release 9
*    (command) pause for user input
*    (ssget "x") filters
*    Support for huge selection sets
*    Quiet function exit via (princ)

AutoLISP Release 10
*    New (getenv "varname") function returns string value of environment
     variable
*    New (findfile "name") function searches path (the current, drawing
     and ACAD directories), returns full file name
*    (load "name" [onfailure]) is now recursive, searches path, returns
     new "onfailure" argument upon failure
*    New S::STARTUP function (if defined) executes automatically at
     editor startup
*    (equal num num [fuzz]) provides optional fuzz factor for equality
     tests between reals
*    (tblnext) and (tblsearch) extended to support new VPORT and UCS
     symbol tables
*    (redraw), (grclear), and (grdraw) operate on the current viewport
*    New (vports) function returns IDs and locations of active viewports
*    Many functions, including (distance) and (inters), now support 3D
*    New FLATLAND system variable selects 2D (compatible) mode
*    (entget) returns new entity fields, including handles
*    (handent "handle") returns entity name
*    Points are normally in UCS, but (entget) and (entmod) work in ECS
*    (trans) translates between User, World and Entity coordinates

--------------------

From a paper presented at the "AutoLISP: Ask The Experts" conference at
AutoCAD Expo '88, May 3, 1988 by Brad Zehring et. al., Autodesk, Inc.,
Training Department.

Ten Of The Most Commonly Asked Questions About AutoLISP

1.   Can AutoLISP programs be compiled?

No, AutoLISP is an interpretive language.  It reads source code directly
and creates lists of tokens from expressions and function definitions as
it reads them.  Creating a compiler for AutoLISP would be a major
undertaking, and Autodesk has not committed to doing so at this time.
However, we are constantly exploring ways to enhance the speed and
flexibility of our applications interface.

2.   Can AutoCAD use any LISP interpreter/compiler other than AutoLISP?

AutoCAD and AutoLISP are designed specifically to work with one another.
Autodesk does not currently support any other LISP interpreters and/or
compilers.

3.   What is "Insufficient Node Space?"

This message appears when there is not enough space in the AutoLISP heap
to store all of the required functions and variables.  The size of the
heap can be adjusted with the environment variable LISPHEAP.  See
Chapter 6 of your AutoLISP Programmer's Reference for details.

4.   What can be done when AutoLISP programs become too large to fit in
the available node space, even if the size of the LISPHEAP has been
increased to the maximum?

AutoLISP supports Virtual Memory Paging, which allows AutoLISP to open a
temporary file and swap functions in and out of memory.  In many cases,
this can effectively increase the size of the heap far beyond its normal
boundary in conventional memory.  See the function VMON in your AutoLISP
Programmer's Reference.

5.   What causes the "LISPSTACK overflow" message?

There is not enough space in the AutoLISP stack to store the required
function arguments and partial results.  The size of the stack can be
adjusted with the environment variable LISPSTACK.  See your  AutoLISP
Programmer's Reference for details.

NOTE:  This error usually occurs because of a program error resulting in
a self-recursive function call, an example of which would be:

(defun a () (B))
(defun b () (A))
(A)

6.   What causes the "Out of RAM" message?

The setting for ACADFREERAM is too low.  This is a stack space in memory
that AutoCAD uses for working storage.  By default, the setting is 14
kilobytes.  Use the environment variable ACADFREERAM to increase its
size (up to its maximum of between 20 and 24 kilobytes).  See your
AutoCAD Installation and Performance Guide for more details.

NOTE: In Release 10, the default setting for ACADFREERAM will be its
maximum value of 24 kilobytes.  You will still be able to adjust the
size of ACADFREERAM via its environment variable, should you so desire.

7.   Why did Autodesk choose LISP rather than some other language as the
first AutoCAD Applications Interface?

LISP excels at working with collections of heterogeneous objects in
various sized groups, which is typically what a CAD program is used for.
It is ideally suited to the unstructured interaction that characterizes
the design process.  It is among the easiest of all programming
languages to learn and to master.  It is the chosen language for
research and development of artificial intelligence and expert systems.
And because of LISP's exceedingly simple syntax, a LISP interpreter is
easy to implement and quite small!

8.   Will Autodesk ever replace AutoLISP with a different language?

In the future, Autodesk may supplement the AutoLISP language with other
application interfaces.  However, Autodesk is committed to long-term
support for AutoLISP, and any new applications will be introduced as
enhancements to AutoLISP, not replacements.

9.   What is AutoLISP based on?

AutoLISP is a superset of a subset of Common LISP, the most popular LISP
implementation currently in use.  Many unique functions and features
specific to AutoCAD have been included in AutoLISP.  The interpreter
itself is based on XLISP, a program developed by David Betz.  Autodesk
gratefully acknowledges the contribution his work made to the
development of AutoLISP.  Information on XLISP is available from David
Betz, 127 Taylor Road, Peterborough, NH 03458.

10.  What books are available on AutoLISP and Common LISP?

AutoLISP specific:

Customizing AutoCAD
     by R. Gesner and J. Smith

AutoLISP In Plain English
     by George O. Head

Common LISP and other dialects:

Common LISP: The Language
     by Guy L. Steele, Jr.

LISP
     by Winston and Horn

Looking At LISP
     by Tony Hasemer

LISPcraft
     by Robert Wilensky

A Gentle Introduction To Symbolic Computation
     by David Touretzky

--------------------

From a paper presented at the "AutoLISP: Ask The Experts" conference at
AutoCAD Expo '88, May 3, 1988, by John Lynch, Senior Programmer,
Autodesk, Inc.

Extended AutoLISP
by John Lynch
April 25, 1988

What is Extended AutoLISP?

Extended AutoLISP is a special version of AutoLISP that has been
modified to take advantage of extended memory.  This version actually
runs in the native ``protected'' mode of the Intel 80286 and 80386, and
allows your programs to access large amounts of memory.  In simpler
terms, Extended AutoLISP gives you access to practically unlimited node
space on an IBM AT or compatible machine while maintaining DOS
compatibility.

We say practically unlimited node space because in a real sense you are
limited to the amount of extended memory available in your machine, but
you may access as much as fourteen megabytes.  In terms of what AutoLISP
can do with this memory, a megabyte of memory gives you approximately
105000 nodes.  A far cry from the 3072 nodes most applications have
under the current lisp implementation.

Other than this, there is no difference in features between Extended
AutoLISP and regular AutoLISP.  The function definitions remain the
same, and existing applications should run the same as before.

We expect to release Extended AutoLISP concurrently with AutoCAD Release
10. A price has not yet been established for Extended AutoLISP.

Why do we need Extended AutoLISP?

The need for additional memory has been an issue with AutoCAD since the
early releases.  AutoCAD uses memory as conservatively as any
application on the market, but with the number of features added to
Release 10, we have finally run out of memory resources below the 640k
barrier.

AutoLISP currently uses some of this precious memory resource for its
purposes.  AutoLISP is a ``small model'' program which means that it
uses a single code segment and data segment of 64k each, for a combined
use of 128k of memory.  AutoLISP, however, gets its memory from AutoCAD,
and is generally the first thing that loses memory when there is a
shortage.  This means that if you rely on network or device drivers, or
have numerous terminate and stay resident  programs (like Sidekick)
installed, you generally would get the message that ``AutoLISP is
disabled.''

By removing AutoLISP from ``low'' memory (memory below 640k), we
eliminate many of these concerns.  In fact, AutoCAD gets the benefit of
having more I/O page space to use, and can run a little faster because
of it.

AutoLISP was also pushing another barrier.  The 64k code segment size
prevented us from implementing any new features in AutoLISP.  As users
become more familiar with Release 10's new features, new AutoLISP
capabilities to access many of these features may be requested.
Extended AutoLISP will allow us to add new features, which would not
otherwise be feasible because of the code size barrier.

How do I install Extended AutoLISP?

Extended AutoLISP will come as an installable option for AutoCAD Release
10.  There are several files provided, one of which is a Terminate and
Stay Resident executable (extlisp.exe) and the other is a replacement
for acadl.ovl (regular AutoLISP), which communicates with Extended
AutoLISP.

To install it, you simply copy the files onto your hard disk, and make
sure that extlisp.exe is loaded (executed) before entering AutoCAD.
This may be done by placing it in your autoexec.bat file so that it is
installed each time you start your machine.  Then you simply copy
acadl.ovl supplied with Extended AutoLISP to the same place as the rest
of your AutoCAD executables.  You may want to save your copy of the
regular AutoLISP overlay first by copying it to another file (e.g. copy
acadl.ovl acadl.sav).


What are the hardware requirements?

Extended AutoLISP will run on 80286 and 80386 based machines that
support AutoCAD and also have extended memory available.  The minimum
amount of extended memory is about 200k, but we would recommend about
500k for a comfortable operating environment and to get the most benefit
from ExtLISP.

Extended AutoLISP will not run on 8086 and 8088 (XT) based machines.

Not all of your extended memory needs to be set aside for Extended
AutoLISP.  ExtLISP will recognize vdisk which uses extended memory, and
can also be configured to allow AutoCAD to use what is left for page
space.  A typical installation with 3 megabytes of extended memory (4
megs total) might set up a 1 megabyte vdisk, use a megabyte for Extended
AutoLISP, and let AutoCAD use the remaining megabyte for page space.

Extended AutoLISP will not work with expanded memory.  This is an
important distinction.  It will also not work with device drivers that
are installed to make extended memory look like expanded memory.  These
include CEMM (Compaq Expanded Memory Manager) and QEMM (Quarterdeck
Expanded Memory Manager).  This limitation stems from the fact that we
are placing code in extended memory which must be executed.  The
expanded memory schemes provide a paging mechanism for swapping data in
and out of low memory.  Although such a scheme could be used to
alleviate data size problems, it will not address the code size
limitations experienced with AutoLISP.

We have studied the Lotus-Intel-Microsoft (LIM) specification version
4.0 of expanded memory usage, and determined that it would not be
feasible to deliver the performance needed for AutoLISP.

How do I tell if I have Extended or Expanded Memory?

Generally your system configuration or diagnostics will tell you how
much memory you have installed.  If there is an entry for memory
installed above one megabyte (1M), it is likely to be the amount of
extended memory installed.  If not, you will need to add it to your
configuration to support Extended AutoLISP.

If you are in doubt, contact the dealer who sold you the system for an
idea of which type of memory is installed.  Extended memory is ``AT
type'' memory while expanded memory is used in PCs and XTs.

Perhaps the simplest method is to watch the memory test at power up. If
the numbers in the upper left corner of the screen go beyond 640k, then
there is Extended memory installed in your machine.

How is Extended AutoLISP created?

To create Extended AutoLISP we used a special software product known as
a ``DOS Extender''.  These products have become popular over the last
year or so, and have matured in features and stability.  The product we
used is DOS/16M created by Rational Systems, Inc. and was chosen for its
support of both the 80286 and 80386.  Other DOS extenders support only
the 80386, and are therefore more restrictive.

DOS/16M converts a DOS executable into an application that runs in the
``protected'' mode on the 80286 (386).  It also provides a library of
routines that allow the application to maintain a very high degree of
DOS compatibility.

How does Extended AutoLISP work?

From its inception, AutoLISP has been a ``stand-alone'', on-line program
with which AutoCAD communicates in a very special way.  Because of this
design, AutoLISP is easily separated from AutoCAD, and placed in
extended memory with the same communication channel between it and
AutoCAD.

Because ExtLISP lives in extended memory, it must run while the
processor is in its native ``protected'' mode.  AutoCAD, of course, runs
in ``real'' mode (as do all DOS applications), and the processor must
therefore be switched from real to protected mode and back again when
AutoCAD calls AutoLISP.

A typical cycle would be when AutoCAD signals AutoLISP to evaluate an
expression.  The expression is passed to the overlay (acadl.ovl) which
in turn signals Extended AutoLISP which switches the processor to
protected mode.  AutoLISP evaluates the expression, places the result in
a buffer, switches the processor back to real mode where  AutoCAD
resumes operation where it left off.

Is Extended AutoLISP faster or slower than regular AutoLISP?

As mentioned, there is a certain amount of overhead associated with
switching the processor from real to protected mode and back again.  In
addition, there is some overhead associated with
changing AutoLISP to multiple code segments.  On the positive side,
additional node space makes memory management (garbage collecting) less
critical.  Requests for more node space can usually be handled by
allocating an additional node segment.  This causes less memory
thrashing, and substantial time savings in execution of large functions.
Function paging, enabled by (vmon) is also eliminated, which saves a
considerable amount of processing.

Total performance is dependent on the activity and functions being
called. From our limited testing thus far, it appears as though Extended
AutoLISP runs at approximately the same speed as regular AutoLISP.  In
addition, there are some optimization steps that may be taken to improve
the performance of Extended AutoLISP (and regular AutoLISP for that
matter).
AutoLISP: Ask the Experts
AutoCAD (r) EXPO '88

Techniques in Integrating AutoLISP
B. Rustin Gesner

I was asked to join this panel from the perspective of the AutoLISP
power user or even developer doing system customization. I'm probably
no more expert than many of you, some of whom I've enjoyed the
pleasure of exchanging ideas with on the Compuserve forum. If you
don't use CompuServe, and you want to ask the experts, get online --
that's where the experts meet every day.

AutoCAD without AutoLISP is like a Model T Ford -- a lot better than
walking, but no Formula 1 race car. And, frankly a lot of users are
still driving Model T class systems. We all keep asking for more
"wishlist" new features, but most of us don't use 50% of what AutoCAD
and AutoLISP can do already. And, while AutoLISP is certainly a key
element in a high performance application system, you really should
consider the whole vehicle.

Most parts of the AutoCAD environment have flexibility that
customization can drive to greater productivity. In our Model T
analogy:

AutoLISP, and often an external program, is the engine; and

AutoLISP is the Drive Train; while

Custom Menus Steer and control your application;

Hardware and memory management are the accelerators; and

Good Error Control and system management are your Brakes.

To comprehensively cover these topics would take a couple of weeks,
or a couple of thick books, but we'll  touch on several key points.
The examples I'll use are contained in this handout, so you can look
at them more closely later. They are from the book, Customizing
AutoCAD, which I'd like to point out is by no means all my own work.
Joe Smith, who's showing structural software in his ACUWARE booth,
co-authored the book, and Pat Haessly, who works for New Riders,
contributed a lot. Remember, these examples may be out of context and
you may need additional functions or instructions from the book to
actually run them. Don't try to read all of these transparencies --
they're just to focus attention on key items.

Let's look at the steering first. Menus provide most of the look and
feel of your LISP programs. Controlling the MENUECHO and CMDECHO
system variables can make very clean, professional applications. Menu
design, and mixing menus and LISP can be controversial issues, but
there are several key techniques. Menus control when and how choices
are presented to the user. By using the MENUCMD function to call menu
pages, and GRTEXT to present status labels in screen menu boxes, you
can control and simplify the users choices. But don't overlook the
use of the menu page change itself as a control point to load
functions, or reset the environment. It is often easier and cleaner
to provide this control in a menu than in AutoLISP. One caution -- if
you integrate your menu with the standard AutoCAD menu, the user can
destroy this control with tablet picks. The last chapter of
Customizing AutoCAD tells how to deal with this and integrate menus.

NOTE: The parenthetical numbers like (1) refer to the pages of the
handout material for this talk, which is material extracted from the
book CUSTOMIZING AutoCAD. If you would like a copy of the handout,
send an 8.5x11 envelope (4 stamps please), marked "HANDOUT" to New
Riders Publishing, POB 4846, Thousand Oaks, CA 91360.

(1) A consistent and controlled user interface is also important on
the AutoLISP input side. In the front of the handout is the UDIST
User-getDIST function. UDIST is example of a function to present a
consistent user input interface, and to simplify programming. It
incorporates INITGET into the GET function, and handles displaying
and returning a default value automatically. You just call it with
the same values you would feed INITGET and GETDIST, plus a default if
any.

That AutoLISP can be your application's engine is pretty obvious, so
we won't dwell on that. What can get a bit trickier is integrating
external programs. This is very dear to many developers, because the
engines of their systems can be turbocharged compiled programs, which
are easier to protect form theft, as well as a lot faster. This is
also important to average users, whether you want to link in Lotus or
dBASE, or an engineering program. Whether your engine is an external
program or AutoLISP, AutoLISP is your drivetrain. It gets selection
sets with SSGET, user input with the GET functions, system status
with GETVAR and entity and table data with the entity and table
functions.

To drive your external programs from AutoLISP, don't overlook the PGP
link. You can define your own external commands in the ACAD.PGP file,
and call them with the COMMAND function, like any other command. You
can even call DOS batch files (or UNIX shells) via PGP. For simple
data passing to your external program, consider command line
parameters, which can even invoke replaceable parameters in a batch
file. If you really get carried away, and nest your batch files,
remember to use the COMMAND /C DOS call, or the CALL command in DOS
3.3 (see your DOS manual).

To output larger amounts of data, you currently have to OPEN a file,
write or append to it with WRITE-LINE or WRITE-CHAR, or the print
functions, and CLOSE it. This is all pretty straightforward, but the
greater problem with linking your AutoLISP drive train up with
external programs is getting data back in.

(2) While we hope to see direct data passing and random file access
in the future, present techniques require a little planning for
efficiency. Customizing AutoCAD covers several formats and
techniques, and page 2 of the handout shows one of my favorites. For
tabular data, consider your data file to be an array. Put each row of
data on a separate line, enclosed as a list in the file by a pair of
parentheses. Then, with the READ-LINE function you can quickly read
it in, then convert it to a LIST with the READ function. Carrying it
one step further, you can preface each line with a key code to search
on, like the example's PIPE-1. Then you can quickly test the CAR of
each READ READ-LINE, continuing to read in lines until you find the
line you need.

Notice the use of the SET (instead of SETQ) function to set the read
in PIPE-1 code to one of the data values. While SETQ sets a symbol to
a value, SET evaluates it's first argument and sets its contents to a
value. The ATTPIPE example uses the powerful but often overlooked
MAPCAR function to take this one more step. By mapping the SET
function to a list of symbols (PDIAM R FDIAM etc.) and a list of
data, ARGLIST, you can simultaneously set an entire list of
variables. MAPCAR is fast and efficient. The APPLY function can be
similarly used on a data list read in in this manner. A case came up
on CompuServe the other day. A user wanted to find the MAX of a
number of values that were in the form of a list. The most efficient
way is to use the APPLY function to apply the MAX function to the
list. Other examples of MAPCAR and APPLY, some 3-D tools, are on
pages 17 and 18 (sorry about the lack of page numbers). MAPCAR and
APPLY are great for efficient handling of 2-D and 3-D points.

(3) While not for data I/O, the VFFILE, BACKUP, and MERGEF functions
provide examples of AutoLISP file access, the use of AutoLISP to
drive the AutoCAD FILES utility, and driving a SHell PGP operation.
VFFILE verifies a file's existence (and it could use rewriting to
take advantage of RELEASE 10's FINDFILE function. BACKUP backs up a
file, and MERGEF merges or appends files through DOS. If you append
to a file that has a <CTRL-Z> End-Of-File character, your appended
data will be ignored by many programs. SHelling out and using DOS
COPY handles the <CTRL-Z>. Other examples of DOS and AutoLISP
integration in Customizing AutoCAD get much more involved, including
programs to generate HATCH patterns, create SCRIPT programs, and
automate Block updating. Which reminds me, our pattern generator
doesn't currntly work with UNIX -- you've gotta watch out for the
difference between back and forward slashes in SHELL processes. For
portability, your application should check to see if it's on a UNIX
or DOS system, and initialize a slash handling function accordingly.

(4) (5) Another important link between the user and AutoLISP, and/or
external programs is a text screen help and input screen system. For
professional 3rd party programs, you should call an external menu
screen system through SHELL, but for in-house user programs the
ANSI.SYS and AutoLISP format codes can do a lot. I won't go into
detail, but pages 4 and 5 provide some food for thought.

If you are a professional C programmer and really want to get carried
away, I suggest you read the ADI specification. It looks to me as if
its applicability isn't limited to hardware device manufacturers, and
you could develop some interesting linkages between AutoCAD, AutoLISP
and external or TSR programs.

(6) A lot of AutoLISP's power comes from its selection set, entity
access, table access and device access functions. They aren't really
hard to use, so if you've not tried yet, give them a try.

SSGET with the "X" options is very efficient for selecting groups of
entities by common attributes such as Entity type, Layer, Block name
and others. Sometimes you want to further filter selection sets like
these.

(7) For example, if you want to select all Circles on layer GREEN
except those with linetype DASHED, pages 6 and 7 provide some
functions for adding, subtracting and finding common entities in
selection sets. The SSUNION and SSDIFF examples show the use of the
SELECT AutoCAD  command to quickly merge or subtract two sets, rather
than slowly stepping through them with AutoLISP and SSMEMB, which
SSINTER must do. Notice the controlling of the HIGHLIGHT system
variable to speed up selection on screen. The book also has functions
to step backwards with LASTN, and to gather newly created entities
with CATCH. CATCH allows you to easily select all entities created by
Explode, for example.

(8) Although Extended AutoLISP takes some pressure off, Since
everybody else is talking about memory management, good memory
management can still accelerate your AutoLISP applications
performance. I included page 8 with some suggested practices and
alternatives. I also recently thought of a good technique, as yet
untested, which I'll briefly outline. It's efficient to standardize
and reuse variable names. Some users like to go further and use the
same name for all substantial functions. Perhaps you call it ROUTINE.
You control and execute it with a menu page for each program. Each
time you call another major function, it wipes clean and redefines
the previous one by LOADing the new one over top the old one. Each
initial execution is slowed while it loads, a drawback. Subsequent
executions of the new function are fast, since it is already loaded,
until the next major function is called. Besides memory management,
another advantage of this load-and-use technique is that your
ACAD.LSP load is faster and you only load what you use.

Consider taking this one step further. Create a stack of five or six
such function names, like ROUTINE1, ROUTINE2, ROUTINE3, and so on.
Write a function to manage the stack and map the names to the menu
calls. When the stack fills, the next function to load would
overwrite the first, and the next the second, and so on. In this
manner, you can have the advantages of self-cleaning load-and-use
while having several of your most recently used functions quickly
available. This idea should be effective whether you use CLEAN of
VMON, current or future AutoLISP. (NOTE: I have since programmed this,
and it will be included in a future edition of Customizing AutoCAD.)

Another simple, effective LOAD and management technique, which could
be combined with the above, is the self-loading self defining
function. This is in the last chapter of Customizing AutoCAD, and is
credited to Phil Kreiker, of Looking Glass MicroProducts. Quite
simply, in your ACAD.LSP file, major functions are DEFUNned as LOAD
functions to load themselves. Then the first time they are called,
whether by menu or keyboard, they load themselves. In the function
file itself, you put a call to the function itself as the last line.
Be sure to call it with a C: if it is a command function. Then for
subsequent executions, it is already loaded and available.

(9) (10) Your brakes are a good set of error handling functions to
keep the environment clean and consistent. AutoLISP's standard
*ERROR* function is designed to be user redefinable, and pages 9
through 12 of my handout show such a system. It's fairly self
explanatory, so I won't go into detail, but the key points are:
Resetting of system variables and Layers; Undoing lost entities and
unfinished tasks; Prompts to the user; and printing of messages.

This error system allows a program to interactively add and remove
items from its error recovery task list. The subroutines can also be
used for general management and  resetting of the environment and
Setvars.

(13) Like the earlier UDIST function, it's often useful to use  small
standard functions for frequent tasks. For example, the DXF
extraction function, on page (13) extracts a piece of entity data
from an entity data list. I suppose it might be a tad less efficient
executing than putting the code in line in every program that needs
it, but it reduces code size and makes programs easier to read and
write. It's slightly simpler to use (dxf 10 elist) to get a
coordinate than (cdr (assoc 10 elist))

The BSCALE program, also on page 13, uses DXF and the UREAL (a
similar GET function to UDIST). It is an example of entity access and
modification, and does what AutoCAD cannot directly do: rescale an
existing Block with independent X, Y and Z values. It's a simple
example of the use of ENTSEL, to select an entity, ENTGET, to get its
data, and our DXF and UREAL functions. Then it uses CONS to build the
new new entity data scale values, SUBST to substitute them in the
entity data list for the original values, and ENTMOD to redefine the
entity in the database.

By the way, you could actually substitute UDIST for UREAL in BSCALE.
Using GETDIST to get REAL values lets you "show" AutoCAD the value.

(14) As you get into more complex entity and table data access, you
might find our DXF codes table on pages 14 and 15 useful. They gather
together material otherwise somewhat scattered in the AutoCAD manual.
Of course RELEASE 10 will require some changes to this table.

(19) Lastly, since we're all looking forward to RELEASE 10's full
3-D, I threw some examples of 3-D utility functions, formulas and
diagrams in at the end. I'll leave you to peruse them on your own.
Most aren't obsoleted by RELEASE 10.

If I get this far, I'm finished.