.SetFocus and .SelStart

[Hello1]

I have a field on a form which is used to enter the email address of a customer.
I have put some code on after update to check if the entered Email address is valid.
If its not I want to set focus on that field and select the text but I dont want the record to save, the email has to be valid to be able to save.
However, the SetFocus just isnt working it doesnt set focus on that field and then select the text.

KeyDown → BeforeUpdate → AfterUpdate → Exit → LostFocus
You can re-set the focus anywhere in there and it will still keep following the pattern. So we need to tell it to stop following the pattern. Replace your Me.MyFld.SetFocus with DoCmd.CancelEvent and it should fix your problem. Basically, this just kicks you out of the above pattern, so the Exit and LostFocus events never fire...

I tried the DoCmd.CancelEvent but same thing.
Heres my code

Private Sub Email_AfterUpdate()     '20190513
        If InStr(Email, "@") = 0 Or InStr(Email, ".") = 0 Then        
            MsgBox "E-mail not valid!"
            DoCmd.CancelEvent
            CheckBox1 = False
            With Me.Email
                    .SelStart = 0
                    .SelLength = Len(Me.Email)
                End With
            'Me.Email = Null
            Exit Sub
        End If
        If Not IsNull(Email) Then
            If Not IsEmailAddress(Email) Then   '20190513
                MsgBox "E-mail not valid!"
                CheckBox1 = False
                DoCmd.CancelEvent
                With Me.Email
                    .SelStart = 0
                    .SelLength = Len(Me.Email)
                End With
                'Me.Email = Null
                Exit Sub
            End If
        End If
End Sub

I commented out the Me.Email = Null because I want the user to see the false entered Email, but as I mentioned before, I dont want the record to be saved.

 

[theDBguy]

Hi. Data validation is better performed using the BeforeUpdate event. Try moving your code to the BeforeUpdate event of the Email textbox. You can then cancel the event if the email address entered is invalid by using something like:

Cancel=True

Hope it helps...

 

[Deleted member 147267]

Often, if you use the BeforeUpdate event and Cancel accordingly the text gets selected. You say that you select the control before trying to select the text but I'm not seeing that in the code.
You realize that .@Something will pass your test?
EDIT - disregard. You probably handle that in the email function call that I missed.

 

[Mark_]

Why are you both checking for "@" and "." FIRST, then calling your "IsEmailAddress" function? I'd have this all in one rather than two separate checks.

 

[Hello1]

Hey Mark_, was an old code the first part so I didnt remove yet but now I did.
Thanks all, now it works as I want it to.

Private Sub Email_BeforeUpdate(Cancel As Integer)   '20190513
    If Not IsNull(Email) Then
        If Not IsEmailAddress(Email) Then   '20190513
            MsgBox "E-mail isnt valid!", vbCritical, "Title"
            CheckBox1 = False
            Cancel = True
            With Me.Email
                .SelStart = 0
                .SelLength = Len(Me.Email)
            End With
            Exit Sub
        End If
    End If
End Sub

One more question, does it matter where I put the Cancle = True, before or after the MsgBox?

 

[theDBguy]

One more question, does it matter where I put the Cancle = True, before or after the MsgBox?

I don't think it matters. I use it right away as soon as I want to cancel the update. For example:

If Not IsValid Then
    Cancel=True
    blah blah blah...
Else
    blah blah blah...
End If

Hope it helps...

 

[The_Doc_Man]

Just for the record:

If you are in control A and do something that would naturally flow to control B (e.g. a TAB key) BUT your code does an explicit C.SetFocus, the A.LostFocus event WILL fire and you cannot cancel that event - because it doesn't have the capacity to be canceled. Events for B won't fire, but C.GotFocus will - IF you can set focus there legally, which is a different issue.

You also cannot cancel .AfterUpdate because that is sort of like closing the barn door AFTER all of the horses have already escaped. .BeforeUpdate, you can cancel. I'm also fairly sure you cannot cancel a .Exit because it implies that something else has happened to disengage from the exiting form.

The whole point with events is that the named event has TWO parts. There is the stuff that Access MUST do and there is the stuff that you WANT to do. Even if you leave the event slot blank in the Events property list, Access does its part for the event and you can't cancel it. Once you start down certain logic paths, there is no stopping the progress of the event. Which is why not every event has the Cancel option.

In the sequence you quoted, once the Update is allowed (by NOT canceling the .BeforeUpdate event), you WILL execute the .AfterUpdate event because the update HAS occurred. At most, you can put logic in your code so that your value-added code will not execute in a given sequence. But the Access part will behave normally.