stop one method and starts another method

[namax]

Hi all,
I have written 2 new methods for a form and put them on the same code.I want the second method to execute after the first when the first method completes execution.I know there is a way but couldn't have them work as I expect.Any help would greatly be appreciated.Thankyou in advance.

 

[Olaf Doschke]

Well, you would call the first method and at the end of it call the second. Or you add a third method calling one, then the other. Simple enough?

Bye, Olaf.

 

[Mike Lewis]

Hi Namax,

There's nothing special you need to do to achieve this. In general, VFP completely finishes executing a method before it continues with the code that calls it. So, the following code would do what you want:

THISFORM.Method1
THISFORM.Method2

Method2 will execute when Method1 has finished.

Does that answer your question, or have I misunderstood it?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[namax]

Hi All,
Thank you for the reply.Maybe I was not too clear.I am sorry.
I tried as Mike has mentioned but I think will work well if there are no conditional statements added in the methods but I have,in the first method, included a DO CASE..ENDCASE statement. The second method should execute only if some conditions are met in the first method.

Brief explanation.I want the data entry people to verify consistency of data entered during data entry.If the data entered of a record doesn't meet the conditions required in the first method then the record pointer should go to that particular record for editing via the data entry form before adding a new record AND NOT ALLOW SECOND METHOD TO EXECUTE after the first method,otherwise second method should execute.

1.first method has queries for data consistency; and
2.second method has code to append new record to the table

I hope this clarification may help you work out the solution.Thank you in advance once again.

 

[Dan Freeman]

What you want to do can certainly be done, but none of it is automatic.

What you're describing is application logic and it's up to you to devise and create that application logic. You can store values from one method (data validation results, for example) for use in the next method. There are many ways to do this.

For validating user input, though, you'd typically separate JUST the data validation logic and put that into the control that accepts data. (See VALID method.) You'd never get to code that depends on having passed data validation if you never pass data validation.

 

[Mike Lewis]

Namax,

What you want to achieve is really quite simple. You simply need to arrange for Method1 to return a logical value - that's either .T. (true) or .F. (false) - depending on whether you want Method2 to execute.

So, in Method1, your code would look something like this (this is just an outline, not the actual code):

do some stuff
test the condition
IF the condition is true
  RETURN .T.
ELSE
  RETURN .F.

In the code that calls the two methods, you test the value returned from Method1. If, and only if, that value is .T., you call Method2:

IF THISFORM.Method1()
  THISFORM.Method2
ENDIF

Note the opening and closing parentheses in the first line above. That's important in this case, to allow the calling code to "see" the returned value.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Mikes last solution would work, you could also still use the approach to call method2 at the end of mehtod1, just do it under whatever conditionns need to be fulfilled and not call method2, if there is some data validation error.

It's rather typical to return the success of an operation, though, as mike put it. You could call the methods DataIsValid and save and would then have code:

WITH THISFORM
  IF .DataIsValid()
    .Save()
  ENDIF
ENDWITH

Sounds quite like natural language, doesn't it?

And of course as Mike said the DataIsValid method must either return .F. or .T. (false or true), nothing else would be acceptable for the IF to work (well, except .NULL., but that would cause the same as .F. in the IF). Just by the way, even if you don't add a RETURN statement to a function or method, it will return .T. (true).

It's a natural way of both OOP programming and procedural programming to chop your problems into smaller chunks, so you can put the logical flow into such flow control code like IF and CASE are. You say you already use CASE in your data validation method, so you know the principle to control what's done conditionally, already.

There are some other ways you could turn this into, eg you could call Save (Method2) in the first place, but let Save first call the validation, so your outer code could just be calling Thisform.Save(), and you put the responsibility to check the validity of the data into the save code, and it would do

*Save method
IF Thisform.DataIsValid()
  * save the data
ENDIF

The advantage of that is you encapsulate the check for the validity into saving the data itself. So anywhere any other code of your form would call into the Save method, that would first check the data validity and you can never forget to check that.

On the other side, keeping the validation call out of the Save method will separate the concerns of data verification and saving data. These are two separate things you can do with the data and they don't need to depend on each other.

Both principles, separation of concerns on the one side, and encapsulation on the other side, are aspects of object oriented programming. To the more advanced develope, forgive me, for using this as encapsulation example, we are talking about a form as a single class/object and therefore this does not really fit here, but in principle.

So in the end it's a bit a matter of taste how you do that, you have to decide case by case what principles are more important. In this case, invalid data might not technically be invalid and save could possibly save it anyway. If you need to prevent false data in your database, you would couple the validation strongly to the save, so you would perhaps choose the way to let the save method call the validation so you can be sure it's called right before you save - always. But there is no single right way of doing this. The separation of the two things into two method still makes sense, just to have less code in each method. Keeping code readable and have the overview is preferable.

Bye, Olaf.