Hi Boris

Yes, with your tip I've just realised that I was tricked by watching in debug. When I thought it was visiting the 1st 2 cases then bombing out, it was actually performing the 1st case - ie * do nothing - then doing the normal case thing of "resting" on the next case before exiting. As the first case does not have an executable line it didn't seem to enter it. So it looked like it was skipping the other cases.

D'OH!

:-)

>>>>>>Hi
>>>>>>
>>>>>>Struggling through the "bane of my life" gibberish code again that has been my lot to maintain (not mine BTW!)
>>>>>>Have been watching the following CASE in debug (using VFP7 to follow FPD2.6 code). I know that it doesn't satisfy the 1st 2 cases, and watch it skirt these, then it suddenly shoots to the EndCase, ignoring the other two cases. There are 2 similar sections where it does this too.
>>>>>>
>>>>>>Anyone any ideas how this can be?
>>>>>>
>>>>>>'ppreciate it
>>>>>>
>>>>>>Terry
>>>>>>
>>>>>>

>>>>>>do case   && journey's
>>>>>>
>>>>>>  case empty(j_start) .and. empty(j_end) .and. empty(j_andor)
>>>>>>     * do nothing
>>>>>>
>>>>>>  case j_andor="OR" .and. !empty(j_start)
>>>>>>     * but test that both times are not empty
>>>>>>     if empty(j_end)  && ignore the OR
>>>>>>        expr=expr+".and."+ opjrny+j_start
>>>>>>     else
>>>>>>        expr=expr+".and. ("+opjrny+j_start+".or." ;
>>>>>>           +opjrny+j_end+")"
>>>>>>     endif
>>>>>>
>>>>>>  case j_andor="OR" .and. empty(j_start)
>>>>>>     * ignore the OR
>>>>>>     if !empty(j_end)
>>>>>>        expr=expr+".and."+opjrny+j_end
>>>>>>     endif
>>>>>>
>>>>>>  case empty(j_andor)
>>>>>>     if !empty(j_start)
>>>>>>        expr=expr+".and."+ opjrny+j_start
>>>>>>     endif
>>>>>>     if !empty(j_end)
>>>>>>        expr=expr+".and."+ opjrny+j_end
>>>>>>     endif
>>>>>>endcase
>>>>>>

>>>>>
>>>>>Just j_andor isn't equal to [OR] and it is not empty. If it is equal to [AND] none of these will be satisfied.
>>>>
>>>>Not sure I get you there BB. However, the point is that I do not see the cursor/pointer visit either of the last 2 cases, after evaluating the 1st 2, in order to evaluate whether no case is satisfied.
>>>
>>>Just add one

WAIT WINDOW j_andor+[   !]

before the DO CASE and see what value j_andor has. If it is not equal to [OR] no CASE of this do CASE will be satisfied.
>>
>>I can appreciate that may be so but I'd have thought that it doesn't "know" in advance what's in the next case, so needs to visit it to evaluate. But this does 2 cases, neither of which is satisfied, then just jumps out of the CASE statement, without checking the other cases. How can this be?
>
>Is it possible that there was some synchronization issue between the code and the object file?
>What happens if you recompile all?
>What happens if you add WAIT WINDOW in all CASE statements?
>
>

>do case   && journey's
>   case empty(j_start) .and. empty(j_end) .and. empty(j_andor)
>        WAIT WINDOW [1]
>        * do nothing
>   case j_andor="OR" .and. !empty(j_start)
>        WAIT WINDOW [2]
>        * but test that both times are not empty
>        if empty(j_end)  && ignore the OR
>           expr=expr+".and."+ opjrny+j_start
>        else
>           expr=expr+".and. ("+opjrny+j_start+".or." ;
>                     +opjrny+j_end+")"
>        endif
>
>   case j_andor="OR" .and. empty(j_start)
>        WAIT WINDOW [3]
>        * ignore the OR
>        if !empty(j_end)
>            expr=expr+".and."+opjrny+j_end
>        endif
>   case empty(j_andor)
>        WAIT WINDOW [4]
>        if !empty(j_start)
>           expr=expr+".and."+ opjrny+j_start
>        endif
>        if !empty(j_end)
>           expr=expr+".and."+ opjrny+j_end
>        endif
>OTHERWISE
>        WAIT WINDOW [5]
>endcase
>

>O! BTW it is possible that some CASE to be satisfied, but not IF in it. Par example if j_ndor ==[OR] and EMPTY(j_start) BUT not empty(j_end)