Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. file info. rss.
 From: Ken Murphy
  Where is Ken Murphy?
 Ken Murphy
 To: Sandeep Misra
  Where is Sandeep Misra?
 Connecticut - United States
 Sandeep Misra
Subject: RE: accessing forms after show
Thread ID: 112328 Message ID: 112335 # Views: 1 # Ratings: 0
Version: Visual FoxPro 8 Category: Forms
Date: Tuesday, November 07, 2006 1:17:40 PM         

> Hi All
> Please help me out with this.
> I have a situation where i am creating a form to display certain text boxes and labels. The user has the privilege to enter data into this form textboxes.
> i need to do a validation on some data that has been entered into the text boxes of the form by the user.
> i am creating a form object of an existing form class which has an OK click event method. This method releases the form object once executed.I want the field validations to happen before releasing the form on the OK click event.
> Please let me know if it can be done without creating a new class.
> regards
> Sandeep


You have a number of options open to you depending on where you wish to do your validation. For most applications validation happens when the user attemps to exit the listbox, textbox, combo, etc. Take a look at the .Valid() event for most form controls. To explain this, lets look at a simple example - a textbox where the user must enter a product code that exists in the product table. You drop a texbox onto a form and then enter the following into the .Valid() of that texbox
LOCAL lnRetVal

IF SEEK(PADR(ALLTRIM(UPPER(This.Value)),10,[ ]),[ProductTable],[ProductIDTag])
   lnRetVal = 1
   MESSAGEBOX([Invalid Product Code],16,This.Name)
   lnRetVal = 0

The first command simply declares the return value as a local numeric variable. The next command may take a bit of understanding. The first thing it does is set the value of the textbox (what the user entered) as upper case. It then removes all of the leading and trailing spaces and then it adds spaces back, but only as trailing spaces. This is done to ensure that the text is comparible to the data in the product table. For the sake of this example, the product ID field in the ProductTable will be 10 upper case chars. Finally, it looks up that value using a SEEK() function over ProductTable and using the ProductIDTag to do the search. If it finds a match it then returns a value of 1 (we will get back to this return value in a second) and if it does not find a match it pops an error message to the user and returns zero.

The return value from a .Valid() event can be logical (.t. or .f.) or an integer (-1, 0, 1, 2, ...) If the return value is logical, and if you return a .t. VFP accepts the value as validated and moves focus to the next control in the tab order (the next textbox, compo, etc.) If the return value is .f., you have told VFP that the value did not validate and therefore VFP retains focus in the current textbox. The user must then re-enter that value correctly.

You can also use an integer return value. If you return a zero, vfp treats it as an unvalidated value and retains focus in that textbox. If you return a 1, vfp treats it as a validated value and moves focus one step in the tab order (to the next textbox, combo, etc.) Now, you can get a little fancy here if you want to. If you return a 2, VFP also treats it as a validated value but it moves focus two steps in the tab order - it moves focus to the second combo, textbox, etc. Entering a negative value will work the same way except that it moves focus in reverse tab order. Create a new form, drop a series of textboxes (set initially to a zero value) on it and then in the .valid() of one of these, enter
RETURN This.Value
Now, play with it, entering negative and positive values and you will see this in action.

This is the way most apps are designed. The validation code goes directly into the .Valid() event. It works, but it has some drawbacks. What happens if the validation rules change? Now you have to go through your entire app looking for and changing that validation code. There are two better ways to handle this. First, you can create a custom textbox for entering product codes. The validation code exists only in one place and when the validation rules change, you only need to fix it in one place.

Another option is to create a procedures file that held the validation code as a series of functions. In your textbox's .Valid() you simply call a fuction:
RETURN ValidateProductCodeFunction(This.Value)
The function returns a .t. or a .f. or it might return an integer. Using our example above you would define the fuction as
FUNCTION ValidateProductCodeFunction


LOCAL lnRetVal

IF VARTYPE(lcProductCode) == [C]
   IF SEEK(PADR(ALLTRIM(UPPER(This.Value)),10,[ ]),[ProductTable],[ProductIDTag])
      lnRetVal = 1
      MESSAGEBOX([Invalid Product Code],16,This.Name)
      lnRetVal = 0
   MESSAGEBOX([Invalid parameter],16,[ValidateProductCodeFunction])
   lnRetVal = -1

Now, if you are working with remote data, or with a non-VFP backend, you might wish to create these functions as stored procedures on the database. When you run them, they run on the server - not in the client. Depending on the procedure, this can mean that you reduce network traffic.

Another way to handle validation is to do it in the "Save" button (similar to your OK button.) When the user clicks the "Save" button, the .Click() event calls a series of validation procedures. If all of the validation proceedures succeed, the record saves, if not, focus is set to the offending control.
CASE NOT ValidateProductCode(ThisForm.ProductCodeTextBox.Value)
   MESSAGEBOX([Invalid product code])
CASE ...
   && or in your case ThisForm.Release

You can validate as you go, or validate all at the end - up to you. (I personally like the validate as you go method. I hate having to go back to fix somethihg - let me fix it while I am there.

Hope this helps.

You shall know the truth - and the truth shall set you free. (John 8:33)


accessing forms after show Posted by sandeep misra @ 11/7/2006 12:04:34 PM
RE: accessing forms after show Posted by Andy Kramek @ 11/7/2006 12:38:50 PM
RE: accessing forms after show Posted by Ken Murphy @ 11/7/2006 1:17:40 PM