>>>>I am definitely not a fan of a sequence of DO CASE statements that are deliberately coded to "do work" (in the conditions themselves) and to ALL run in the sequence coded. To me that 'style' is a pure corruption of the intention of DO CASE.
>>>>
>>>I often corrupt <g> the DO CASE.
>>>I put the real work within the CASEs.
>>>The alternative is usually to use nested IF - ENDIFs.
>>>And I personally HATE those.
>>
>>To each his own, Andy, and I'm sure you're not alone.
>>
>>Just curious as to what you mean by 'within the CASE'. If by that you mean after each CASE, then I'd say that's proper use of CASE. If you mean as part of the CASE statement (i.e. the conditions) then that's where *I* have a problem.
>>
>>I HATE typing but I still code descriptive names for memvars, properties, methods, fields, etc.
>>
>>
>>cheers
>
>Here is an example.
>

>...
>DO CASE
>    CASE NOT EMPTY( mytable.cost )
>        THISFORM.cErrorMsg = "Please fill in Cost."
>    CASE mytable.cost >= 10000
>        THISFORM.cErrorMsg = "Cost must be less than $10,000."
>    CASE lTooMuchForThatVendor( mytable.cost )
>        THISFORM.cErrorMsg = "The Cost is too much for that Vendor."
>ENDCASE
>IF NOT EMPTY(THISFORM.cErrorMsg)
>    RETURN
>ENDIF
>...
>

>I use the DO CASE to set the flow of a program.
>If I call a function, like lTooMuchForThatVendor(), it is to check some value. I don't do much other processing in a called function.
>
>Hope this clarifies something!

Your logic has a flaw in it. The first CASE should not have the NOT in it. I know it's only an example, but it should demonstrate things correctly.