>
>Procedure someproc
>*-- Evan would replace
>* Local ...
>*-- with
>Local luReturnValue, ...
>With This
> If !.GetValidDateRanges()
> *-- Evan would replace
> * Return .F.
> *-- with
> luReturnValue = .F.
> Endif
> * Some other code ...
> Select ... From ...Into Array .arrItems
> If Type('.arrItems[1,1]')#'N'
> *-- Evan would replace
> * Return .F.
> *-- with
> luReturnValue = .F.
> Endif
> For ix=1 To Alen(.arrItems,1)
> If .arrItems[ix,2] = 'somecondition'
> *-- Evan would replace
> * Return .SomeOtherProc(ix)
> *-- with
> luReturnValue = .SomeOtherProc(ix)
> Endif
> If .arrItems[ix,3] = 'somecondition2'
> *-- Evan would replace
> * Return .SomeOtherProc2(ix)
> *-- with
> luReturnValue = .SomeOtherProc2(ix)
> Endif
> Endfor
> * Some other code where also there are few other returns ...
>Endwith
>*-- Evan would add here:
>RETURN ( luReturnValue )
>
>Endproc
>>
I think you'll find you fired the FOR ix and the ENDFOR lines. That would have been suppressed by a RETURN .F. You would have had to wrap the FOR IX...ENDFOR in an IF luReturnValue, which can easily get complicated when the type of luReturnValue may change from logical to something else.
Exiting before getting to the heart of the matter is like having a fuse in a circuit. The fuse goes before the major components melt. I often think we can learn a lot from other disciplines.
