Command in silent mode

[nn.araujo]

Hello,

I want to use AutoCAD commands, like (command "line" "1,2" "3,4" ""), in my lisp routines but in silent mode. Is possible to do it with no printing in the command line?

Thanks

Nuno

[hgasty1001]

(setvar "CMDECHO" 0)

[wkiernan]

Don't forget to set OSMODE to zero, or else you will probably get bogus results from AutoCAD commands called by (command "line" ...).

[pbejse]

if its only two points you could do this:

(command "_.line" "_none" "1,2" "_none" "3,4" "")

 that way you dont need to switch back to the previous osmode settings

[nn.araujo · Accepted solution]

Hello

Since I use several AutoCAD commands (not only “line”) I decided to change “osmode” and “cmdecho”.

This is the solution I implemented:

;Commands in silent mode.

(setq oldosmode (getvar "osmode"))

(setq oldcmdecho (getvar "cmdecho"))

(setvar "osmode" 0)

(setvar "cmdecho" 0)

(code)

;Reset to original "osmode" and "cmdecho".

(setvar "osmode" oldosmode)

(setvar "cmdecho" oldcmdecho)

Thank you all

Nuno

[petervose]

I find that using 'vl-cmdf' iinstead of 'command' seems to get rid of some of the command echo's... 

 eg. (vl-cmdf "line" '(0 0 0) '(25 45 0) "")

[Kent1Cooper]

---

@petervose wrote:

I find that using 'vl-cmdf' iinstead of 'command' seems to get rid of some of the command echo's... 

 eg. (vl-cmdf "line" '(0 0 0) '(25 45 0) "")

---

Not for me back here in Acad2004, at least not in that example [it may in other commands, though I can't imagine what the distinction would be].  The only difference is that doing that with (command) returns nil afterwards, but doing it with (vl-cmdf) returns T.  When User input is involved, the sequence of prompts and echoes may differ [see Help for (vl-cmdf)].  Setting CMDECHO to 0 suppresses the echos when using either function, but with it set to 1, command prompts are echoed under both functions.

[lgabriel]

I write a lot of AutoLisp programs so I created functions called echooff and echoon and added it to my acad2010.lsp program so these functions are automatically loaded when opening any drawing

(defun echooff ()
  (setq oldecho (getvar "CMDECHO"))
  (setq oldblip (getvar "BLIPMODE"))
  (setq oldosm (getvar "OSMODE"))
  (setvar "CMDECHO" 0)
  (setvar "BLIPMODE" 0)
  (setvar "OSMODE" 0)
  (setq olderror_echo *ERROR*)
  (terpri)
  (defun *ERROR* (msg)
    (princ " \n")
    (princ msg)
    (echoon)
  )
)
(defun echoon ()
  (setvar "CMDECHO" oldecho)
  (setvar "BLIPMODE" oldblip)
  (setvar "OSMODE" oldosm)
  (setq *ERROR* olderror_echo)
  (princ)
)

In the main body of any AutoLisp program, add the functions at the beginning and end of the program. Much easier than writing nine lines of code in every AutoLisp program

;AUTOSUM.lsp
;
;object: to sum the distances a series of points
;
(defun c:autosum()
   (echooff)
   (setq sum 0)
   (setq scn (cdr(assoc 1 (entget(car(entsel)))))) 
   (setq pt1 (getpoint "\nSelect starting point: "))
   (while (/= (setq pt2 (getpoint pt1 "\nSelect next point (Press ENTER to quit): ")) nil)
      (setq sum (+ sum (distance pt1 pt2)))
      (setq pt1 pt2)
   )
   (alert (strcat "Total length in feet is for " scn " : " (rtos (+ 105.0 (/ sum 12.0))) " feet"))
   (echoon)
)

[Kent1Cooper]

I highly recommend the approach described in Message 2 of this thread:

http://forums.autodesk.com/t5/Visual-LISP-AutoLISP-and-General/error-question-localizing-the-error-h...

With that and a couple of other little refinements, your functions could be streamlined a little, mostly by eliminating the saving and resetting of the current *error* handler:

(defun echooff ()
  (setq ; <------consolidated into one

    oldecho (getvar "CMDECHO")
    oldblip (getvar "BLIPMODE")
    oldosm (getvar "OSMODE")

  )
  (setvar "CMDECHO" 0)
  (setvar "BLIPMODE" 0)
  (setvar "OSMODE" 0)
  (defun *error* (msg); <------removed saving of current error handler [and (terpri)]
    (princ " \n")
    (princ msg)
    (echoon)
  )
)

 
(defun echoon ()
  (setvar "CMDECHO" oldecho)
  (setvar "BLIPMODE" oldblip)
  (setvar "OSMODE" oldosm)
  (princ); <------removed resetting of old error handler
)

;AUTOSUM.lsp
(defun c:autosum (/ *error* ...); <-----added *error* as localized variable
   (echooff)
....

   (echoon)
)

However, I do find there are often reasons to have individual *error* definitions in most routines.  Some routines change the UCS and possibly even the UCSFOLLOW System Variable, and need *error* to change them back; some change the current Layer, or unlock locked ones, or something; some don't have any reason to change BLIPMODE and/or OSMODE; some change CMDECHO, but not at the beginning of the routine, because some command in which command echoing is needed for User input occurs before others in which it needs to be turned off; etc., etc.  But if you have enough routines that need exactly the same combination of settings/resettings, you can certainly have a shared routine used in all of those, and only do something more or less, independently, in routines for which that's appropriate.

[lgabriel]

I agree with you Kent. A good programmer will always save current settings before changing them in his program and then return them to their orignal settings. To often I see Autolisp programs that change system variables and then the user wonders what happened.

The code I posted covers common system variables. If there are any system variables that I have to change in a single Autolisp program, I will add the neccessary code to that program.

Thanks for the compliment.

[wkiernan]

Kent: The only downside to this is that you load the library functions in a different file from the application program, so then one of your coworkers says "how do you do such-and-such?" and you reply "o I gotta lil program that does it, here I'll email it to you," and then they get the email and run the attachment which promptly issues:

error: no function definition: ECHOOFF

and then they're all "woah that's screwed up, that guy's _weird_" but after all, f___ 'em anyway, let them write their own stuff, or at least RTFM.