Doesn't really matter. It's like going down a checklist.
Could have also been done like
((member (getvar "errno") '( 7 52))
but that would have made the program a little more
difficult to change if a later decision was made to handle the
two conditions in different ways later. The result of both
conditions is that nothing is done. This leaves the main
check of the errno in place. When the main check is
done at the while statement, the exit will occur.
A decision to arrange the order of checks should be
made on the basis of
1) check for things that could cause errors in later checks
2) check for things that require less computation first after 1)
3) check for things expected often should happen before other checks.
There could also be other rules dependent on the situation.
Doug
"sundog" wrote in message
news:443A9E5DAB24AF511001B5E075226D45@in.WebX.maYIadrTaRb...
> Ok, ok, ok. I can follow it! Clever. Man. This lisp is versatile. And
> smart. This is the *- turn the paradigm on its head -* kind of stuff I
> like. My dog is chewing on my leg, telling me to go inside, but after 10
> minutes of puzzling, Here's my question.
> How does the following function, and why this order? Shouldn't the 7 be
> second?
> ;;;Stop testing on mispick or enter key
> ;;;-------------------------------------
> ((= (getvar "errno") 7))
> ((= (getvar "errno") 52))
>
> I thank you again. That kind of walk through of the program is very helpful
> to me. I can stare at the help files all day, stare at other code, and
> puzzle til my eyes pop out of my head, and still not get it. Thanks. I'll
> try a version on the next project and see if you approve!
>
> Matt
>
> "Bobby C. Jones" wrote in message
> news:3E5758B3472ED0A0927EBDB5F845ADEB@in.WebX.maYIadrTaRb...
> > Matt,
> >
> > The T is a little trick that is commonly used with a COND statement. COND
> > evaluates each test case that you provide in order from the first to the
> > last. It stops evaluating test expressions as soon as one evaluates to
> > True. Once you understand that principal, you can play around with the
> > order of the test expressions to achieve a desired result. In this
> > instance, our first test checks the "ERRNO" system variable. If it is 7,
> > then the user has 'mis-picked'. This is an important test for us, because
> > our loop is based on this system variable. I'll come back to that in a
> > minute. Notice that our COND statement doesn't actually do anything on a
> > user mispick. It just simply stops evaluating test expressions. Our next
> > test also checks the "ERRNO" system variable. If it is 52, then the user
> > has pressed the "Enter" key. We're assuming that this means the user is
> > tired of picking ATTRIBS (this will end the loop). Again our COND
> statement
> > doesn't do anything here, except stop evaluating test expressions. Our
> next
> > test determines whether or not the selected entity is actually an ATTRIB.
> > We know that the variable 'ent' actually contains something, because COND
> > never even gets to this test unless the user actually selects an entity.
> > Our previous two tests ensure this. If the entity is not an attribute, we
> > let the user know, then we set the ERRNO system variable to 7. I told you
> > earlier that I'd tell you why this was important to do, so be patient with
> > me, I'm almost there 🙂 Finally, we get to the infamous 't'. Remember
> > from above that the COND statement evaluates each test expression from
> > beginning to end and only stops when it finds one that evaluates to True,
> or
> > until it reaches the end of your test expressions. So what happens when
> > COND tries to evaluate our test expression T. You guessed it. It
> evaluates
> > to True (every single time, I promise) and executes all of the ensuing
> > statements. At this point we are positive that the user has selected an
> > actual attribute because whatever the user selected passed all of the
> > previous tests. This type of setup allows us to easily filter data and
> only
> > execute certain statements when specific criteria are met. These are
> > generally the statements where the actual work is to be done. In our case
> > it was to modify an attribute value. Also, note that the last statement
> > evaluated after the attrib has been set, re-sets the ERRNO system variable
> > back to 7. Why does it do this you ask/demand?!? Because this is what
> our
> > WHILE loop is keying on. Our COND statement is wrapped in a WHILE loop
> that
> > executes as long as the ERRNO system variable is set to 7. It is set to 7
> > when a user 'mis-picks' while attempting to select an entity with ENTSEL.
> > Look real hard at the loop structure. Do you see how/why it's looping?
> If
> > not, just let me know and I'll see if I can babble on for a bit longer on
> > the subject. HINT - If you only want to allow the user to select a single
> > attribute to modify, remove the (setvar "errno" 7) from the 't' test case.
> > That way it won't bomb when the user mis-picks or selects something that's
> > not an attribute, but will exit after they successfully select an
> attribute.
> > --
> > Bobby C. Jones
> > http://www.acadx.com
> >
> >
> >
>
>
![Autodesk Design & Make Report](https://forums.autodesk.com/t5/image/serverpage/image-id/1350519iCB55845EBFC43016/image-size/large?v=v2&px=999" "Autodesk Design & Make Report")
