Executes an AutoCAD command and the supplied input
(command-s [cmdname [arguments ...]])
The arguments to the command function can be strings, reals, integers, or points, as expected by the prompt sequence of the executed command. A null string ("") is equivalent to pressing Enter on the keyboard.
Command: (command-s "_circle" "5,4" "_d" 2.75) nil
Command: (setq cPt (getpoint "\nSpecify center point: ")) (5.0 4.0 0.0) Command: (command-s "_.circle" cPt "_d" 2.75) nil
Command: (command-s "_.circle" (getpoint "\nSpecify center point: ") "_d" 2.75)
The command-s function is a variation of the command function which has some restrictions on command token content, but is both faster than command and can be used in *error* handlers due to internal logic differences.
A command token is a single argument provided to the command-s function. This could be a string, real, integer, point, entity name, list, and so on. The following example shows the AutoCAD LINE command and three command tokens:
(command-s "_line" "0,0" "5,7" "")
The "-s" suffix stands for "subroutine" execution of the supplied command tokens. 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 command that is being executed must be started and completed in the same command-s function.
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. AutoCAD then calls AutoLISP back, and AutoLISP resumes evaluation of the expression in progress. In this logic flow, subsequent token expressions can query AutoCAD for the results of previous token processing and use it.
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. 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. For the same set of command tokens, command-s function is significantly faster.
(command-s "_line") (command-s "2,2" "12.25,9" "")
(command-s "_line" "0,0" PAUSE "")
For typical *error* handler cases where the previous state of the program needs to be restored and a few batch commands are executed, you can substitute (command-s <...>) for (command <...>). The *error* handler is called from the same context as it always has been.
(defun my_err(s) (prompt "\nERROR: mycmd failed or was cancelled") (setvar "clayer" old_clayer) (command-s "_.UNDO" "_E") (setq *error* mv_oer) ) (defun c:mycmd () (setq old_err *error* *error* my_err old_clayer (getvar "clayer") ) (setq insPt (getpoint "\nSpecify text insertion: ")) (if (/= insPt nil) (progn (command-s "_.UNDO" "_BE") (command-s "-_LAYER" "_M" "Text" "_C" "3" "" "") (command-s "_-TEXT" insPt "" "0" "Sample Text") (command-s "_.UNDO" "_E") ) ) (setvar "clayer" old_clayer) (setq *error* mv_oer) (princ) )
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.
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.