Altering a savetime LISP

[CCarleton]

Hello all,

To start off here is the original code

{code}
(defun C:ALERTME ()
(vl-load-com)
(setq VTFRXN (vlr-editor-reactor nil '((:VLR-sysVarChanged . VTF))))
)


(defun VTF (CALL CALLBACK)
(if (and
(= (strcase (car CALLBACK)) (setq str "SAVETIME"))
(not (eq (getvar str) 40))
)
(progn
(princ (strcat "Warning: Someone or something has changed your Autosave settings.\n" str " has been changed back to 40 minutes"))
(setvar "SAVETIME" 40)
)
)
)
(setvar "SAVETIME" 40)
(c:alertme)
{code}

I found this routine a very long time ago to counter CAD's desire to sometimes turn off automatic save (and you never knew until it was too late). It works great, just as advertised it will always turn the savetime back to whatever value you have it set to.

Well, another variable that likes to change on me is the pickfirst variable. It just likes to set itself to 0 from time to time, and it's annoying. So I was like "Well, theoretically I should be able to duplicate it..." and I went on my way. Turns out I was right, it wasn't hard at all...however getting it to place nicely with the savetime variable is an entirely other matter. I basically tried to update all the variables to be a similar format, but different definitions and couldn't get them to cooperate.

Anyone know how to go about doing that?

Thanks

[Tom Beauford]

You could enter SAVETIME 40 PICKFIRST 1 at the command line or in a macro. Try adding these two lines to your acaddoc.lsp file so they will be set correctly each time you open a drawing:

(if (/= (getvar 'pickfirst) 1)(progn(setvar 'pickfirst 1)(princ "\nPick before command. PICKFIRST")))
(if (/= (getvar 'savetime) 40)(progn(setvar 'savetime" 15)(princ "\nAutosave every 40 minutes.")))

The cause of these issues is poorly written code. Search all your code for those variables and debug them.

[CCarleton]

Hi Tom, I see you're coming to my rescue again!

You could enter SAVETIME 40 PICKFIRST 1 at the command line or in a macro

Well in regards to savetime it's one of those things that you don't pay attention to until it crashes so that doesn't really do me any good. That code I linked does the job perfectly for making sure my savetime variable never changes. Whenever the pickfirst variable changes I already just type in pickfirst, see it's set to zero, and set it back to one. Could also macro it I suppose, but the point of making this routine is so that it never changes from one because I have never had that desire and I don't really want to personally mess with it.

The savetime routine that I linked is actually a bit above me, but I get the jist of how it's doing what it's doing. I just figured that if I slightly tweaked every variable and the defined function that it should, in theory, work without upsetting the savetime routine and at the end of the day that's all I really want.

Try adding these two lines to your acaddoc.lsp file so they will be set correctly each time you open a drawing

I mean I know I could just create a very simple line in the file that says (setvar "pickfirst" 1) and every time I opened the drawing it would do that, but if it changes midway it doesn't do me any good. And testing your pickfirst line of code it doesn't seem to do anything but immediately set it to 1 upon loading.

The cause of these issues is poorly written code. Search all your code for those variables and debug them.

I can assure you there is nothing in my entire LISP routine that even mentions the pickfirst variable or am I just misunderstanding ? The only variables my routines ever alter are the clayer, plinewid, and plinegen. Additionally they are all set up to reset upon exiting the command regardless of whether you press escape or hit return. Or are you saying that the way I've coded some of my routines (as admittedly I am very much a newbie in the grand scheme of LISP) could be affecting the pickfirst variable even though I never use it in said routines? Because that would be pretty depressing.

I do get the concept of what you're saying though, computers don't do things just because they feel like it, or in this case alter variables, but in my experience CAD has been an exception to that rule.

[Tom Beauford]

I modified your code to include pickfirst, but leave the other code earlier in acaddoc.lsp to make sure they're set correctly on open:

(defun VTF (CALL CALLBACK)
  (if (and(= (strcase (car CALLBACK)) (setq str "SAVETIME"))(not (eq (getvar str) 40)))
    (progn
      ;(alert (strcat "Warning: "\"SAVETIME\" has been set to " (itoa(getvar "SAVETIME")) " reset it to 40 minutes."))
      (princ (strcat "Warning: Someone or something has changed your Autosave settings.\n" str " has been changed back to 40 minutes"))
      (setvar "SAVETIME" 40)
    )
  )
  (if (and(= (strcase (car CALLBACK)) (setq str "PICKFIRST"))(not (eq (getvar str) 1)))
    (progn
      ;(alert (strcat "Warning: "\"PICKFIRST\" has been set to " (itoa(getvar "SAVETIME")) " reset it to 15 minutes."))
      (princ (strcat "Warning: Someone or something has changed your PICKFIRST settings.\n" str " has been changed back to 1"))
      (setvar "PICKFIRST" 1)
    )
  )
)
(c:alertme)

Both system variables are stored in the Registry, but you can't be to safe.

[CCarleton]

Interesting, that works, and it looks like I could expand on that with other variables if I ever wanted/needed to.

I am a bit confused though...

(setq str "SAVETIME")
(setq str "PICKFIRST")

Isn't setq used to create variables, and in this case a variable named str that you've created twice but with different variable values which should screw it up? But both are reset when I tested it so it works. When I first attempted to tackle this myself I did a save as and just changed all the information to pickfirst and updated the variable from 40 to 1. Then, the way I saw it, I was creating a a variable named VTFRXN twice, function called VTF twice, and a variable called str twice and when I tried to run both at the same time it was failing so I assumed I was on the right track, and that if I changed the variable names in the pickfirst routine everything would be good to go and that since they're just variable names I could call them whatever I wanted. Alas as I said in my original post this didn't' work.

Unfortunately the bigger snaffu is I wanted these to be separate files if they can be. I'm throwing these up on our server and someone may be weird and like pickfirst being set to 0 so I don't want it to be tied with the savetime routine. I have a master routine that contains the vast bulk of what people want to use, but then I have a few other more personal choice routines that people can choose to load or not.

I appreciate your help Tom

Thanks

[Tom Beauford]

The reactor in C:ALERTME runs VTF any time a sysVar is Changed. Then VTF checks and resets if necessary first SAVETIME then PICKFIRST. You can do this with as many variables as you like. Keep an eye on the command line for the "Warning…" messages so you will know what action caused the change to these variables. In the 22 years I've been using AutoCAD they've never changed on me. Something you're using is causing the change and the reactor may affect how that code works. It's hard to imagine anyone wanting PICKFIRST set to 0 though.

[CCarleton]

The reactor in C:ALERTME runs VTF any time a sysVar is Changed. Then VTF checks and resets if necessary first SAVETIME then PICKFIRST. You can do this with as many variables as you like.

It's funny since when I first got the routine I just copied it, confirmed it worked, and went on with my life. Now that I've been trying to alter it (and I've been playing with traps for variables in other commands) it looks like to me that it's a three part LISP (although the way it closes arguments does still slightly confuse me).

I see what you're saying doing with adding the variables and therefore able to be endless though. That may be the way to go, but again I am curious to know if there's a way to separate them if I wanted to, forget the logic (or lack of it) if that helps as my next plan of attack is to try to split the original routine so that you load the "master" one, and then mix/match the variables you want to never change that is controlled by that "master" routine.

Keep an eye on the command line for the "Warning…" messages so you will know what action caused the change to these variables.

I'm curious to know if you can change it to be an alert? I never look at my command line so I'm never going to notice it. I tried to do it once upon a time because I had the same thought about looking for why it's changing, but I couldn't get it to become an alert even though I feel that shouldn't be too difficult to do...

In the 22 years I've been using AutoCAD they've never changed on me. Something you're using is causing the change and the reactor may affect how that code works.

I've done some googling around about it and I find people talking about variables changing on them too so I know I'm not alone in it, but yeah I get what you're saying. I consider myself moderately computer savvy, and it drives me bonkers to know that there should be something that's doing it, but I've never found the rhyme or reason. I've also been through several computers and I've recently started a new job and the problem seems to follow (and up until about a month ago I wasn't using any lisps) so I'm really having a hard time believing it's a PEBKAC.

It's hard to imagine anyone wanting PICKFIRST set to 0 though.

Yeah I can't either, I just sort of envision being able to make multiple/separate routines where people could load what they like because I know some people are really finnicky about their setup, and so if the routine isn't doing something that increases productivity I don't want to force people into using it. The reason this savetime routine isn't in my master routine is because one guy I talked to said he hates autosave, doesn't use it, and instead just saves a lot more frequently. Another guy asked about why 'off' no longer used the offset command which was because I wrote a simple macro for locking/unlocking VPs using 'on' or 'off' and despite 'o' being a default CAD command for offset.

At least he was a good sport about it when I pranked him by remacroing 'off' to alert with the message "STOP IT"...

Again, thanks for the help. Given me a lot to play with.

[rkmcswain]

As far as I know, the credit for that code goes to Peter Jamtgaard.
I used it in this blog post from 2007.

[Tom Beauford]

I see what you're saying doing with adding the variables and therefore able to be endless though. That may be the way to go, but again I am curious to know if there's a way to separate them if I wanted to, forget the logic (or lack of it) if that helps as my next plan of attack is to try to split the original routine so that you load the "master" one, and then mix/match the variables you want to never change that is controlled by that "master" routine.

Keep in mind it's two things the reactor C:ALERTME and function VTF. To separate them you would need a reactor and a function for each.

I'm curious to know if you can change it to be an alert? I never look at my command line so I'm never going to notice it. I tried to do it once upon a time because I had the same thought about looking for why it's changing, but I couldn't get it to become an alert even though I feel that shouldn't be too difficult to do...

Reactors don't allow interruptions, but I had to try. Hoped that would make it easy to see what changed the system variable.

Yeah I can't either, I just sort of envision being able to make multiple/separate routines where people could load what they like because I know some people are really finnicky about their setup, and so if the routine isn't doing something that increases productivity I don't want to force people into using it. The reason this savetime routine isn't in my master routine is because one guy I talked to said he hates autosave, doesn't use it, and instead just saves a lot more frequently.

Since Autosave counts the minutes from the last save it should never be an issue for him. The initial setting is 10 minutes, a lot can happen in 40 minutes.

Another guy asked about why 'off' no longer used the offset command which was because I wrote a simple macro for locking/unlocking VPs using 'on' or 'off' and despite 'o' being a default CAD command for offset.

Even with the viewport on a frozen layer you can toggle VP locking by clicking a button on the status bar.

[Tom Beauford]

As far as I know, the credit for that code goes to Peter Jamtgaard.
I used it in this blog post from 2007.

Thanks, thought that code looked familiar. Always helpful to know where it came from. So alert does work, Cool! This should help you track down what's changing those system variables:

 ;Reactor by: Peter Jamtgaard
(defun C:ALERTME ()
(vl-load-com)
(setq VTFRXN (vlr-editor-reactor nil '((:VLR-sysVarChanged . VTF))))
)


(defun VTF (CALL CALLBACK)
  (if (and(= (strcase (car CALLBACK)) (setq str "SAVETIME"))(not (eq (getvar str) 15)))
    (progn
      (alert (strcat str " was changed and reset"))
      (setvar "SAVETIME" 15)
      (princ)
    )
  )
  (if (and(= (strcase (car CALLBACK)) (setq str "PICKFIRST"))(not (eq (getvar str) 1)))
    (progn
      (alert (strcat str " was changed and reset"))
      (setvar "PICKFIRST" 1)
      (princ)
    )
  )
)
(c:alertme)