If/then question

Hello all,
Below is a snippet of some code I am working on, however, I am having
trouble with
the if/then when determining what layer the object is on.
I threw in some commented psuedo code so you can see where I am having
problems.
Basically, if the object is on layer 1, then solid fill it, if on layer 2
then another hatch, etc. etc.
Many thanks.

(setq ss (ssget '((0 . "CIRCLE,POLYLINE,LWPOLYLINE,TEXT,MTEXT")))
i -1
ss1 (ssadd)
)

(repeat (sslength ss)
;;if the layer is 1 then
(command "_.hatch" "s" (ssname ss (setq i (1+ i))) "") ;SOLID
;;end if

;;if the layer is 2 then
(command "_.hatch"
hat_pat
hat_scale
hat_angle
(ssname ss (setq i (1+ i)))
""
)

;;end if
(ssadd (entlast) ss1)
)
(command "_.draworder" ss1 "" "b")

 

Have a nice day.

(cond
((= your_layer layer_name)
(progn
(do_this_or_that)
))
((= your_layer layer_name)
(progn
(do_this_or_that)
))
((= your_layer layer_name)
(progn
(do_this_or_that)
))
((= your_layer layer_name)
(progn
(do_this_or_that)
))
)
--

AUTODESK
Authorized Developer
www.Cadentity.com
MASi

 

The THEN portion will take only one arguement. Use (PROGN to group several arguements into one.

 

The THEN portion will take only one arguement. Use (PROGN to group several arguements into one.

 

Basically, if the object is on layer 1, then solid fill it, if on layer 2
then another hatch, etc.

Rudy's right that cond is more suitable than if for checking multiple
conditions, but you don't need a progn in a cond:

(repeat (sslength ss)
(setq
i (1+ i)
ename (ssname ss i))
ss1 (ssadd)
layr (cdr (assoc 8 (entget ename)))
)
(cond
((= "1" layr)
(command "_.hatch" "s" ename "")
)
((= "2" layr)
(command "_.hatch" "s" hat_pat hat_scale hat_angle ename "")
;do more stuff if you want
;do more stuff if you want
)

;;etc

(t nil) ;catchall for other layers
)
(ssadd (entlast) ss1)
)

I'd put the as many of the setqs as possible outside the cond -- for
instance, don't repeat the same "setq i" for each different condition. Each
condition has a single test (one expression that must evaluate to either nil
or "something") and one or more results, which are triggered if the test
isn't nil. It's traditional to put a final t test which always triggers a
nil result, to handle any possible condition you haven't tested.

 

For If/Then Help Look Here.

http://theswamp.org/phpBB2/viewtopic.php?t=731&postdays=0&postorder=asc&&start=15

CAB

 

http://theswamp.org/phpBB2/viewtopic.php?t=731&postdays=0&postorder=asc&&sta
rt=15

CAB, that's a good simple description for both if and cond. A small point,
though: you said "The (cond) stmt on the other hand executes the all of code
following a true condition and then exits the condition stmt." There doesn't
have to be anything after the true condition; the last thing evaluated is
what's returned (or executed). Often it's more pertinent to think in terms
of return value than execution.

(cond
((exit_if_plan_a_works))
((exit_if_plan_b_works))
;etc
(t nil)
)

Would be valid if each of the functions called are designed to return
something for success and nil for failure. Though it might better be written
as

(or
(plan_a_works)
(plan_b_works)
;etc
)

 

Creature of habit, I like to enclose everything as illustrated.

I've found that (while ...) statements still processes information when
exiting, unlesss contained in a 'Progn'. To me it's just much easier to
manage visually, than to not use the 'Progn'.

 

To me it's just much easier to manage visually, than to not use the
'Progn'.

I agree that readabilty matters, but to me the structure is obvious from the
indentation in these examples.

In most cases I'll only have a single "result" expression for each "test"
expression, so it becomes a moot point -- I certainly wouldn't enclose a
single expression in a progn.

 

Thank you all very much, I learned a ton from all the posts =)

 

Well put Tom.
The example given was to show an example of FLOW and nothing more.
As you pointed out the return value is often a consideration but the
condition function may not need to return a value.
Producing the correct return value is a subject unto itself.

CAB