TheSwamp
Code Red => AutoLISP (Vanilla / Visual) => Topic started by: Brick_top on November 23, 2011, 06:48:33 AM
-
Hi there,
I would like to set new variables in a file I open with a routine.
I know I can "copy" variables from a drawing to another using vl-propagate. But how do I create new ones?
And how do I propagate more than one variable? vl-propagate only seems to propagate one variable?
thanks.
-
(setq a 1
b 2
c 3
)
(mapcar (function vl-propagate) '(a b c))
-
Nice! thanks a lot!
-
(foreach sym '(a b c) (vl-propagate sym))
-
how about the other question? in case I explained my self correctly
thanks for the alternative lee
-
Creating a new variable:
(setq a 1)
-
lets see if I can explain my self better.
I have a routine I run in a drawing.
That routine opens another drawing, and now I want to set new variables in that drawing.
-
That routine opens another drawing, and now I want to set new variables in that drawing.
Set the variables in the active drawing and propagate them?
-
If you do not have a large amount of data you can use the setenv/getenv
-
That routine opens another drawing, and now I want to set new variables in that drawing.
Set the variables in the active drawing and propagate them?
Well in the way I'm seeing things right now I don't know how to do that because of what I want to do because there are variables that need to be set differently in the "other" drawing.
What I want to do is save notes in each drawing (as xrecords) I have and then have a "master" drawing with all the notes so I can later search all the notes of all the projects. Problem is the xrecord "name?" is diferent in the master drawing.
For example I name the notes in all the projects as "Note 1" "Note 2" "Note 3" etc.. every project will start in number 1. But the "master" drawing where I'll have all the notes stored will only have one "Note 1".
-
I need to check the xrecords in the "opened by the routine" file to set the new name of the next xrecord.
At least this is what I'm thinking
-
This is what I'm doing to check the number of the note, and set the number of the next one.
(setq a (mapcar 'cdr (vl-remove-if-not '(lambda (x) (= 3 (car x)))(entget (namedobjdict))))
b (vl-remove-if-not '(lambda (x) (= "Nota" (substr x 1 4))) a)
titl2 (strcat "Nota" " " (itoa (+ 1 (length b))))
);setq
-
I gave up the ideia, I just run another routine in the opened file to set the new variables.
-
I have an idea, DBX or vl-propagate + s::startup
-
will the s::startup function define functions for every drawing?
-
Hi,
It's a bit late, but I have a routine that also opens a new drawing from another and I found that (vl-bb-set/ref) is a much better option. Vl-propogate dumps global variables in the new drawing which may cause problems. I'm also under the impression that you can't access vl-propogate variables until after the S::STARTUP has finished.
Have a good one.
Shawndoe
-
I use vl-registry-write and vl-registry-read.
Example: setting globals for dialog box controls.
(defun ARCH:SETDIALMODE (key /)
(vl-registry-write
"HKEY_CURRENT_USER\\Software\\Arch Program\\Controls\\Dialog\\Display"
""
key)
(setq ARCH#DIAL
(vl-registry-read
"HKEY_CURRENT_USER\\Software\\Arch Program\\Controls\\Dialog\\Display"))
(princ))
-
setcfg / getcfg 8-)
-
8-)
FTFY :wink:
** Note - the LISP functions are now hyperlinked to the help documentation.
-
I quit using setcfg and getcfg some years ago after I realized that it was causing the config file to grow and you have to manually remove orphaned entries.
Use the registry and then you can programmatically delete the keys after you no longer need them.
-
I quit using setcfg and getcfg some years ago after I realized that it was causing the config file to grow and you have to manually remove orphaned entries.
Use the registry and then you can programmatically delete the keys after you no longer need them.
The registry is a great option also.
As long as you keep reusing the same cfg there is no issue with file bloat. Just another way. :kewl:
(i.e. "AppData/Vars/var1")
There are also the setenv / getenv variables.
*This was for you RenderMan :angel:
All great options as long as the limitations are taken into account.
-
There are also the setenv / getenv variables.
*This was for you RenderMan :angel:
:-P