Bypassing validation

[AndrewMozley]

Many forms have a textbox control for data entry. And such a control will very likely have a Valid() method to keep focus on the control until an acceptable value is entered. So, for a very simple example, if txtcustRef must be at least 4 characters, one might include code like :

*  MycustRef.valid()
IF LEN(This.value) < 4
   MESSAGEBOX(“The reference must be at least 4 characters”)
   RETURN .F.
   ENDIF
RETURN DODEFAULT()

There will be circumstances in which you do not want the validation – for example if a ‘Cancel’ button is provided on the form and the user clicks on that. So txtcustRef.valid() may well include code to handle that.

But there are other circumstances in which you might not want the validation code be be invoked. For example there might be a Customer enquiry form where the user can look at old invoices and see what reference was used last time. In that case, if the user clicks on the enquiry form you might not want to validate the customer reference. That might be handled by detecting the position of the mouse on another form, and once again the Valid() method could invoke code to detect the position of the mouse, perhaps using the SYS(1270) function.

But here again a complication arises : if this other enquiry form (or any other form) is open, and the user has let the mouse wander over this other form - without clicking – we would not want to inhibit the validation (which checks for a long enough reference).

So I included code in txtcustRef.valid() to say that if LASTKEY() was <Tab> or Enter<>, then do the validation anyway, but otherwise do the check to bypass validation if the mouse is on another form.

This works up to a point. But if the user has navigated to txtCustRef by pressing <Enter> (from the previous textbox and then clicks on the other enquiry form, txtcustRef.valid() will think “LASTKEY() was <Enter>” (even though that was not what invoked this call to txtCustRef.valid ); and it will therefore decide to do its validation, and complain about the reference being too short – which is not what was wanted in this case.

I feel I am going round in circles !!

I did see a thread on techtips from andreateh in Feb 2004 (search for CLEAR LASTKEY(). I wonder whether that might be relevant. Thanks in advance for your guidance.

 

[Nigel Gomm]

Andrew,

one option might be to add a new property "isChanged" to your base class;
then in its interactivechange event set

this.ischanged = .t.

and have .valid() test

if this.ischanged

that would mean you only validate if something has been changed.

hth

n

n.b. you will probably want to

 this.ischanged = .f.

either at end of valid() or in .lostfocus() event

 

[Mike Lewis]

you will probably want to
this.ischanged = .f.
either at end of valid() or in .lostfocus() event

I would suggest putting it in the .GotFocus.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[AndrewMozley]

Thank you, Nigel for your prompt reply; but I am not sure that achieves the result.

The situation is that the user first navigates to txtCustRef (currently blank), by pressing Tab or Enter.

If he then presses <Tab> or <Enter> again, I do wish to validate, and complain bitterly that he has left txtCustRef blank. But if he clicks on another form - which will also fire the Valid() event - I accept that he may be wanting to find further information to help him to provide a good reference, and so I want to bypass validation.

Even while writing this, I realise that I am perhaps arguing for Mike’s recommendation, elsewhere, that validation should really happen by clicking on a separate Validate button ! But that would be quite a big change throughout the application.

 

[Nigel Gomm]

in .valid() test for

if empty(this.value) or this.ischanged = .t.
**validation code

or might the validation be better on the form's save button.... allowing the user to tab around entering data in their preferred order? and if they don't save no validation was needed anyway?

?

 

[Mike Lewis]

I am perhaps arguing for Mike’s recommendation, elsewhere, that validation should really happen by clicking on separate Validate button ! But that would be quite a big change throughout the application.

Andrew, I can see that it would indeed be a big change. But I also see that this is not your first post on the subject, and that you have had several problems in the past arising from the use of the Valid event. Personally, I never use the Valid event, precisely for the reasons that you have experienced. So I would still argue in favour of doing your validation at the point of saving the edits rather than on a per-field basis. But of course it is up to you to weigh up the pros and cons.

Quite apart from the programming issues, there are also user interface issues. When you use the Valid event, if the user enters an invalid value, they are trapped in the field. If they don't know what to enter, or what constitutes a valid value, then their only option is to cancel the entire edit.

Problems can also occur if they need to enter a value which depends on another value in the same form (such as a leaving date that has to be later than a start date).

Worst of all, if they don't know what valid value to enter, they might end up entering a fictitious value, just in order to get out of the field. I've seen cases a form contained a National Insurance number. The Valid event stipulated that the number was mandatory, that is, that the field could not be left blank. If the user didn't have the number to hand, rather than cancel the whole edit and start again, they simply invented a number. Perhaps they thought they would correct it later, but there is no guarantee that they would do so - with possibly disastrous results.

Anyhow, those are my arguments for not using the Valid event. But of course it's just my personal opinion. Other people will no doubt disagree.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Nigel Gomm]

Other people will no doubt disagree.

not me...

n

 

[mjcmkrsr]

Hi,

or might the validation be better on the form's save button

Definitely YES - I added 4 custom methods to my base form called BEFORECHANGES (specifying e. a. the controls allowed to accept changes) - CHECKCHANGES (checking whether the changes/new data are ok) - SAVECHANGES (if changes are ok SAVE - else CANCEL/REVERT) - AFTERCHANGES (reset controls to initial state, etc.). Depending on the application I can easily adapt these methods' code to specific needs.

hth

MarK