Hi Jim,

I may get struck down by lightning for this next statement...
but I agree with you on this one. (bg)(ducking)

In its defense, this *is* an interesting approach, but IMHO also a "future maintenance" nightmare. What happens if, in a future modification, I want things to stop or conditionally branch after one of the steps upon certain conditions being the case? If I want out after FirstStep, for instance, I still need to run -all- the code in -all- the other steps whether I need it or not. To carry this to its (probably illogical) conclusion, ** I cannot easily control what branches fire under what circumstances ** using this construct.

CASE statements are intended to be used for executing only required processes based on a logical expression -- NOT to provide a logical code sequencer. CASE is meant to reduce the amount of code that must be parsed -- NOT to arrange the order of that parsing.

Just my $.02 ---


>>>
>>>You may call it a corruption, I call it an elegant and readable solution to a common coding pattern.
>>
>>Kind of cool. I have never thought about doing something like that. However, I'd have to agree with Jim. It wasn't immediately obvious as to what was happening. I'd modify the code a bit to make it a little easier to understand (eg. add a comment):
>>
>>

>>Success = .f.
>>
>>* Run each method in sequence as each CASE
>>* gets evaluated. If an error occurs, bail
>>* out, otherwise set Success to true.
>>
>>DO CASE
>>   CASE ! This.FirstStep()
>>   CASE ! This.SecondStep()
>>   CASE ! This.ThirdStep()
>>   CASE ! This.ForthStep()
>>   OTHERWISE
>>      Success = .t.
>>ENDCASE
>>
>>Return Success
>>

>>
>>Like you, I think that I'd much rather see the above code than a bunch of nest IF statements.
>
>I shouldn't, but I just have to jump in here...
>
>"rather see" should not be a legitimate excuse for a coding practise that is a corruption of intended and expected usage of a programming construct.
>
>Just because I **CAN** cross the street without looking for traffic, it remains a stupid/silly/dumb/crazy/... thing to do.
>So it is with CASE. Who are you helping by coding this way?? If the answer is yourself, then it is the wrong answer. Similarly if you are doing it because you hate compound (or nested) IFs. Similarly if you are doing it because you hate typing.
>
>"Professionalism" doesn't mean stretching a language to its extremes or using nifty constructs because you understand the innards or using the minimum number of lines to accomplish some end or... In fact "professionalism" usually means quite the opposite. Take an Accountant... is there anything more boring to most of us? And look at what happens when an "Accountant" decides that his regular business is too boring and so starts devising alternative methods to accomplish 'standard work products' - you get your Enrons and Worldcoms and bunches and bunches of other like them!!
>
>CASE was clearly not invented for this kind of usage! Anyone who does so really is doing the busines of VFP programming a disservice IN MY OPINION!
>
>cheers