#losingFocus callback for data validation (again) 
Author Message
 #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  
 #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  
 #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  
 #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  
 #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  
 #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  
 #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  
 
 [ 7 post ] 

 Relevant Pages 

1. data validation and data format

2. data validation and data format

3. EIP Validation Again

4. Scheme vs ML again and again and again and again

5. Scheme vs ML again and again and again and again

6. pthreads + callbacks again

7. Data validation and EIP

8. Validation of Data within the same file being changed

9. CPD2.1 table driven data validation

10. HTML Form data validation with Object REXX (Windows)

11. Data Entry with editing and validation library module

12. MF Cobol and data validation

 

 
Powered by phpBB® Forum Software