I had a few lisps in my Startup Suite, and never had a problem with it. But I've seen posts by others saying that it's more 'stable' to load them by acaddoc.lsp instead. I was allured by the possibility of everyone on the network having them loaded, so I thought I'd try it.
Well, so much for 'more stable'. First of all, I couldn't get demandload to work at all, ever.
Then with plain load, it works in some drawings but not others. Specifically, it seems that when I start a new drawing from template, all the lisp commands are loaded and working. But when I open an existing drawing they rarely are. (Right now it seems they never are, but last time I was testing it I thought they sometimes were.)
I'm using the syntax:
(load "W:\\Civil 3D 2011\\extra\\lisp\\nonexistant.LSP" "The nonexistant lisp failed to load")
I actually put the above line in my acoddoc.lsp. But I never do get the warning about the nonexistant lisp, which I should, seeing as it does not exist!
So much for stability! What am I doing wrong?
Thanks.
Mark Green
Working on Civil 3D in Canada
@troma wrote:
...
I'm using the syntax:
(load "W:\\Civil 3D 2011\\extra\\lisp\\nonexistant.LSP" "The nonexistant lisp failed to load")
I actually put the above line in my acoddoc.lsp. But I never do get the warning about the nonexistant lisp, which I should, seeing as it does not exist!
...
Hi troma,
just for testing, copy/paste into the command line
(findfile "acaddoc.lsp")
is the returned path from the file you add the (load "W:\\Civil 3D 2011\\extra\\lisp\\nonexistant.LSP" "The nonexistant lisp failed to load")?
Henrique
Mark Green
Working on Civil 3D in Canada
Troma, try
(load "W:\\Civil 3D 2011\\extra\\lisp\\nonexistant.LSP" (prompt "The nonexistant lisp failed to load"))
HTh
Henrique
The second argument of the (load ...) call is returned on failure. If the argument is missing, a hard *error* is thrown. Normally I provide the path/filename in a variable and T for the second argument, then test the return. If the call fails (returns T), then I use the passed path/filename variable in the feedback.
The Startup Suite isn't profile-specific. If you only have one profile, you won't see many problems. If, like us, you have a number of application profiles running on top of AutoCAD you need some discrete control over what is loaded. There's also the option of application-only code in ACAD.LSP.
@troma wrote:I had a few lisps in my Startup Suite, and never had a problem with it. But I've seen posts by others saying that it's more 'stable' to load them by acaddoc.lsp instead. I was allured by the possibility of everyone on the network having them loaded, so I thought I'd try it.
Well, so much for 'more stable'. First of all, I couldn't get demandload to work at all, ever.
Then with plain load, it works in some drawings but not others. Specifically, it seems that when I start a new drawing from template, all the lisp commands are loaded and working. But when I open an existing drawing they rarely are. (Right now it seems they never are, but last time I was testing it I thought they sometimes were.)
I'm using the syntax:
(load "W:\\Civil 3D 2011\\extra\\lisp\\nonexistant.LSP" "The nonexistant lisp failed to load")
I actually put the above line in my acoddoc.lsp. But I never do get the warning about the nonexistant lisp, which I should, seeing as it does not exist!
So much for stability! What am I doing wrong?
Thanks.
If you tried just (load "W:\\Civil 3D 2011\\extra\\lisp\\nonexistant.LSP") you would get an error, and the rest of acaddoc.lsp wouldn't run.
The onfailure argument doesn't cause any error reports, it just suppresses them.
If you want a report on failure, but the rest of acaddoc.lsp running, something like this should work:
(if (eq (load "W:\\Civil 3D 2011\\extra\\lisp\\nonexistant.LSP" 'error) 'error) (alert "The nonexistant lisp failed to load"))
--
@dgorsman wrote:The second argument of the (load ...) call is returned on failure. If the argument is missing, a hard *error* is thrown. Normally I provide the path/filename in a variable and T for the second argument, then test the return. If the call fails (returns T), then I use the passed path/filename variable in the feedback.
The documentation says that the return value is Unspecified, if successful. On my case seems to return whatever was the value of the last thing executed in the loaded file, so, if that happened to be T, you'd also interpret that as an error. (or, if comparing to nil, anything non-nil returned would do that).
So, it would be less likely to cause erroneous reports to use some distinct value you are sure can never come from the file.
--
@dgorsman wrote:
The second argument of the (load ...) call is returned on failure. If the argument is missing, a hard *error* is thrown. Normally I provide the path/filename in a variable and T for the second argument, then test the return. If the call fails (returns T), then I use the passed path/filename variable in the feedback.
Should return...
I'm out of the office, and tested with a coworker pc, on AC2012
And the only way I can see the return error string is using a prompt, alert...
i.e.
(load "W:\\Civil 3D 2011\\extra\\lisp\\nonexistant.LSP" (prompt "\nThe nonexistant lisp failed to load"))
or
(load "W:\\Civil 3D 2011\\extra\\lisp\\nonexistant.LSP" (alert "The nonexistant lisp failed to load"))
Henrique
@hmsilva wrote:Troma, try
(load "W:\\Civil 3D 2011\\extra\\lisp\\nonexistant.LSP" (prompt "The nonexistant lisp failed to load"))
Here you are being fooled by the documentation of LOAD which incorrectly implies some special evaluation behaviour.
This is incorrect, LOAD uses the normal lisp evaluation rules, so all the arguments get evaluated in any case before LOAD is called.
So this would call PROMPT before the LOAD call executes, both on success and on failure.
On failure the result of LOAD would be what PROMPT returns, i.e. nil.
--
@martti.halminen wrote:
@hmsilva wrote:
Troma, try
(load "W:\\Civil 3D 2011\\extra\\lisp\\nonexistant.LSP" (prompt "The nonexistant lisp failed to load"))
Here you are being fooled by the documentation of LOAD which incorrectly implies some special evaluation behaviour.This is incorrect, LOAD uses the normal lisp evaluation rules, so all the arguments get evaluated in any case before LOAD is called.
So this would call PROMPT before the LOAD call executes, both on success and on failure.
On failure the result of LOAD would be what PROMPT returns, i.e. nil.
--
You are correct Martti, my bad...
We need to test the existence of an error and then use a prompt or an alert to get an error msg...
Thank you!
Henrique
My coding style will never have that so its not been a problem. The point is very valid though. Think I'll put that in the things-to-do list for the next code review.
Mark Green
Working on Civil 3D in Canada
@troma wrote:
Thanks everyone, interesting discussion. Pity I only understand half of it (or, rather, half understand all of it).
Is there a conclusion?
Troma,
the martti.halminen's message #7 it's the way to get on failure an error massage at command line...
Henrique
@hmsilva wrote:
And the only way I can see the return error string is using a prompt, alert...i.e.
(load "W:\\Civil 3D 2011\\extra\\lisp\\nonexistant.LSP" (prompt "\nThe nonexistant lisp failed to load"))
or
(load "W:\\Civil 3D 2011\\extra\\lisp\\nonexistant.LSP" (alert "The nonexistant lisp failed to load"))
Try this instead:
(eval (load "MyLISP.lsp" '(alert "Load failed!")))
Thanks Henrique
Just be careful if the last expression in an AutoLISP file is a quoted expression, e.g.:
(defun c:myboringcommand ( ) (princ "\nThis command is useless.") (princ) ) '(alert "Surprise!")
If you wanted to get fancy, this could even be done without an explicit EVAL call:
((load "c:/temp/koe.lsp" (lambda ()(alert "Load failed!"))))
But this has the problem that the value returned by successful loading would also need to always be something you can call as a function (for example, the symbol PRINC, unquoted), so I am not advocating this as a realistic usage.
--
Lee, I'm glad you've chimed in! My original code came from your excellent site:
The load function takes two arguments:
(load <filename> [on failure])
...
Although the on failure argument is optional, I would recommend to include it in the load statement, else the function will return an error should the file fail to load.
Using this knowledge we can populate our ACADDOC.lsp file with load statements to be evaluated when the ACADDOC.lsp file is loaded on startup.
In this way, the ACADDOC.lsp may look something like this:
(load "C:\\MyPrograms\\MyLISP.lsp" "MyLISP Failed to Load.") (load "F:\\My Folder\\MyApp.fas" "MyApp Failed to Load.") (load "MyProgram" "MyProgram Failed to Load.")
I really appreciate everyone's comments. However, before I go updating everything, let me revisit the real reason I started this thread. The problem is that the lisps load in some drawings but not others. I can have two or three drawings open in one session; in one the lisps all work, in another they are 'unknown command'. This is the real problem and I don't think anyone has addressed it yet. It seems we all focused on issue of getting the warning to show up, which is really a minor problem in comparison.
Mark Green
Working on Civil 3D in Canada
Mark Green
Working on Civil 3D in Canada