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