Set focus question

  • Thread starter Thread starter Junior
  • Start date Start date
J

Junior

focus doesn't return to [txtDob] if the field is null -
instead, focus advances to the next field
what is wrong with this code- or- what should i be looking for?

Private Sub txtDOB_Exit(Cancel As Integer)
If IsNull(Me!txtDOB) Then
MsgBox "Input is required in this field", vbOKOnly
Me.txtDOB.SetFocus
End If

End Sub
 
focus doesn't return to [txtDob] if the field is null -
instead, focus advances to the next field
what is wrong with this code- or- what should i be looking for?

Private Sub txtDOB_Exit(Cancel As Integer)
If IsNull(Me!txtDOB) Then
MsgBox "Input is required in this field", vbOKOnly
Me.txtDOB.SetFocus
End If

End Sub
Click to expand...

Try ...

Private Sub txtDOB_Exit(Cancel As Integer)
If Len(Me!txtDOB & "") = 0 Then
MsgBox "Input is required in this field", vbOKOnly
Cancel = True
End If
End Sub

- Jim
 
Junior said:
focus doesn't return to [txtDob] if the field is null -
instead, focus advances to the next field
what is wrong with this code- or- what should i be looking for?

Private Sub txtDOB_Exit(Cancel As Integer)
If IsNull(Me!txtDOB) Then
MsgBox "Input is required in this field", vbOKOnly
Me.txtDOB.SetFocus
End If

End Sub
Click to expand...

You have to use the Cancel argument to tell Access that you don't want
to exit the control:

Private Sub txtDOB_Exit(Cancel As Integer)

If IsNull(Me!txtDOB) Then
MsgBox "Input is required in this field", vbOKOnly
Cancel = True
End If

End Sub
 
Just one more comment about this - IMHO the Exit Event is not the best place
to put code to ensure that data is valid. This event will fire if the user
tries to move focus to anything else and it can become rather frustrating to
the user. What if the user just wants to click undo to start over - he'll
have to enter something in this field first! Instead, I find it better to
move this sort of validation to the BeforeUpdate event of the form. This
allows you to catch the ommission before the record is saved and then using
the setfocus event you can return focus to the problematic control.
BeforeUpdate has a cancel event which is used in the same way as Dirk has
described for the Exit event.
 
Sandra Daigle said:
Just one more comment about this - IMHO the Exit Event is not the
best place to put code to ensure that data is valid. This event will
fire if the user tries to move focus to anything else and it can
become rather frustrating to the user. What if the user just wants to
click undo to start over - he'll have to enter something in this
field first! Instead, I find it better to move this sort of
validation to the BeforeUpdate event of the form. This allows you to
catch the ommission before the record is saved and then using the
setfocus event you can return focus to the problematic control.
BeforeUpdate has a cancel event which is used in the same way as Dirk
has described for the Exit event.
Click to expand...

And FWIW I agree with Sandra.
 
:-)

The real question is whether you learned this the hard way! (I'll confess
that I did!!)
 
Sandra Daigle said:
:-)

The real question is whether you learned this the hard way! (I'll
confess that I did!!)
Click to expand...

Actually, I learned it from my own frustration in trying to work with
applications designed like that. That's probably not "the hard way",
but it's very convincing.
 
Back
Top