LISP: Problem with insert and pause...

Hello,

This may be the pause problem as referred to by Dan Wiseman in this forum post:
http://www.bricsys.nl/common/support/forumthread.jsp?id=12268

If I use this function:

(defun c:er ()
(command "_.-insert" "testBlock" "_scale" 1 pause 0)
(princ)
)

and cancel before supplying an insertion point, this message appears:

Cancel

; ----- LISP Error : Call Stack -----
; [0]...C:ER <<--
;
; ----- Error around expression -----
(COMMAND PAUSE)
;
; error : Lisp execution failure < <PAUSE input after command finished>> at [COMMAND]

 

So basically the error-function kicks in, but only after a lisp error report has been displayed. Is there a way to supress this report? Using (getpoint) instead of pause is not a good alternative because then you cannot see the insert as you are determining the insertion point.

Thanks in advance, Roy.

 

 

 

Comments

  • Dear Roy,
    indeed, this is not the normal + correct behaviour ... I have just checked what happens here :
    as I found, the INSERT command returns a wrong status to Lisp after (command PAUSE) is executed.

    It returns ERROR, instead of CANCELLED, thus the Lisp engine also reports + behaves other than expected.
    I just added a workaround, so any "erroneous" input to PAUSE (like ESCAPE) is treated as cancellation.

    Then, your code works as expected ... I hope to get this fix included in next Bricscad Beta version.

    Many greetings, and many thanks, Torsten

  • Hello,

    This also happens in other cases... for example :

    1)

    (setq pnt1 nil)
    (getpoint pnt1 "Pick a point") -> 

    ----- Error around expression -----
    (getpoint nil "Pick a point")

     

    2)

    (setq pc1 nil pc2 nil)
    (ssget "_F" (list pc1 pc2) (list (cons 0 "3DFACE")))  ->

    ; ----- Error around expression -----
    (CONS 0 "3DFACE")
    ;

    I run version 10.3.11

    Torsten, can you confirm the problem ?

     

    Philippe

     

  • Your problem doesn't seem related to pause. I think that both your code snippets fail because you use nil instead of valid points. What is your intention?

  • Hello,

     

    This is intentional...

    What I mean is that the error is not trapped correctly.

    Philippe

  • Right (and of course...)! So what we need is something like (setvar "do-not-show-extended-lisp-error-reports" 1). Because if you are debugging you do want to see this information.

  • I'd prefer the same behaviour than Autocad instead of another variable (if it is possible...).

    I generally define my error function like this :

    (defun myerror(msg)
     (vl-bt)   --> for debugging
    )

    then once debugged :

    (defun myerror(msg)
      (princ)  --> no echo
    )

    Philippe

  • Hello, Philipp & Roy ...

    that report
    ----- Error around expression -----
    (getpoint nil "Pick a point")

    most often is not exactly the point of the error condition -
    it is the last successful operation executed - to give a hint where
    the error is.

    But your idea is good :
    in case, any other error handler than the built-in *error* is the active
    one (like 'MyError'), then the default "error call back-track" could be
    suppressed ...

    The only point is, how to show that error location, even to developer ?
    As part of the error message itself ?

  • Hello Torsten,

    I don't understand what you mean by:

    " The only point is, how to show that error location, even to developer ?
    As part of the error message itself ?"

    Can't we simply mimic Acad behaviour ? Just asking, hey... Bricscad is getting better and better, keep on the good job.

    Philippe

     

  • @ Torsten:

    Maybe this could work:
    If (vl-bt) is present inside the error-handler:
    Incorporate "error call back-track" in error message,
    Else:
    Use AC-compatible error message.

    But in any case, incorporating the "error call back-track" in the error message seems a logical approach. As long as  this message starts with a fixed string, a developer can always decide to either display or hide it.

  • @Philippe - what I meant is : the error handler gets a string as argument ...
    my idea is, to add the extra (extended) error message regarding the error location
    to the same string, but with \n between - thus it is still 1 error message, that splits
    across multiple lines ...
    and developers might check if there is a \n and if so, limit text up \n, if desired.

    @Roy - I guess, you also assumed this ? :-)

    Probably a beter approach here :
    instead of using a system variable which is not present in Acad, we can also have
    a "magic" variable, like
    *extended*error*

    By default, it would be set to t - so extended error log (like current) is active -
    otherwise, if developer prefers to suppress this :

    (setq *extended*error* nil)

    will suppress both the callstack and error location message, thus, we have Acad
    like behaviour;

    this "magic" Lisp variable will work dynamically, so it can always switched to t or nil.

    Mainly we got only positive feedback on our Lisp error mode ... but I agree, it might
    be good to reduce the error output, especially if a custom error handler is defined.

    Another advantage of that "magic" Lisp variable - that variable can be changed even
    on client's machine, to investigate problems, which are only present on client machine,
    and not reproducable on developer machine ...

    So feedback is welcome :-)

  • Hello

    Ok, the magic variable seems to be a good solution. Can we give it a name so we remember it is Bricscad only.

    Philippe

  • Dear All,

    as mentioned before, the mode of extended error message and behaviour can now
    be controlled by Lisp code directly.

    (vl-bt-on)    : enabled "error callstack backtrace"
    (vl-bt-off)   : disabled "error callstack backtrace"
    (vl-bt <n>) : outputs the "error callstack backtrace" to commandline, regardless of
                          enabled / disabled backtrace state; uses <n> error levels;
                          intended to be used from inside error handler, usually

    This effects the behaviour of default *error* error handler, whether to show the
    error callstack backtrace.

    Additionally, there is now a "magic" Lisp variable which controls whether or not to
    display the extra error location message :

    (setq bcad$disable-extended-error t)   : disables output of error location message
    (setq bcad$disable-extended-error nil) : enables output of error location message

    Internal (startup) defaults :
    - error callstack backtrace is on
    - (setq bcad$disable-extended-error nil)

    Using these 2 features, the error output can be reduced to minimum style (like AutoCAD)
    or to maximum style incl. error callstack and error location message.

    I hope this is a good solution ?

  • Hello,

    Great.

    Philippe

  • @ Torsten: this seems like a good solution. Two questions:

    1. What exactly is the difference between: "error callstack backtrace" and "error location message"?
    2. Is (vl-bt-off)  enough for "totally silent mode" do you have to use (setq bcad$disable-extended-error t) as well?
  • Dear Roy,
    (vl-bt-on) and (vl-bt-off) controls the "error callstack backtrace" only -
    that is the stack of called functions

    (setq bcad$disable-extended-error t/nil) controls the extra message regarding
    the error location, like
    ; ----- Error around expression -----
    (+ 1 "")

    Both is independent (at the moment) ... but if prefered, both could be controlled
    by (vl-bt-on) resp. (vl-bt-off) ... just to your (and other developers' preference)

  • @ Torsten:

    These considerations spring to mind:

    1. Does (vl-bt-off) give you "totally silent mode" in AC? And should BC therefore behave the same?
    2. What use is an "error location message" without an "error callstack backtrace"?

    But because I only work with Bricscad both solutions wil be OK.

  • Dear Roy,

    2. the "error callback backtrace" is the sequence of called functions ...
        but the "error location" is the particular code which immediately triggered the error.
        So you can have a callstack of 3 levels, and the innermost is s (defun xxx ...) with 50 statements :
        the "error location" indicates the statement where the error happend - 1 of those 50

    1. (vl-bt-off) does not give a "totally silent mode" - this depends on active error handler :
        Acad AutoLISp always calls the active *error* function as (*error* "error message")
        So if a client code switches to its own error handler, then custom error handler can choose
        whether to print that message or not.
        Bricscad Lisp engine does exactly the same - no difference.
        Inside a custom error handler, the client code might call (vl-bt) to get an error call backtrace,
        but looks pretty strange

    I will improve Lisp engine, to call (vl-bt) - the standard output - only in case that the active error
    handler is the built-in error handler, not a client error handler.
    I think, this would be the best approach ... ?

This discussion has been closed.