Using COND Statements

[stusic]

I'm excited about learning what I have, and am getting moreso thinking of what I can do next. Going further with the code we were working with earlier (http://forums.augi.com/showthread.php?t=79752), I'd like to add a COND statement to change the current layer depending on user input.

I've looked at Afralisp, and while it's a great resource, it's hard to get clarification if you need it. From there, this is what I have, but it won't accept any input, getting the "Invalid option keyword." error.

Any ideas?



(defun c:bbn (/ ss j mode oldclay olderr tt)

(setq oldclay (getvar "clayer")); record current layer
(setvar "cmdecho" 0)
(command "undo" "be")

;Error Trapping
(setq olderr *error*); save copy of ACAD error
(defun *error* (msg)
(if (= msg "Function cancelled"); user presses escape
(princ); do nothing
(princ (strcat "Error: " str)); print error string
); if
(command "undo" "e")
(setvar "cmdecho" 1)
(setvar "highlight" 1)
); end of error

;user prompt
(setq tt (getkword "Choose tendon type: Band , Uniform [U], Beam [M]"))

(strcase tt)

(cond

((= tt "B") (COMMAND "-LAYER" "M" "BAND" ""))

((= tt "BAND") (COMMAND "-LAYER" "M" "BAND" ""))

((= tt "U") (COMMAND "-LAYER" "M" "UNIFORM" ""))

((= tt "UNIFORM") (COMMAND "-LAYER" "M" "UNIFORM" ""))

((= tt "M") (COMMAND "-LAYER" "M" "BEAM" ""))

((= tt "BEAM") (COMMAND "-LAYER" "M" "BEAM" ""))

(t (princ "\nUnknown Tendon Type"))

)

(COMMAND "-INSERT" "f:/apps/CCS_CAD/LABEL/1TEN_L" "S" "96" PAUSE PAUSE)
(COMMAND "EXPLODE" "L")
(COMMAND "CHPROP" "L" "P" "" "LA" (getvar "clayer") "")

(setq ss (ssadd))
(ssadd (entlast) ss)
(setq mode 0)
(setvar "highlight" 0)
(setq j (bns_trot ss mode))

(setvar "highlight" 1)
(setq *error* olderr); set back to ACAD error
(setvar "clayer" oldclay); restore previous layer
(command "undo" "e")
(setvar "cmdecho" 1)

(princ)
);defun


Thanks all!

[T.Willey]

The problem isn't the 'cond', it is the way you use 'getkword'. When using 'getkword' you want to use 'initget' so that you can supply a list of what you want the answer to be.



(initget "Band Uniform beaM")
(setq tt (getkword "\n Choose tendon type [Band/Uniform/beaM]: "))
(cond
((= tt "Band"))
(command "_.layer" "_m" "BAND" "")
)
((= tt "Uniform"))
(command "_.layer" "_m" "UNIFORM" "")
)
((= tt "beaM"))
(command "_.layer" "_m" "BEAM" "")
)
)

Notice that how you supply the strings to 'initget' is how 'getkword' will return the strings. If the layer names are going to be the same name as the option you select, then you don't need the 'cond', you can just use what is returned by 'getkword' to name the layer. Such as



(command "_.layer" "_m" (strcase tt) "")


Hope the explains it a little.

[jmcshane]

Sorry to jump in, but just to point out that because Tim used the square brackets,
the choices will now appear whenever you right click for the short cut menu.

Nice one Tim.




(setq tt (getkword "\n Choose tendon type [Band/Uniform/beaM]: "))

[stusic]

The problem isn't the 'cond', it is the way you use 'getkword'. When using 'getkword' you want to use 'initget' so that you can supply a list of what you want the answer to be.


...
Notice that how you supply the strings to 'initget' is how 'getkword' will return the strings.

Ah, it comes together now....


If the layer names are going to be the same name as the option you select, then you don't need the 'cond', you can just use what is returned by 'getkword' to name the layer. Such as



(command "_.layer" "_m" (strcase tt) "")
Hope the explains it a little.

It wasn't until I read this that I realized the choices don't match the layer names (beam are actually on the "beam_tendon" layer), but that's really neat (and much easier).

Thanks a bunch! :beer:

[T.Willey]

Sorry to jump in, but just to point out that because Tim used the square brackets,
the choices will now appear whenever you right click for the short cut menu.

Nice one Tim.

Thanks. Picked that one up a while ago, six months or so, and haven't looked back since.


Ah, it comes together now....
It wasn't until I read this that I realized the choices don't match the layer names (beam are actually on the "beam_tendon" layer), but that's really neat (and much easier).

Thanks a bunch! :beer:

Glad to have been able to help, and even glader (not really a word, but who cares) that you have learned something. You're welcome.

[stusic]

Not a big deal, but is there a way to keep the last choice as the default for the next time it's used, so they can just hit Enter if they're using the same option?

Man, I wouldn't get anything done if I didn't have help from here... ;)

[d_m_hopper]

Notice that how you supply the strings to 'initget' is how 'getkword' will return the strings. If the layer names are going to be the same name as the option you select, then you don't need the 'cond', you can just use what is returned by 'getkword' to name the layer. Such as



(command "_.layer" "_m" (strcase tt) "")


Hope the explains it a little.

I like that ^^^ thanks for sharing

[stusic]

Thanks. Picked that one up a while ago, six months or so, and haven't looked back since.



Glad to have been able to help, and even glader (not really a word, but who cares) that you have learned something. You're welcome.

I love that feeling of "Aha! Now I get it!".. :)

[T.Willey]

To do something like that, you would use a global variable. Most of the time you don't want these, but once in awhile they are helpful. You may want to name the global variable something that won't be common, as you wouldn't want it to be changed to anything but what you want it to be. I prefix mine with 'GlbVar' and then write out the name. So for yours I would use something like 'GlbVarLayerNameOption'. With that said, here is how I would do it.



(or
GlbVarLayerNameOption
(setq GlbVarLayerNameOption "Band")
)
; this will set the global var if it doesn't exist

(initget "Band Uniform beaM")
(setq tt
(cond
((getkword (strcat "\n Choose tendon type [Beam/Uniform/beaM] <" GlbVarLayerNameOption ">: ")))
(t GlbVarLayerNameOption)
)
)
; the cond only executes when the test item is not nil, and it returns the last item
; item, so that is why we can use 'cond' like this, to set 'tt'
(setq GlbVarLayerNameOption tt)

[stusic]

To do something like that, you would use a global variable. Most of the time you don't want these, but once in awhile they are helpful. You may want to name the global variable something that won't be common, as you wouldn't want it to be changed to anything but what you want it to be. I prefix mine with 'GlbVar' and then write out the name. So for yours I would use something like 'GlbVarLayerNameOption'. With that said, here is how I would do it.



That is sooooo cool! Why do you say you don't normally want these?

[T.Willey]

That is sooooo cool! Why do you say you don't normally want these?

If you work with a lot of global they can step on each other. If you know which globals you have/use then there isn't really a problem, but in lisp any program can assign any value to any global variable, so you might think it is one value/type when you run your program, and if it isn't what you want it to be it could error, or give you unwanted results.

Globals are just one of those things you need to understand where they can help/hurt you, and then use them accordingly. I have globals in some of my programs, but most of the time all variables are local.

[stusic]

If you work with a lot of global they can step on each other. If you know which globals you have/use then there isn't really a problem, but in lisp any program can assign any value to any global variable, so you might think it is one value/type when you run your program, and if it isn't what you want it to be it could error, or give you unwanted results.

Globals are just one of those things you need to understand where they can help/hurt you, and then use them accordingly. I have globals in some of my programs, but most of the time all variables are local.

Not sure I quite follow. From what you explained earlier, it sounded like you name it to specifically be unique, as to not re-use them if it's not intended.

Let me read up a bit on these "globals" and see if I can get it...

[Opie]

Not sure I quite follow. From what you explained earlier, it sounded like you name it to specifically be unique, as to not re-use them if it's not intended.

Let me read up a bit on these "globals" and see if I can get it...
If you have one global variable with an integer value assigned from one routine and then you have another routine that uses the same global variable but you assign it a string value. The next time you use the first routine it will be expecting an integer but the value will be a string and it will crash. Does that make sense?

[dgorsman]

"Unique" is not necessarily so - if you thought of the variable name chances are somebody else has also. If the only code you run is your own its not bad, but if you ever incorporate downloaded material... safer is better than days of debugging.

[stusic]

"Unique" is not necessarily so - if you thought of the variable name chances are somebody else has also. If the only code you run is your own its not bad, but if you ever incorporate downloaded material... safer is better than days of debugging.

Ah, I see -- that's what I wasn't getting. I was containing this rule to only code I create, not thinking of others' code.