Set Focus problemm

[ZOR]

I have the code below, where if MTCEnd value is empty, it flags up a message box, shown remmed out. However on clicking the dialogue box, or remming it out iits inclusion in the procedure, I cannot get back focus to the control MTCEnd. If I rem out the setfocus line, and press the return key after exiting the dialogue box or without it if excluded, the focus returns to the control okay. The field is enabled and not locked. It has an input mask of 00:00:00:00 and is a bound field.

Any ideas, thanks


If IsNull(Me.MTCEnd) = True Then
MsgBox "Timecode End value not entered"
Me.MTCDuration.Visible = False
Me.Label20.Visible = False
Me.Accept1.Enabled = False
'Forms!mainform1!Subform1.Form.MTCEnd.SetFocus
'Me.MTCEnd.SetFocus
'Me.MTCEnd.Text = ""
Exit Sub
End If

 

[TheAceMan1]

ZOR . . .

Sorry to getback so late . . . I saw your reply yesterday.

The problem here is that users can hit a cancel button to revert back to the origional record (new record or not). In this sense focus events are out! and you can not pin them down to specific data input sequence.

Experience (I've been programming since access 1.0) has taught me to capture any errors in the forms [blue]BeforeUpdate[/blue] event. [blue]Here you can capture all errors![/blue] [blue]They can't escape![/blue]

In this light . . . the question is . . . [blue]whats the difference if the user enters data randomly in the fields/controls and you capture the errors anyway?[/blue]

Logically there is none! . . . I always give users free-wheel with the db. If they wanna screw up . . . fine! . . . The forms [blue]BeforeUpdate[blue] event will apprise them of this . . . per control!

There is no such thing as foolproof, and within our DB's users will quickly findout what they did wrong and whats needed to correct it.

I'm saying . . . make it easy on yourself . . . let the hardcore sequence of data entry go! Let them make mistakes!
We have [blue]BeforeUpdate[/blue] that will pin then down!

I"m just asking you to think about it . . . [blue]BeforeUpdate[/blue] has already been stipulated by [blue]missinglinq[/blue] . . . and righton! . . . You'd already be done and on to more important problems.

make it easy on yourself!

[blue]Your Thoughts?[/blue] . . .

See Ya! . . . . . .

Be sure to see thread181-473997

 

[PHV]

I'm with TheAceMan1: the BeforeUpdate event proceure of a bound form is usually the best place to enforce the validation rules.

Furthermore, ZOR, your last posted code shows us that you didn't understand what a function is.
Tip: use the Option Explicit instruction.

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886