VFP equivalent of RETURN?

[mpgalvin]

I'm converting an FP2.6 program to VFP. It's going well, but I'm hitting some issues with some RETURN statements.

The FP2.6 version has conditions all over the place, and if these conditions are not met, it simply RETURNs out of the program. Now most of these portions of code are going into an object event procedure thing.

I can't RETURN out of cmdButton.Click, can I? Would EXITPROC work? Basically, if the condition is not met, I want to stop processing, but I'd like to avoid multiple-nested IF statements...

IF condition
.
.
.
IF condition2
.
.
.
IF !condition3

etc

Instead I'd prefer:

IF !condition
EXIT
ENDIF

.
.
.

IF !condition2
EXIT
ENDIF

.
.
.

etc

 

[GlynW]

The best suggestion would be to tidy up the code...

Each routine should really one way in and one way out. Sometimes you can't avoid it, but it's good practice.

Try copying each condition check to a new function, and then calling them 1by1 at the end check if the each function returned .T. To carry on.

Fair enough this will still be nested if's but the code would be a lot easier to follow.

Hope this helps

 

[mpgalvin]

I'm not sure how that would help. "Copy each condition to a seperate function"? Each condition is really just

IF t_field = 0 THEN

which doesn't strike me as a suitable candidate for a seperate function

And, as you say, it wouldn't solve my problem of nested IFs, which is really what I'm trying to avoid here - nested IFs are usually my biggest problem when coming back to code ("Now, does that ELSE belong to that IF statement, or the one above it&quot Especially if the indentation leaves something to be desired.

 

[GlynW]

How about......



VarLastConditionPassed = .F.

IF Condition1()
VarLastConditionPassed = .T.
ENDIF

IF Condition2() .AND. VarLastConditionPassed
VarLastConditionPassed = .T.
ENDIF

IF Condition3() .AND. VarLastConditionPassed
VarLastConditionPassed = .T.
ENDIF

IF Condition4() .AND. VarLastConditionPassed
VarLastConditionPassed = .T.
ENDIF

Each If statement is dependant on the previous passing if one fails the rest fail and falls out of the procedure.

This isn't the best solution, but it keeps all your code together, and no real heavy nesting.

Just trying to help...

Glyn

 

[GlynW]

Whoops...

I missed out the ELSE's doh!
they should be the following


IF ConditionN() .AND. VarLastConditionPassed
ELSE
VarLastConditionPassed = .F.
ENDIF


......
When I said the 'condition check to a new function' I ment the condition code. so you will still be left with your.

IF t_field = 0 THEN
*** line of code *** line of code |
*** line of code |
*** line of code |
*** line of code |- move these inside a func or proc
*** line of code |
*** line of code |
*** line of code |
*** line of code/
ENDIF


So that would have left you with...


IF t_field1 = 0 THEN
DO passedProc1

IF t_field2 = 0 THEN
DO passedProc2

IF t_field3 = 0 THEN
DO passedProc3

IF t_field4 = 0 THEN
DO passedProc4

IF t_field5 = 0 THEN
DO passedProc5
ENDIF
ENDIF
ENDIF
ENDIF
ENDIF

Anyway best of luck...

Cheers

Glyn

 

[foxdev]

I can't RETURN out of cmdButton.Click, can I?

To answer mpgalvin's original question: yes, you can issue a RETURN in method code, including cmdButton.Click.

I'm not sure I agree with the suggestion of using external procedures; if you're trying to design an object-oriented system, there should be a cleaner way of handling this either internally in the code you have or using other methods in the same object or form.

If it fits, you might also consider using CASE statements or, if the IF conditions are all known at the beginning, something like:

[tt]if condition1 and condition2 and condition3
* pass
else
* fail
endif[/tt] Robert Bradley

http://www.foxdev.com/

Do you have too much money? Visit

http://www.agrainofhope.org