Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Valid or whatever, revisited
Message
From
14/04/1998 00:44:31
 
 
To
13/04/1998 15:20:32
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Miscellaneous
Thread ID:
00091590
Message ID:
00091681
Views:
21
>Back to an old issue (I started a bit of it in another thread couple of days ago, but I think it needs a new thread. I need it :).
>
>Question: field validation within a control AND from the save button (both). The desired behavior is to enable validation if field is exited via regularly typing until it's full, or if the user edits it any way, and to skip validation if user didn't change the value, or a nav button is clicked on. The exception to this is that form.SaveRec method will call validation for itself. It will not call control.valid, it will call control.localvalid (defined at control class level) and set focus back to any control which returns false or 0; regular valid also calls this.

Pretty close to what I use, but your strategy must change depending on whether you use row or table buffering. With row buffering, you would definitely want to call the field rules even when a nav button is clicked, otherwise a user could commit bad changes, and you would have no way to revert. With tablebuffering you would probably want to do the same thing, but you could wait until TABLEUPDATE() to check the fields and use GETNEXTMODIFIED().

> BTW, is this the famous hook technology?

IN the sense that your Class' Valid method calls your instance's localValid method, yes.

>[Now this may be my only chance to get something done before the last method of form.txt1 fires]
>form.navbuttons.cmdexit.When()
>[And finally the last chance fires. Is this the reason why all the folks here said that Valid is legacy and the validation should be moved to .lostfocus - it fires after some of the next control's methods, so we can establish some inter-control communication?]


Actually this is not dependable. If you do some more event tracing, you'll find that this behaviour only happens when using the mouse to Navigate. The firing order changes when tabbing or using a keyboard shortcut. I found this when messing around with a form.nextcontrol property that I thought I could fill in a control's when event. Couldn't do it.

>...etc. Now is there any better solution than to replicate the signalling code (thisform.EditingIsOn=.f.) in every nav button's .When(), and to move all the validation to txt*.lostfocus, or try another approach? I have another idea - to have an indicator property of IAmChanged on every control, and set it to .t. from .InteractiveChange and .ProgrammaticChange,

I do this in my framework also. I have a method similar to your localvalid method that is hooked into the real valid method. The class' valid code looks something like (translated into your names):

if !LASTKEY() = 27 AND this.changed AND !this.localvalid()
?chr(7) && Beep
WAIT WINDOW this.failedvalidtext
this.value = this.origvalue && orig value was populated in gotfocus
this.changed = .F. && I'll explain below
return 0
endif

Checking for LASTKEY() = 27 looks to see if the user hit escape (and therefore wants to revert any changes). The documented functionality of a commandbutton's cancel property is that the btton's click code will be run if the cancel key is pressed. What is undocumented is that clicking the same command button with the mouse actually stuffs LASTKEY() with 27. This provides a little of the information you were trying to get with a commandbutton's when method.

The save method can loop through all bound controls and test the localvalid code also, using the failedvalidtext the same way before aborting the save and setting focus to the control.

Resetting the control's changed property to .F. allows the user to tab out of the control after having seen the message once. Users do not always want to fill in information in the order that you have laid out, and I don't feel I should force them. If a user consciously (or accidentally) tabs out of a control that fails its validation test, don't worry, it will be rechecked before the record is saved.

This strategy follows the theory that users should be given 'help' along the way, but should only be forced to type something after they have requested that their data be saved. Best of both worlds, IMHO
Erik Moore
Clientelligence
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform