If this is done, you must also invoke *pop-error-mode* after the old *error* handler is restored.Posted by James Johnston on 16 July 2018 11:17 AM If your logic has nested pushes and pops of the *error* handler, and an *error* handler has been set up to use the command function by invoking *push-error-using-command*, while the nested handler will not use it, you can provide access to the locally defined symbols on the AutoLISP stack by invoking *push-error-using-stack* at the same point where you set *error* to the current handler.When restoring an old error handler, also invoke the *pop-error-mode* function to reverse the effects of any call to the *push-error-using-command* or *push-error-using-stack* functions.However, if your program actually pushes and pops error handlers as part of its operations, or your AutoLISP logic can be invoked while other unknown AutoLISP logic is invoked, there are a couple more steps you may have to make. Now the command function can be used within the *error* handler. If the *error* handler refers to local symbols that are on the AutoLISP stack at the point where AutoLISP program failed or was cancelled, you must remove those references, or make the referenced symbols global symbols.Īll local symbols on the AutoLISP call stack are pushed out of scope because the AutoLISP evaluator is reset before entering the *error* handler.NoteWhenever an AutoLISP expression evaluation begins, the AutoLISP engine assumes that the command function will not be allowed within an *error* handler. When overriding the *error* symbol with a custom *error* handler, invoke the *push-error-using-command* function to inform AutoLISP that error handling will be used with the proceeding command functions.The following is an overview of what is required to continue to use the command function in the *error* handler. If using the command-s function is not viable option, then the command function can still be used, but only at the expense of losing access to any local symbols that would normally be on the AutoLISP call stack at the time of the *error* processing. Retaining the use of the command function in *error* handler.(command-s "_-TEXT" insPt "" "0" "Sample Text") (setq insPt (getpoint "\nSpecify text insertion: ")) (prompt "\nERROR: mycmd failed or was cancelled") For the same set of command tokens, command-s function is significantly faster. The "subroutine" style of command token processing can be used in a much wider range of contexts, but processes all command tokens in advance, and actual execution is non-interactive. In summary, the "co-routine" style of command token processing is more functionally powerful, but is limited in when it can be used when running. In this logic flow, subsequent token expressions can query AutoCAD for the results of previous token processing and use it. AutoCAD then calls AutoLISP back, and AutoLISP resumes evaluation of the expression in progress. In contrast, the command function remains a "co-routine" execution of the supplied command tokens, where AutoLISP evaluates the tokens one at a time, sending the result to AutoCAD, and then returning to allow AutoCAD to process that token.
The command that is being executed must be started and completed in the same command-s function. In this form, AutoCAD is directly called from AutoLISP, processes the supplied command tokens in a temporary command processor distinct from the main document command processor, and then returns, thus terminating the temporary command processor. The "-s" suffix stands for "subroutine" execution of the supplied command tokens.
0 kommentar(er)
