Author Topic: Remembering Previous Entries  (Read 4260 times)

0 Members and 1 Guest are viewing this topic.

CADaver

  • Guest
Remembering Previous Entries
« on: August 03, 2004, 09:43:42 AM »
I know it was posted here a while back, but I've spent the morning looking and haven't found it yet, so I'm just gonna ask.  What's the "best way to remember previous variable entries for recall in susequent uses of the function?  Example:
Code: [Select]
(setq frad 0)
(defun C:FR ()
    (IF (SETQ NFRAD (GETDIST (STRCAT "Enter Fillet Radius <" (RTOS FRAD) ">: ")))
(SETQ FRAD NFRAD))
    (command ".FILLET" "R" FRAD)
    (command ".FILLET")
)


I've been doing it like this for quite a while and it works, but seems heavy-handed to  me.  I'm quite sure one of you gurus can produce something considerably more elegant.

EDITTED to use the "right" function, just noticed I pasted something from a work in progress instead of the one I've been using.

Mark

  • Custom Title
  • Seagull
  • Posts: 28762
Remembering Previous Entries
« Reply #1 on: August 03, 2004, 10:20:39 AM »
How about this;
Code: [Select]

(defun C:FR (/ erad frad)

(setq erad (getvar 'filletrad))

(if (not
 (setq
frad
(getdist
  (strcat "Enter Fillet Radius <" (rtos erad) ">: ")
  )
)
 )
 (setq frad erad)
 )

(command ".FILLET" "R" frad)
(command ".FILLET")
)
TheSwamp.org  (serving the CAD community since 2003)

CADaver

  • Guest
Remembering Previous Entries
« Reply #2 on: August 03, 2004, 10:31:13 AM »
Quote from: Mark Thomas
How about this;
Code: [Select]

(defun C:FR (/ erad frad)

(setq erad (getvar 'filletrad))

(if (not
 (setq
frad
(getdist
  (strcat "Enter Fillet Radius <" (rtos erad) ">: ")
  )
)
 )
 (setq frad erad)
 )

(command ".FILLET" "R" frad)
(command ".FILLET")
)


hmmm... that uses the setvar "filletrad" doesn't it?  I'd like something that remembers the setting independent of the setvar. That way the function I have that fillets rad 0 won't change the "FRAD" variable in this routine.  If I'm reading this right.

I just noticed I had pasted the wrong routine into the original post, I'm gettin' too old fer this stuff.

Mark

  • Custom Title
  • Seagull
  • Posts: 28762
Remembering Previous Entries
« Reply #3 on: August 03, 2004, 10:36:46 AM »
Ohhhhhhh I see were you're headed now. Let's try another approach then.
TheSwamp.org  (serving the CAD community since 2003)

Mark

  • Custom Title
  • Seagull
  • Posts: 28762
Remembering Previous Entries
« Reply #4 on: August 03, 2004, 10:53:02 AM »
How about using a environment variable. like so;
Code: [Select]

(defun C:FR (/ erad frad)
 
  (if (not (getenv "frad"))
(setenv "frad" "6.0")
)

(setq erad (getenv "frad"))

(if (not
 (setq
frad
(getdist
  (strcat "Enter Fillet Radius <" erad ">: ")
  )
)
 )
 (setq frad (atof erad))
 (setenv "frad" (rtos frad))
 )

(command ".FILLET" "R" frad)
(command ".FILLET")
)
TheSwamp.org  (serving the CAD community since 2003)

hendie

  • Guest
Remembering Previous Entries
« Reply #5 on: August 03, 2004, 10:53:47 AM »
what about setcfg & getcfg

CADaver

  • Guest
Remembering Previous Entries
« Reply #6 on: August 03, 2004, 05:53:52 PM »
Quote from: Mark Thomas
How about using a environment variable. like so;
Code: [Select]

(defun C:FR (/ erad frad)
 
  (if (not (getenv "frad"))
(setenv "frad" "6.0")
)

(setq erad (getenv "frad"))

(if (not
 (setq
frad
(getdist
  (strcat "Enter Fillet Radius <" erad ">: ")
  )
)
 )
 (setq frad (atof erad))
 (setenv "frad" (rtos frad))
 )

(command ".FILLET" "R" frad)
(command ".FILLET")
)


this is interesting, though I choked on it a couple of times before I snapped that the setenv requires a string. I know environment vars have been around a while, but I've always avoided diddling with them out of abject fear, so I have a couple questions about them:
1.) Is there any "real" reason to be concerned?
2.) What are the possible pitfalls, and how may they be avoided?
3.) Is there a maximum number of "variables" that can be stored with "SETENV"?
4.) How big a hole can I shoot through my foot using them as global variable sets?
5.) How many folks use them like above? All okay?

This may be a real asset for my limited programming skills.

sinc

  • Guest
Remembering Previous Entries
« Reply #7 on: August 04, 2004, 12:25:06 AM »
Here's some general rules-of-thumb on the variable types and when to use each:

Local Variables
Most-commonly used type, but only stick around for the length of the routine.  Released when the function ends.

Global Variables
Stick around after the function ends, and visible to everyone.  As such, using them can result in inconsistent buggy behavior, since any other routine can clobber the variable (set it to some value that your routine doesn't expect and possibly can't handle).  Should therefore be used sparingly.  There are some valid uses, but not many.  (In VLisp, global variables should have names that begin and end with an asterisk, as in *myglobal*.)

Drawing Variables
Variables stored in a dictionary in the drawing, either as a global dictionary or hooked to an object in the drawing.  These variables are saved with the drawing, and are therefore drawing-specific.  For example, the layer manager saves layer states in a dictionary attatched to the Layers collection.

Application Variables
Application-specific variables - i.e., variables specific to a routine.  (In this context, you can think of any custom function you write as an "application".)  Variables stored here are not drawing-specific; they retain their current value even if you close the current drawing and open another one.  These variables are stored in the acad.cfg file, so they are remembered even if the Autocad session is terminated and restarted.  These variables are accessed with the setcfg and getcfg functions.  Since they are stored in the acad.cfg file, they should follow the naming conventions in the documentation to avoid conflicts with other programs/routines.

Environment Variables
Variables that affect the way a program runs.  Accessed with getenv and setenv.  You can also think of these as "startup configuration variables".  Most commonly, these variables are used to specify important facts about the user's specific environment, such as path information, language settings, editor preferences, web browser preference, etc.  Autocad uses them to store the default hatch and linetype definition filenames and a few other things.  The documentation warns that once you change the value of an environment variable with setenv, you should not count on getenv returning the correct value until the next time you start Autocad.  These variables are stored in the Windows registry, and as such may also be changed from outside Autocad.