Hi Agnes,

First, I like your tag line(s) < s >!

The essence of *my* problem is usage of a DO CASE to do "work" in the actual CASE statement AND always end up being a FALSE so that the next DO CASE executes too.

Sure, the reader's brain will eventually get it, but probably (as has been the case with me) only after much frustration.

I think it is pretty clear that a DO CASE is expected to ask/answer a "question" and not to do real "work"... in the corrupted use in fact THE real work AND in concert with the remaining DO CASE statements. DO CASE simply is not anticipated to do that so the (next) reader only looks for that as a last resort. (= frustration)

We are talking about readability here, not ease of coding. An IF, even nested to 5 or 6 levels, conveys a certain intention and certain factors about the problem at hand. Yes, it can be accomplished with a DO CASE with fewer lines but the DO CASE also conveys certain things that are totally opposite to its actual usage in that case.

If I wrote "trees cannot over jump Dogs tall" you could eventually figure out what I meant and I could say it's perfectly understandable to me so what's your problem < s >. Does that make me right? Why is it any different with programming?

cheers


>Hi Jim,
>>I continue to contend that DO CASE's design was never to do as your top example shows ...
>
>PMFJI,
>
>but to use things in a way they are not designed to is that what makes life possible down here. If our anchestors stuck on that idea they would never had invented the use of open fire. Or do you realy mean something is originally designed to be cooked? ::) (If the last sentence harms somebodies religous feeling: apologies)
>
>For example a wire was originaly not invented to conduct a current. Or a computer to draw graphics on it.
>
>I even disagree that DO CASE is not designed to do it. DO CASE catches the first expression that evaluates to .T. and what else is the code doing?
>I agree that a too tricky use of DO CASE might be very unreadable and I have seen code like
>
>

>lnLoop=1
>do while .t.
> do case
>  case lnloop=1 and some_function()
>   lnloop = some_newval
>  case lnloop=2 and some_other_function()
>   lnloop = some newval
>*...
>  otherwise
>   exit
> endcase
>enddo
>*process lnLoop for return code ...
>

>AFAIK I saw this in a FoxTalk article ...
>
>And why should I waste my time if endless boring IF..ELSE..ENDIF if it goes that neat? If the reader got the trick (and he will) its much faster to read then IF nested to dead or superfluous expressions to hold it flat.
>
>And (just a 1€cent thought) if you use a DO CASE like in VB, PASCAL or the like you still can do things like
>

>lnLoop=1
>do while .t.
> do case
>  case lnloop=1
>   if some_function() THEN
>    lnloop = some_newval
>   else
>    lnloop = some_other_newval
>   endif
>  case lnloop=2
>*...
>  otherwise
>   exit
> endcase
>enddo
>*process lnLoop for return code ...
>

>,even eleminating the Exit and place some expression instead of DO WHILE .T. wouldn't make it better here.
>
>But do you know that this looks close to the way a PLC will be programmed?
>
>So all what I say is that all that stuff it depends on the place of use and sometimes the brains of the reader. And my personal feeling is that over normalizing a database is as wrong as a single return (loop,exit) point that result in endless deep nesting. To deep nesting is hard to maintain too.
>
>I normaly have a bunch of RETURNS on top of a method that will check the input, then I will process (with or without loop and exit as needed because they are designed for it) and a return an the end.
>
>We can not ban every usefull command because somebody missuse it.
>
>I go that far to say that something like GOTO target has it goods
>because something like the following is very easy to understand
>(pseudocode)
>

>parameters;
>lvOptional
>if expression then
> GoTo WeHaveParameter
>endif
>
>*some hundred lines to get the value from somewhere else
>
>:WeHaveParameter
>
>*process
>

>is very clear.
>
>And one last.
>
>If somebody is unable to trace some simple constructs like EXIT or LOOP, how should he ever deal with the wonders of *_ASSIGN, *_ACCESS, BINDEVENT or even the events that vfp raises?
>
>Agnes