Loading Multiple LISP Routines at Once...

We are trying to load multiple LISP routines at one time. We would like to
load them when AutoCAD is starting up, but do not want to use the acad.lsp
file to accomplish this task.

Thank you in advance.

 

Only if ACADLSPASDOC is set to 0.
A setting of 1 loads acad.lsp in every drawing opened.

 

Only if ACADLSPASDOC is set to 0.

True. The default is 0. Setting it to 1 defeats the potentially very useful
dustinction between the two files.

 

We have a custom menu on the server that everyone is mapped to (company.MNS) and a company.MNL in the same location.
All of the .VLX and .LSP files that are use frequently are loaded from the company.MNL.
Any other .LSP or .VLX files are called from the menu ie.
(if (not c:somelisp (load "somelisp")(princ)) somelisp.

 

All of the .VLX and .LSP files that are use frequently are loaded from the
company.MNL.

Syntax error in last line.

I don't like loading any lisps at startup because of the time wasted
compared to the autoload technique. I don't distinguish between frequently
used and otherwise, because I've learned that usage varies wildly among
users. I autoload everything, in small doses, so that nothing's loaded until
it's called, and there's never a delay waiting for this to happen.

I don't put any of the (if (not "blah") (load "blah"));blah; business in a
menu item, because it's just repetitive clutter. That's what mnl's were
intended for, to get the lisp out of the menu and to eliminate the question
of whether a lisp had been loaded. If the mnl says (autoload "blah"
'("blah")) then there's no reason to use anything more than ^c^cblah; for
the menu item.

 

I didn't know about autoload. I just looked it up and it looks to be the way to go.
The help file doesn't say anything about a VLX file, but I am assuming that will work as well.
I am getting ready to write a new menu and I will have to try autoload.

Thanks for the information.

 

The help file doesn't say anything about a VLX file, but I am assuming
that will work as well.

It takes a small tweak. There's a silly oversight in Acad's autoloader in
that it doesn't accept FAS or VLX files.

My loader-upper file, which is loaded by an mnl, consists of a number of
autoload statements. In that file, I redefined the ai_ffile function found
in acad2004doc.lsp as follows:

(defun ai_ffile (app)
(or (findfile (strcat app ".lsp"))
(findfile (strcat app ".exp"))
(findfile (strcat app ".exe"))
(findfile (strcat app ".arx"))
(findfile (strcat app ".fas"))
(findfile (strcat app ".vlx"))
(findfile app)))

This allows autoload to work with FAS and VLX files as well as the other
types.

For performance reasons (e.g. not waiting for things to load) I compile any
single lisp larger than about 5 or 10K as a FAS file and use a statement
like (autoload "jack" '("jack")). For multiple small lisps, I compile them
into VLX's in bunches of about 20 or 30K, and use a statement like (autoload
"lisp1" '("addbp" "alloff" "arrow" "bkln" "chglayer" "date")). In that
example, lisp1.vlx will load the first time the user issues any of the
commands listed.

 

Thanks Tom.
This gives me a whole new perspective on loading my routines.
Have a great New Year.

Ed Cable

 

You're welcome, same to you Ed.

Load time isn't as noticeable as it used to be on slower machines, but it
can make a big difference if you're automating things, as in running a
script on multile drawings.

I've even made myself another profile purely for scripting, which has no
menu at all and therefore, all of our custom stuff is disabled. I'll set up
the script to only load whatever lisps are actually needed. I found that
drawings will open at least three times as fast in a script, on my computer,
if there's no menu loaded. That's a big difference if you're processing many
files.

 

Try adding the routines to Startup Suite.

Type Appload, in dialog box press the button "Contents",

select the routines and close. In the next autocad section,

the routines are loadeds.

[]s,

Rogério

 

That's a good idea. I run scrips on whole directories of drawings occasionally, and never thought to create a profile for just that purpose.

Thanks again.

Ed Cable

 

But there are times when you would want to normally load a LSP file in each and
every drawing, e.g. if you offer your users a standard "macros" type of
application that has many company-wide keyboard macros as a
replacement/enhancement for acad.pgp.

If you try to autoload this, you'd had to define an Autoload expression for each
and every command, which could get daunting if you have many of them, and you'd
always have to sync the source macros file with the autoload expression, which
adds a bit of admin overhead.

Currently I autoload a standard "macros.vlx" package - using a modified
(ai_ffile) function that is STILL not fixed in 2005 - that contains hundreds of
keyboard macros. It's about 300K, yet doesn't cause a noticable delay in loading
for my 30-odd users.

The other thing I do is separate standard functions into separate library VLX
files, and "demand load" those libraries as required. That lessens the code
required in the macros and utilities. I currently have about 20 separate library
files for handling different types of tasks (registry, file I/O, blocks, text,
strings, etc.)

For times when one wants to turn off autoloading a "big" application like
macros.vlx (for speed or whatever), you could offer your users the option of not
autoloading it using a simple "flag" function (in acaddoc.lsp) which uses
(getenv) and (setenv) to read/write to the user's Registry...

(defun ToggleMacrosLoad (/ v)
(setq v (getenv "LoadMacros"))
(if v
(setenv "LoadMacros" (abs (1- v)))
(setenv "LoadMacros" 1) ;;default value = enabled
)
(princ)
)

...., which can accessed in a menu using DIESEL:
[$(if,$(eq,$(getenv,LoadMacros),1),!.)Load macros in every
drawing]^c^c^p(ToggleMacrosLoad)

And in your S::STARTUP function, use this expression to load them:
(if (= 1 (getenv "LoadMacros")) (load "Macros.vlx"))

Matt

 

Matt, I stand corrected -- I simplified to the point of incorrectness. I
should have said, I don't like loading any lisps on startup except when it's
actually necessary. One is the keyboard macro scenaro you mention.

I explicitly load 5 compiled lisps on startup, totalling about 35K, by means
of the mnl. They could have been combined into one, but it's clearer to me
to break them up by function. For that matter, they could have all been in
the mnl itself, but AFAIK it can't be compiled, and I've had a thing about
securing code ever since our whole suite of R14 lisps walked out the door
with a short term employee.

The mnl contains only one load statement. The compiled file it loads is a
"copyright" protection gizmo. Unless certain conditions are true, it will
crash with a software license error message, and none of our other lisps
will load individually. If the conditions are met, then it loads 4 other
compiled lisps.

The first contains menu-related "library" functions. None of our menu
customizations will work unless this is loaded. The second is simply a
lisp-loader-upper file containing ai_ffile and all my autoload statements.
(When are they ever going to remember to fix that?) The third is entirely
keyboard macros -- only about 11K of them, but then we obviously have a much
simpler system than yours. The fourth defines block-related macros. It's
only a 4K file, but has a slightly noticeable load time, because it scans
our block folders at load time and writes a like-named insertion macro for
each block found, maybe 800 more macros in all. The result is that we can
insert any standard block simply by typing its name. (There are other
interfaces for inserting blocks, of course, but our keyboard junkies love
this.)

For the autoloading stuff, I mentioned that I compiled all our mini-lisps
into VLX's in groups of a certain size. I found the size that was
comfortable for us purely by experimentation, and it's nowhere near your
300K! Obviously, we have some very, very slow computers still in use, but
that will change soon. If I could autoload more stuff in a gulp, I would --
I'll adjust this when the computers get upgraded. My point was that
performance issues are relative, and what's fast enough in one setting might
be horribly slow in another.

As I told Ed, if I'm going to run a script on hundreds of drawings, I really
don't want ANYTHING loading except what's actually going to be used in the
script. I have an alternate profile which doesn't load any menu, thereby
taking all our lisp out of the loop, as well as the menu load time. It makes
a remarkable difference in how quickly files will open. I can script process
files 3 or 4 times as fast with the "naked" profile, and that's a worthwhile
difference.

The option for not autoloading things is interesting, thanks. I'll tuck that
away for future reference.