Lisp and Support files

I am hoping that someone can help shed some light on an issue that I am
facing in regards to the loading and using of Lisp routines in Acad 2005.
Bottom line, I have several routines that loaded and worked great with 2000i
and they still work with 2005. My issue is that most of the time, the
routines have to be manually loaded.

I have several routines that I want to load anytime a drawing is opened and
I would like for them to load each and every time. I have about 10 users
and so I would like to have all this happen within the acad support paths so
that I do not have to go to individual workstations each time I enhance or
make a addition. I have created an acad.lsp file which is located within a
support path that is on all the users systems however, some of the lisps
load and some do not. I have loaded a lisp with appload, gone to test it
and it will not work. On some machines it does and others it does not. All
the computers all XP Pro with Acad 2005. This is driving me nuts.

How can I simplify and solidify the organization and loading of these
routines? With Acad 2005, there are now 2 or 3 support locations and what
goes where? I am referring to the acad.lsp, acaddoc.lsp or anything else I
can create to better organize and maintain my systems and tools.

Thank you in advance for any information that anyone may be able to provide.

James.

 

First off...do it in your acaddoc.lsp not the acad.lsp. acaddoc.lsp loads
with every drawing whereas acad.lsp only loads once per session unless you
specify otherwise in the settings.

Another suggestion is to use the autoload lisp command in your acaddoc.lsp
instead of just loading. That way, the command is only loaded when it is
invoked.

(autoload "LISPNAME.lsp" '(("LISP COMMAND")))

for example

(autoload "deletelayerfilters.lsp" '(("dlf")))

Also, make sure the lisp files are stored somewhere in the support file
search path of each computer.


Casey

 

Hi James,

A possible cause of inconsistent behaviour is that AutoCAD loads the first
file it finds in the search path. On some computers an alternative Acad.lsp
may be getting loaded.

--

Regards,


Laurie Comerford
www.cadapps.com.au

 

What I do is load all my stuff into a .mnl file associated with our custom
menu file.
That way, when the menu file gets loaded, all of our custom routines get
loaded with it.
If you use a custom menu file, that would be one solution.
Then, when AutoCAD get upgraded, all of your routines should go along
without modifications to any of the acad*.lsp files. That's my theory
anyway.

 

What I do is load all my stuff into a .mnl file associated with our custom

I also "trigger" everything through the mnl, but I don't explicitly load
anything except what's necessary during startup. All the other lisps are
autoloaded, so the actual load doesn't happen until they're called. This
gets the drawing open noticeably quicker than loading everything at once.

 

Hi James,if I not misinterpreted,I always loaded routines codes.

Tools >>Load Application.. >>Contents.. >>Add.. >> find your routines code

 

Exactly - a snip from my .mnl file:

(defun C:AD () (load "dimtext" ) (C:AD) ) ; alter
dimension points
(defun C:BE () (load "ddblock" ) (C:BE) ) ; block
insertion editor
(defun C:BF () (load "break" ) (C:BF) ) ; break
first command
(defun C:BR () (load "break" ) (C:BR) ) ; break
repeat command
(defun C:BS () (load "break" ) (C:BS) ) ; break
single command
(defun C:CAP () (load "joinlines") (C:CAP) ) ; caps ends
of two parallel lines
(defun C:CAPS () (load "shiftxt" ) (C:CAPS) ) ;
UPPER/Cap/lower case text editor
(defun C:CB () (load "centernotes") (C:CB) ) ; Changes
Section note text to be center justified

 

Exactly - a snip from my .mnl file:

Well, not exactly. You didn't read my post very carefully. I'm making a
distinction between distinction between the (load) and (autoload) functions,
which are quite different. Autoload is covered in the help docs.

I specifically *don't* load anything that isn't actually necessary to the
startup process itself. My mnl only loads four files, each of which does
something slightly different, for instance:

(load "our_lisp.fas") ;load the file which autoloads all other lisps

The our_lisp.fas contains quite a number of autoload statements:

;lisps with a single command per file:
(autoload "a2l.fas" '("a2l")) ;lisps with a single command per file
(autoload "fdn.fas" '("fdn"))
...etc...
;lisp which contains a number of commands.
(autoload "lisp2.vlx" '("pua" "pw" "rsl" "rsp" "pdh" "pdl" "pdv" "bm" "hdr"
"dtr" "stl" "s2b" "s2" "x4b" "x4" "sxb" "sa" "upd" "vbs"))

The point being, *none* of these individual files are loaded, opened, or
read until the one of the listed commands is invoked. If the user never
enters "a2l," then a2l.lsp is never loaded. Considering that we have many,
many dozens of custom lisp commands available, there would be a unacceptable
delay in opening a drawing if every one of these lisps were loaded in the
manner you use. Using the autoload method eliminates this.

In order to autoload compiled lisps, my "our_lisp" file also redefines of
the (ai_ffile) function, as has been discussed in this NG.

 

typical autoloader from my mnl file:

I don't see the reason for the duplicate test. Wouldn't this be exactly the
same?

(defun C:ACT ()
(if ACTIVATEIT
(ACTIVATEIT)
(ARCH:LOAD (strcat ARCH#FILF "ARCH_ACTIVATE.lsp")))
(princ))

 

Yes, you are correct...I'm still learning....and bad habits are hard to break.

Gary

 

Semantics..... this doesn't load anything until the command is called
either.

The majority of my stuff was done long before autoload came around.
Autoload also uses memory to store the command name and file to load up if
the command is called.
It could be written as (autoload "dimtext" '("AD")) and do the same thing.

 

Semantics..... this doesn't load anything until the command is called

thing.

Point taken. In the simplest case, that's functionally equivalent, the only
difference being a more concise syntax in the (autoload) version. Before the
autoload function came along, I wrote my own version, which worked the same,
for the sake of the more compact syntax, which eliminated the repetitive
typing of defuns.

Your homebrew autoload method only lends itself to the scenario of one
"command" defined per lisp file, and I seldom do that anymore, except for
cases where the one function is fairly huge in its own right. I find it
easier to keep all my tools related to dimensioning, for instance, in one
file. For those remaining groups of little one-command lisps, I prefer to
compile them into a single vlx, as in the last example I gave. I find it
much easier to manage a dozen or so compiled files in my lisp folder, as
opposed to the 800+ files I'd have by now if I had stuck with one command
per file.

There's more than a semantical difference between using a single autoload
statement to load a file if any one of eighteen commands are issued, as per
my example, versus churning out eighteen separate repetitive defuns to
achieve the same thing.

 

I tried a cond version too ...

(defun C:ACT ()
(cond
(ACTIVATEIT
(ACTIVATEIT))
((ARCH:LOAD (strcat ARCH#FILF "ARCH_ACTIVATE.lsp"))))
(princ))

As usual, in the case of a simple if/then/else situaion, the if construction
is slightly more compact and clear than the cond. But if the were more than
two possible outcomes, cond would start looking a lot better.

 

For loading a routine, I also use a dialog based routine...

That's an impressive dialog, and would probably be an asset for training new
users to your system.

I very seldom explicitly load a particular routine, unless I'm doing
something pretty specialized, and that's usually in the context of running a
script on multiple drawings. For everyday work, I just autoload everything
on startup.

 

This response is perhaps a little beyond the scope of James' original issue, but it is my 3 cents on how I administer (major) programs to my users.

I am in a situation where I am administering roughly 30 AutoCAD workstations located in 3 different states. (Washington, Illinios and Kentucky) And I want to be able to do this from my desktop without walking (or flying) around. All three sites are networked and share the same network drive letters.

I created a *very* simple "stub" .vlx program that is placed on each users computer and is launched from a single Toolbar Button (or drop-down menu). I don't care how the user launches the program, I just want them to launch it.

This "stub" program essentially COPIES a directory structure (and the files located there) from a common network drive location to their local C: drive.

Example:

V:\AutoLISP\Alisp\
\Bitmaps\
\Dialogs\
\Drawings\
\Systems\

...is replicated to the users C: drive.

C:\AutoLISP\Alisp\
\Bitmaps\
\Dialogs\
\Drawings\
\Systems\

The last command issued in the "stub" .vlx program is a call to load an interface program located within this directory structure. For example: load a .vlx file called Master_Interface.vlx located in the "c:\AutoLISP\ALisp" directory.

This displays a dialog box (modal or dockable or maybe even a custom toolbar designed with ObjectDCL) that allows the user to select from any number of programs that EXIST within the replicated directory structure. The options in the interface dialog box are directly linked to the programs that exist in the replicated directory structure on the users local drive.

This allows me to make changes to ANY file that exists within the replicated directory structure. When I edit a program and want to administer it to all 30 users I simply place it in the network directory structure. I know that when any individual user fires up the interface, his computer will be upgraded with the last changes that I made.

Because the stub program does all the work, I can even update the interface dialog box via the network and I know that the stub program will make the update happen and the user will be greeted with a new option in the interface dialog box.

Knowing that I would eventually want to add to the functionality of the "stub" program, I programmed a section (in the stub) that would always search a particular directory in the replicated directory structure and run certain file names (or Extensions). This allows me to add all kinds of cool (or just temporary) functions that would help me to "build" onto the original programming in the stub program over the years WITHOUT having to go to every users computer to replace the master stub program. The original "stub" program is dated 08/15/00 and I have never needed to touch it.

Technically, there's no reason to have to replicate the directory structure from a network drive to the users local drive. But in the early days of our network, let's just say it wasn't always UP all the time. In this case, the "stub" program would see that the network drive was unavailable, not initiate a replication and use the programs that already existed on the users local drive directory structure as it would normally.

The replication is also smart in that it compares file dates and times from the network drive and the users local drive and only updates those that are necessary. Otherwise, the copying would take forever if you did it wholesale slaughter every time.

This system is really meant for updating medium to large programs that are used a half dozen times a day. I designed and programmed a CAM System for wire edm machining and these are the types of huge programs that I administer. However, I DO use the Extension Services (as described above) to copy small utility programs over to the users local drive to a directory called (in this case) c:\AutoLISP\User. All of my users are mapped to this directory and can utilize any one of the hundreds of small utilities that exist there. (Most tiny utility type programs are located in custom toolbars that the user launches. I update these whenever necessary via the networked system.)

Anyway, I could rant on about all the other features in this system. Suffice it to say, it has served me well over the last 5 or so years. However, I don't seem to get as much exercise as I used to!! Is that a bad thing?


David Lister
Mikron Industries