#losingFocus callback for data validation (again)
Author |
Message |
lgorsl.. #1 / 7
|
#losingFocus callback for data validation (again)
The basic problem: I have an entry field on which I need to do validation, and #losingFocus is the best time to do it. #modifyVerify is not appropriate, because the type of validation I have to do has nothing to do with legal/illegal characters, but is business-domain related. For instance, say they're entering the name of something, and I have to warn them if they're using a duplicate name. I don't actually know the complete name they typed until after the field loses focus. Say I have two entry fields in the same window, both of which have to be validated on #losingFocus. If I start off in Field1, type something, then click in Field2, the flow of events seems to be: 1. Field1 loses focus 2. Field2 gains focus (immediately) 3. Field1 #losingFocus callback code is entered. 4. Say Field1 had an error, bringing up a MessageBox. 5. Now, since Field2 has now lost focus (because of the MessageBox), a #losingFocus callback is queued for Field2. 6. I click OK in the MessageBox. 7. The queued #losingFocus callback fires, potentially bringing up a MessageBox. Steps 5-7 will repeat forever. How do other people handle this??? Is there some way for an entryField to refuse to accept input focus if there are callbacks queued up? Thanks all,
Sent via Deja.com http://www.*-*-*.com/ Before you buy.
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
|
tco.. #2 / 7
|
#losingFocus callback for data validation (again)
#losingFocus is one way to do it but strictly from a GUI standpoint, the user would have to enter some text then explicitly click out of the field before hitting the 'Ok' button on a window. If a window had 2 fields and an 'Ok' and 'Cancel' button, then it would seem to me that you would want the user to enter all the info and then go ahead and read the fields and validate them. Especially if stuff is being sent to a server or database, it would be quicker to do things all at once rather than do a field at a time. --tc
Quote:
> The basic problem: I have an entry field on > which I need to do validation, and #losingFocus > is the best time to do it. #modifyVerify is not > appropriate, because the type of validation I > have to do has nothing to do with legal/illegal > characters, but is business-domain related. For > instance, say they're entering the name of > something, and I have to warn them if they're > using a duplicate name. I don't actually know > the complete name they typed until after the > field loses focus. > Say I have two entry fields in the same window, > both of which have to be validated on > #losingFocus. If I start off in Field1, type > something, then click in Field2, the flow of > events seems to be: > 1. Field1 loses focus > 2. Field2 gains focus (immediately) > 3. Field1 #losingFocus callback code is entered. > 4. Say Field1 had an error, bringing up a > MessageBox. > 5. Now, since Field2 has now lost focus (because > of the MessageBox), a #losingFocus callback is > queued for Field2. > 6. I click OK in the MessageBox. > 7. The queued #losingFocus callback fires, > potentially bringing up a MessageBox. > Steps 5-7 will repeat forever. > How do other people handle this??? Is there some > way for an entryField to refuse to accept input > focus if there are callbacks queued up? > Thanks all,
> Sent via Deja.com http://www.deja.com/ > Before you buy.
Sent via Deja.com http://www.deja.com/ Before you buy.
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
|
Peter van Rooije #3 / 7
|
#losingFocus callback for data validation (again)
Consider the following: Don't pop up a message box. They're annoying. Make the offending field red or something. If the user presses OK or issues some other command that uses the input data, while there is still invalid input, then pop up a message box, and make it explanatory. Any questions, let me know. Regards, -- Peter van Rooijen
fax, voice mail +31 20 866 2895
Quote: > The basic problem: I have an entry field on > which I need to do validation, and #losingFocus > is the best time to do it. #modifyVerify is not > appropriate, because the type of validation I > have to do has nothing to do with legal/illegal > characters, but is business-domain related. For > instance, say they're entering the name of > something, and I have to warn them if they're > using a duplicate name. I don't actually know > the complete name they typed until after the > field loses focus. > Say I have two entry fields in the same window, > both of which have to be validated on > #losingFocus. If I start off in Field1, type > something, then click in Field2, the flow of > events seems to be: > 1. Field1 loses focus > 2. Field2 gains focus (immediately) > 3. Field1 #losingFocus callback code is entered. > 4. Say Field1 had an error, bringing up a > MessageBox. > 5. Now, since Field2 has now lost focus (because > of the MessageBox), a #losingFocus callback is > queued for Field2. > 6. I click OK in the MessageBox. > 7. The queued #losingFocus callback fires, > potentially bringing up a MessageBox. > Steps 5-7 will repeat forever. > How do other people handle this??? Is there some > way for an entryField to refuse to accept input > focus if there are callbacks queued up? > Thanks all,
> Sent via Deja.com http://www.deja.com/ > Before you buy.
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
|
Srikrishna Kott #4 / 7
|
#losingFocus callback for data validation (again)
I would do the same thing what "tc" explained below.... because you can't predict what button would be pressed at the end. If user willing to hit 'Cancel', all the work that was done on "Losing Focus" would go waste. You can write a framework method for validation when user pressed OK and before closing the window, then there won't be race around condition. ---Krishna Quote:
> #losingFocus is one way to do it but strictly from a GUI standpoint, > the user would have to enter some text then explicitly click out of the > field before hitting the 'Ok' button on a window. > If a window had 2 fields and an 'Ok' and 'Cancel' button, then it would > seem to me that you would want the user to enter all the info and then > go ahead and read the fields and validate them. Especially if stuff is > being sent to a server or database, it would be quicker to do things > all at once rather than do a field at a time. > --tc
> > The basic problem: I have an entry field on > > which I need to do validation, and #losingFocus > > is the best time to do it. #modifyVerify is not > > appropriate, because the type of validation I > > have to do has nothing to do with legal/illegal > > characters, but is business-domain related. For > > instance, say they're entering the name of > > something, and I have to warn them if they're > > using a duplicate name. I don't actually know > > the complete name they typed until after the > > field loses focus. > > Say I have two entry fields in the same window, > > both of which have to be validated on > > #losingFocus. If I start off in Field1, type > > something, then click in Field2, the flow of > > events seems to be: > > 1. Field1 loses focus > > 2. Field2 gains focus (immediately) > > 3. Field1 #losingFocus callback code is entered. > > 4. Say Field1 had an error, bringing up a > > MessageBox. > > 5. Now, since Field2 has now lost focus (because > > of the MessageBox), a #losingFocus callback is > > queued for Field2. > > 6. I click OK in the MessageBox. > > 7. The queued #losingFocus callback fires, > > potentially bringing up a MessageBox. > > Steps 5-7 will repeat forever. > > How do other people handle this??? Is there some > > way for an entryField to refuse to accept input > > focus if there are callbacks queued up? > > Thanks all,
> > Sent via Deja.com http://www.deja.com/ > > Before you buy. > Sent via Deja.com http://www.deja.com/ > Before you buy.
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
|
Richard MacDonal #5 / 7
|
#losingFocus callback for data validation (again)
Not sure what dialog you're using, but check for an #aboutToLoseFocus and use that instead, preventing the change of focus to occur. If this fails, include the field as an argument in the callback, then have the handler reset the focus. Personally, I update the domain model as soon as the value is entered and accepted. The domain model will trigger an exception which may or may not be used for some purpose. But I also have code (a mini-controller) tying the field and the domain object together. This controller actually handles the events (no direct links between the domain and the field), so it handles the change forwarding to the domain, then it immediately calls the domain object for its value and inserts it into the field. Thus, I can handle display formatting (e.g., putting dashes into a social security number if the user did not enter them). If the domain model rejects the new value it will keep its old value, which will be re-inserted back into the field. Downside is that whatever the user typed is lost.
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
|
Denis Johnso #6 / 7
|
#losingFocus callback for data validation (again)
I'm not sure which dialect you're using, but in VisualWorks there are also a series of optional request callbacks including a request to change the value at the model (this is called just before the widget updates the model) and there is also a request for giving up focus. The response to these callbacks must be a boolean representing the permission to go ahead or cancel the requested operation. With this, one has the opportunity to achieve what you ask for and much more. This can be just the tip of the iceberg though with various approaches and issues to contemplate. I have written a framework addressing these issues (as I'm sure many others here have) so if you have other questions or just want to discuss further, then feel free to e-mail me. Regards Denis Quote:
>The basic problem: I have an entry field on >which I need to do validation, and #losingFocus >is the best time to do it. #modifyVerify is not >appropriate, because the type of validation I >have to do has nothing to do with legal/illegal >characters, but is business-domain related. For >instance, say they're entering the name of >something, and I have to warn them if they're >using a duplicate name. I don't actually know >the complete name they typed until after the >field loses focus. >Say I have two entry fields in the same window, >both of which have to be validated on >#losingFocus. If I start off in Field1, type >something, then click in Field2, the flow of >events seems to be: >1. Field1 loses focus >2. Field2 gains focus (immediately) >3. Field1 #losingFocus callback code is entered. >4. Say Field1 had an error, bringing up a >MessageBox. >5. Now, since Field2 has now lost focus (because >of the MessageBox), a #losingFocus callback is >queued for Field2. >6. I click OK in the MessageBox. >7. The queued #losingFocus callback fires, >potentially bringing up a MessageBox. >Steps 5-7 will repeat forever. >How do other people handle this??? Is there some >way for an entryField to refuse to accept input >focus if there are callbacks queued up? >Thanks all,
>Sent via Deja.com http://www.deja.com/ >Before you buy.
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
|
Bob Whitefiel #7 / 7
|
#losingFocus callback for data validation (again)
Quote:
> Don't pop up a message box. They're annoying. Make the offending field > red or something. If the user presses OK or issues some other command > that uses the input data, while there is still invalid input, then pop > up a message box, and make it explanatory.
I'd like to second that. See Alan Cooper's excellent book "About Face" for an explanation of why you shouldn't bring up message dialogs for simple validation problems. As Cooper puts it: "Don't stop the proceedings with idiocy!" If a validation test fails, simply change the background color of the field to pink. This unobtrusively tells the user they have a problem, but doesn't stop them from continuing. If you have a status bar at the bottom of your window, put an informative message there. You may also want to change the tooltip text for the field to explain the problem. But whatever you do, don't put up a dialog, and don't beep! If the user tries to commit changes while errors exist, then you can put up a message dialog, telling them what needs to be fixed. Better yet: Disable the OK or Save button until all validation has passed, and have the status/tooltip message for the disabled button explain the pink fields. This approach sounds a bit extreme the first time you hear it (because we've gotten so used to stupid error dialogs, according to Cooper) but users LOVE it. It puts them in control because they correct mistakes at their convenience--not the computer's. Bob
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
|
|