Peter/Nancy,

Nancy, you're *right on the mark* -- whichever way a developer chooses to handle this should be completely dependent on what type of action(s) need to happen when a condition succeeds or fails. There is no all-encompassing "right way" or "wrong way".

Personally, seeing twenty or so IF...ENDIF constructs in a row drives me crazy! (BG) My chosen way out of ever having to do that again was to write a table-driven "rules engine" (which is no big deal -- I'm sure others here have done the same thing, and *MUCH* more elegantly than mine) with enough options to let me "drop it in" to an app and handle 95+ percent of any data validation needs I've ever come across.

While that might be a future option for Peter, either of our suggestions (and I'm sure others from the rest of the folks here) will certainly produce the results he's looking for in this instance.


>Peter-
>
>Variation on Evan's suggestion...
>
>Sometimes you want to stop checking once any condition is false (or true, as the case may be). The case statement will do that. Sometimes you have to take some action depending on the condition, in which case your nested IFs would be correct. Sometimes you want to know all the things that are wrong, so you might want to check all conditions. In which case, I do something like the following:
>

LOCAL llFieldOK, llFileExists, llProcessedOK
>llFieldOK     = {SomeCondition1}
>llFileExists  = {SomeCondition2}
>llProcessedOK = {SomeCondition3}
>
>IF !llFieldOK
>  *!* Maybe tell the user, or set a flag for an error report.
>ENDI
>
>IF !llFileExists
>  *!* Maybe tell the user, or set a flag for an error report.
>ENDIF
>
>IF !llProcessedOK
>  *!* Maybe tell the user, or set a flag for an error report.
>ENDIF
>
>RETURN llFieldOK .AND. llFileExists .AND. llProcessedOK

>
>>I am writing a procedure that requires a certain set of criteria to happen before the end of the code can process. I need to know, other than a huge set of nested IF ENDIF calls, is there away to jump out of the code.
>>
>>Here is an example.
>>
>>In the CLICK method for a button that is labeled NEXT... when the user clicks on the NEXT button, it needs to process some information. If any of it fails it needs to remain on the current form after displaying an error msg. Writing this with IF's would look something like this.
>>
>>IF - verify proper field data is ok
>> ** data OK
>> IF - verify file exists
>> ** file exists
>> IF - processed info created
>> ** processed complete
>> IF - remaining criteria met
>> ** all done
>> ** thisform.release
>> ELSE
>> ** display error
>> ENDIF
>> ELSE
>> ** display error
>> ENDIF
>> ELSE
>> ** display error
>> ENDIF
>>ELSE
>> ** display error
>>ENDIF
>>
>>
>>This is true structured programming because it doesn't release the form until all the criteria is met.... BUT... and I know this is wrong for true programmers... but for a large chunk of code, it's easy to lose track of which loop you are in and what needs to happen. I was wondering if there was something like an EXIT call that get you out of the button code and return to the form input.