When to validate a Textbox.

[AndrewMozley]

I have an application with a textbox in which a customer account code can be entered. (this text box is based on a class used within the application). The Valid() method of this particular control – call it txtCust - will do several things, including helping the user to search for suitable customers, displaying the name if the account code is valid, warning the user if the account code is not valid.

But in some cases we do not need to validate the account code : For example the user may have decided to open another form to look at recent sales transactions to check the likely customer code.

What is the best way to handle this requirement?

At present there is an (application-wide) Leaveform() function which can be invoked in the Valid() method. This checks - SYS(1270) - to see whether the mouse has been clicked outside the present form - perhaps to call a different enquiry form.

In this case txtCust.valid() calls Leaveform(). If this returns .T., the Valid() method returns .T. irrespective of txtcust.value.

I would be interested how other users handle this matter of when to validate a control; grateful for guidance.

Andrew

 

[Mike Lewis]

Andrew,

We've discussed your use of the Valid event before. And as I have said before, I think you are overloading the it. You are expecting it to do much more than it is really designed to do. In particular, the fact that you are allowing it to invoke another form, given that its main role is to decide whether or not to let the user move focus off the control.

The search for the customer, displaying the customer name if the code is valid, and the error message if it is not valid - those are all things that can rightly be done in the Valid. But I don't like the idea of opening another form while the Valid is in progress. And as for using the SYS() function to see if the user has clicked outside the form - I would just say that that is very unusual.

If you must open another form while the Valid is in progress, do so by letting the user click on a toolbar or a menu item. The point is that those items never receive focus, which means that the textbox won't lose focus, so the Valid will still function.

But my preferred approach would be to use the LostFocus to look for the customer and to display its name. If the name is not found, display the error message on the form, in the place where the name would otherwise appear, not in a MessageBox. That way, the user is free to open other forms, or to (temporarily) ignore the error, without being trapped in the textbox.

I would also re-check the customer code at the point where you save the record. If it fails that test, move focus back to the textbox so that the user can fix it.

At least, that would be my preferred way of doing things. Others will prefer a different approach.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[AndrewMozley]

Thank you Mike, for your prompt reply. I apologise for re-visiting this theme!

I don’t exactly _do_ the search for customer (by partial name) within the txtcust.valid() method; but if the user knows the partial name of the customer, and keys in ‘#LEW’, then txtCust.valid() calls a method which invokes the search form which comes back with the customer (if he exists); users seem to like it.

But I’m sure there are many ways of organising this.

Likewise, if the user is uncertain of the account code, and – as I believe you suggest – uses the ribbon menu to get further information, this may open another enquiry or report form, But in my case that means the the valid() method of the txtCust control is invoked, and this is why I have to check whether the method was invoked by an action outside the form.

For what it is worth this is the Leaveform() code which a Valid() method may call to see if it can abandon validation, and possible avoid displaying an error message,

*  Leave form(). 
*  returns .T. if the X in the top right hand corner of the screen has been.
*  pressed or if he has clicked outside the form.  This is usually called by
*  the Valid() method of a control which is reluctant to lose focus unless it
*  likes its own value!  In general you call this function at the start of the Valid() method.

FUNCTION LeaveForm(vThis)         && vThis is the name of the current control
LOCAL lClosed, oWhere, lLastkey
   lClosed = .F.
   lLastkey = LASTKEY()
   oWhere = SYS(1270)
     
   *  If he has completed data entry to the control by <Tab> or <Enter>, we go 
   *  ahead and validate;  otherwise he may have clicked somewhere else.  If he
   *  has clicked on the form (except the <Close> button), we insist on the validation.
   IF lLastKey <> 13 .AND. lLastKey <> 9
      IF TYPE("oWhere") <> "O" .OR. TYPE("owhere.parent") = "U" .OR. ;
            owhere.parent.name <> vthis.Parent.name
         RETURN .T.
         ENDIF
      *  Has he clicked on the Top right Close button
      IF TYPE("owhere.releasetype") = "N" .AND. owhere.releasetype = 1
         RETURN .T.
         ENDIF
      ENDIF
   RETURN lClosed
   ENDFUNC

. . . . .

But as far as its parent form, salinv, is concerned, txtcust still has focus and when I close the enquiry form, focus returns to salinv.txtcust.

Thanks again - Andrew

 

[Chris Miller]

If you wonder, how on earth the post I deleted came into existence...
I spilled a drink on my notebook keyboard as I started it, and before I could react the submit was somehow triggered.
Deleting it fortunately only takes a few mouse clicks.
But unfortunately, I have no replacement keyboard at hand - I write this with Windows On-Screen Keyboard.



Chriss

 

[Mike Lewis]

Yes, I was wondering.I thought maybe a cat had jumped on the keyboard and did a little dance.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

I think this is overcomplicating things.

Just because VFP offers the per control validation, it often enough is easier to have an overall validation in a user defined form method and call that before saving changes.

You've found a quite short, yet not easy to understand solution, if you don't know SYS(1270) inside out. I still have to think through what you check with owhere.parent.name <> vthis.Parent.name. If I get it right that only works for controls directly on the form and not on pageframes or other locations nested deeper. Well, if you start to complicate things this way, then also find a solution that's generally working. Not sure if that criticism applies at all.

I see this topic has been discussed already often enough and there are very good arguments for an overall validation instead of each single control validation, anyway. Just search "valid" in the forum.

Do you use buffering? If so, that speaks even more against using the valid event for actual validation. In the end the whole change only has to be valid when the buffered changes are committed with TABLEUPDATE, not earlier. Letting unwanted values slip through and get into the buffer is nothing to worry about.

And indeed then you may use the valid event to make lookups, establishing the convention a # at the start of the entered value should make VFP lookup what's found with the following input, why not? And doing that search in a popup form and offer the result or to pick another result, if multiple are found? Fine, why not? But then why insist on single field validation in general?

I think you like the immediate feedback this single field validation means, but why force the user to stick to a control? You can validate and mark invlalid controls with a red backcolor, then reject saving changes, until all red controls are corrected. That's the simplest way to still have immediate feedback to the user but let him decide in which way and with which help of other forms he finds a correct input.

Chriss

 

[Chris Miller]

Let me ask two questions, please.

Do you use valid as it's foreseen by VFP to be used?
Do you use table rules and field rules?

Chriss