automatic reloading lisps

[The Buzzard]

the startup suite is part of the profile so when changing machines import the profile and the programs list will be there, but you will have to bring over the programs also and depending on where they are located you might have to make a few path adjustments. this is why you should always make a folder on the C drive for programs because that path never changes

 

Thats how I have always handled my routines. Cannot help but notice how many folks put everything in the Support folder rather then make a dedicated folder on C: and add it to the Support Search Path. So much easier to find what your looking for and also less problems when you upgrade. You do not lose all your files.

[ronjonp]

If you name the lisp file the same as the calling command, you can use this to load all the files in a given directory (and add that directory to the support paths) I call this from my *.mnl file:

 

(defun rjp-loadlisp (dir / files)
 (setq files (vla-get-files (vla-get-preferences (vlax-get-acad-object))))
 (vla-put-supportpath files (strcat (vla-get-supportpath files) ";" dir))
 (foreach x (mapcar 'vl-filename-base (vl-directory-files dir "*.lsp" 1))
   (vl-catch-all-apply 'autoload (list x (list x)))
   ;;(setfunhelp (strcat "c:" x) "acadtools" x);;add F1 shortcut to help file
 )
 (princ)
)
(rjp-loadlisp "c:\\my\\lisp\\directory")

[rkmcswain]

the startup suite is part of the profile so when changing machines import the profile and the programs list will be there...

 

Well there you have it... We don't mess with profiles and certainly don't migrate them from one version to the other...

[Glen Smith]

I know this thread is a bit old, but my question has been partially answered here, so for the sake of future searchers...

 

I do not have an ACADDOC.LSP file out of the box, so where should it be in my file structure? rkmcswain, you suggest placing it on the network so it can be accessed by several people and for future upgrades. I like this idea - so where do I tell AutoCAD where to lok for the ACADDOC.LSP file?

 

Is there anything more to it than the code you posted below?

(load "mylisp")
(load "myotherlisp")
;;if the lisp file is not in your support file search path
(load \\\\server\\share\\path\\lisp2)

 

Many thinks.

 

Glen

[alanjt]

I know this thread is a bit old, but my question has been partially answered here, so for the sake of future searchers...

 

I do not have an ACADDOC.LSP file out of the box, so where should it be in my file structure? rkmcswain, you suggest placing it on the network so it can be accessed by several people and for future upgrades. I like this idea - so where do I tell AutoCAD where to lok for the ACADDOC.LSP file?

 

Is there anything more to it than the code you posted below?

(load "mylisp")
(load "myotherlisp")
;;if the lisp file is not in your support file search path
(load \\\\server\\share\\path\\lisp2)

Many thinks.

 

Glen

You can put it wherever you like, just make sure you add that directory to the Support Paths in Options.

[Olhado_]

Any working LISP code will work; but the following line is nice to have at the end, so you know the file actual ran.

 

; Load LISP

(princ "\nacaddoc.lsp loaded")
(princ)

 

Also, if you do more in this file, then load LISP files, then you may want to add the following lines:

 

(setvar "CMDECHO" 0)  ; Allows for quite load

;;; Rest of Code
; Load LISP 

; Set AutoCAD variables

(setvar "CMDECHO" 1)  ; Allows for quite load
(princ "\nacaddoc.lsp loaded")
(princ)

[Lee Mac]

Olhado,

 

There is no need for the change to CMDECHO - it does not mean "quiet loading".

 

CMDECHO just suppresses the command line return, when issuing commands to the command line.

 

You should not need to mess with Sys Vars outside of LISP functions, as this can get messy if there is an error.

[alanjt]

Olhado,

 

There is no need for the change to CMDECHO - it does not mean "quiet loading".

 

CMDECHO just suppresses the command line return, when issuing commands to the command line.

 

You should not need to mess with Sys Vars outside of LISP functions, as this can get messy if there is an error.

 

Not true, in our acaddoc.lsp I have it set several system variables, as I'm sure many companies do. A good method is to just check if the variable exists (version differences). For example: (and (getvar "cmdecho") (setvar "cmdecho" 0)). However, I use this, just to make sure that the entered value is actually acceptable.

;;; Setvar Replacement
;;; #Variable - Variable to set
;;; #Setting - Setting for setvar
;;; Example - (AT:Setvar "clayer" "A") -> "A"
;;; Example - (AT:Setvar "cclayerr" "A" -> nil
;;; Alan J. Thompson, 05.05.09
(defun AT:Setvar (#Variable #Setting / #Check)
 (if (not (vl-catch-all-error-p
            (setq #Check
                   (vl-catch-all-apply 'setvar (list #Variable #Setting))
            ) ;_ setq
          ) ;_ vl-catch-all-error-p
     ) ;_ not
   #Check
 ) ;_ if
) ;_ defun

[Olhado_]

I am glad we are not the only company that sets system variables in the acaddoc.lsp file and I will take a look at your check code.

 

However, it looks like Lee's recommendation is not entirely incorrect. It looks like Autodesk recommends using the acaddoc.lsp file to only load macros.

 

If you want to run programs (other code) at start up, then you place that code in the inside the below function, which would be located inside the acaddoc.lsp code.

 

(defun s::startup ()
; Run Startup Code

(princ)
)

 

I learned this from here.

 

If anyone else has any more information, then I would love to hear more, especially what is the significance of the "s::".

[Lee Mac]

I can see that my post was taken in completely the wrong way,

 

You should not need to mess with Sys Vars outside of LISP functions, as this can get messy if there is an error.

 

I should probably have added "Sys Vars that you intend to reset" - using your example with CMDECHO (which is unnecessary), say you disable a different Sys Var when loading a LISP, intending to reset it after the LISP has loaded - if there is an error, the sys var will not be reset.

 

Of course, those sys vars that you do not intend to reset are set through the ACADDOC.lsp - this is a known fact.

 

There is no need for the change to CMDECHO - it does not mean "quiet loading".

 

CMDECHO just suppresses the command line return, when issuing commands to the command line.

 

The above still holds, I stand by what I say.

[alanjt]

I am glad we are not the only company that sets system variables in the acaddoc.lsp file and I will take a look at your check code.

 

However, it looks like Lee's recommendation is not entirely incorrect. It looks like Autodesk recommends using the acaddoc.lsp file to only load macros.

 

If you want to run programs (other code) at start up, then you place that code in the inside the below function, which would be located inside the acaddoc.lsp code.

 

(defun s::startup ()
; Run Startup Code

(princ)
)

I learned this from here.

 

If anyone else has any more information, then I would love to hear more, especially what is the significance of the "s::".

 

 

Yes, the use of S::Startup is where you should place anything. However, you shouldn't redefine the S::Startup, just append to it.

(defun-q MyStartup (/) 
 blah blah
 blah blah blah
)

(setq S::STARTUP (append S::STARTUP MyStartup))

[alanjt]

Originally Posted by Lee Mac

There is no need for the change to CMDECHO - it does not mean "quiet loading".

 

CMDECHO just suppresses the command line return, when issuing commands to the command line.

The above still holds, I stand by what I say.

I don't think anyone disagrees with you there.

[Lee Mac]

I don't think anyone disagrees with you there.

 

Not true,

 

 

........

[Olhado_]

Lee, yeah I knew CMDECHO does not mean quite loading. But, I could not come up with a better way to describe what I was doing in my code, which is a "quite load".

Basically, I only want "acaddoc.lsp loaded" to show up on the Commandline and not all the system variables being set to values.

I will try to be clearer, in the future, since this is a learning forum.

[Olhado_]

Yes, the use of S::Startup is where you should place anything. However, you shouldn't redefine the S::Startup, just append to it.

 

So, where is it originally defined because I looked in the acad2009.lsp and acad2009doc.lsp files; but could not find it there, so I was just going with what the posted blog instructed.

Is this a function that just exist in AutoCAD?

Thanks.

[alanjt]

........

 

You should not need to mess with Sys Vars outside of LISP functions, as this can get messy if there is an error.

 

 

In reference to the above, not about the properties of the cmdecho system variable. If you read my post, you can clearly see I'm not arguing about toggling the on/off state of cmdecho for loading purposes.

[alanjt]

So, where is it originally defined because I looked in the acad2009.lsp and acad2009doc.lsp files; but could not find it there, so I was just going with what the posted blog instructed.

 

Is this a function that just exist in AutoCAD?

 

Thanks.

Generally, by default, it's not defined, but just in case it's defined elsewhere, appending to it will cover your bases. If it doesn't exist, no harm, if it does, you just piggyback on it.

[Lee Mac]

Lee, yeah I knew CMDECHO does not mean quite loading. But, I could not come up with a better way to describe what I was doing in my code, which is a "quite load".

 

Basically, I only want "acaddoc.lsp loaded" to show up on the Commandline and not all the system variables being set to values.

 

I will try to be clearer, in the future, since this is a learning forum.

 

Ok Olhado, but you shouldn't need to mess with CMDECHO to prevent the user seeing the Sys Vars changing, as no command calls are needed to change Sys Vars.

 

Just (setvar )

 

Lee

[alanjt]

Controls whether prompts and input are echoed during the AutoLISP [color=Red]command[/color] function.

0    Turns off echoing
1    Turns on echoing