Tough Questions - OSNAP Lisp
Tough Questions - OSNAP LispAutoCAD 2007
I have a quite a few tough questions/requests and I am currently looking for some lisps to solve them.I have been doing some searching online to find the lisps I need, and although I have been able to find some stuff, I still have some things that I can't seem to find exactly what I am looking for.I would like to take the opportunity ahead of time to thank every who views my questions and for any help that is given.
When using lisps I am finding that many of them reset my OSNAP settings, I was wondering if there was a way or a lisp that can be used to keep my OSNAP setting.So far the only thing I have found is the variable "OSMODE" which has a numerical setting based on the snaps set. The fact that they reset your osnaps is merely that the LISP is badly written, not the downside of LISP itself.
Thanks Lee.I was going to post something very similar.Good programmers will reset any variables or settings that are changed for the sake of the functionality of the LISP routine. I agree with Lee, however if it's a bug in autocad, not lisp, we noticed something similar with the auto savetime settings, so I've modified this lisp we found to work for osnap settings, see what you think. Set the value of the red highlight to the osnap setting you usually use:
(not tested & not recommended)
(defun C:ALERTME ()(vl-load-com)(setq VTFRXN (vlr-editor-reactor nil '((:VLR-sysVarChanged . VTF)))))(defun VTF (CALL CALLBACK / str val)(setq val 39)(if (and(= (strcase (car CALLBACK)) (setq str "OSMODE"))(eq (getvar str) 0))(progn(princ (strcat "Warning: Someone or something has changed your " str " settings.\n" str " has been changed back to " (itoa val)))(setvar str val))))(c:alertme) Nice one Steve,
I would include a function like this to remove reactor also though!
(defun c:rem_reac ( ) (and VTFRXN (vlr-remove VTFRXN)) (setq VTFRXN nil) (princ)) True, good thing to add. I didn't write it, someone at work found it (hopefully they didn't remove a copyright)
John, it's not recommended because it could conflict if you have lisps that modify the OSMODE settings. But we are all just talking to ourselves aren't we...
John, it is common courtesy to reply to threads that you start.
Tough Questions - Part 1
Tough Questions - Part 2
Tough Questions - Part 3
1 year ago!... and still no reply...
A "user" me thinks. Many routines start off by SAVING your current OSMODE setting prior to changing it then resetting it back after the routine completes.
Just make sure your error trapping does the same if the routine is cancelled.
If you're trying to learn (like me!) Post the problem routine and the code masters
will not only show you how to fix it, you'll learn what to look for in bad coding as well!! I've found the reactors for resetting the osmode to be quite annoying and it's not that difficult to code your *error* sub to reset everything accordingly.
For example:
(defun c:TEst (/ *error* #Osmode #Pnt1 #Pnt2);;; error handler (defun *error* (#Message) (and #Osmode (setvar 'osmode #Osmode)) (and #Message (not (wcmatch (strcase #Message) "*BREAK*,*CANCEL*,*QUIT*")) (princ (strcat "\nError: " #Message)) ) ;_ and ) ;_ defun (setq #Osmode (getvar 'osmode)) (setvar 'osmode 4105) (and (setq #Pnt1 (getpoint "\nSpecify first point: ")) (setq #Pnt2 (getpoint #Pnt1 "\nSpecity next point: ")) (command "_.line" "_non" #Pnt1 "_non" #Pnt2 "") ) ;_ and (and #Osmode (setvar 'osmode #Osmode)) ;; or you can type: (*error* nil) (princ)) ;_ defun
页:
[1]
2