AfterUpdate event does not fire until focus moved to another control

[GraeagleBill]

I an app with the following control:




The AfterUpdate event code is:

Private Sub tbCellPhone_AfterUpdate()
If Not IsNull(Me.tbCellPhone) Then Me.tbCellPhone = FmtPhoneNos(Me.tbCellPhone)
End Sub

The event does not fire after data is entered into the filed and Enter is pressed. The event fires AFTER I click on another filed. I can't even get the AfterEnter to fire either.

What would cause the delay? (I have 2 other apps that are structured in exactly the same way and the AfterUpdate event fires exactly as expected.)

[Missinglinq]

I can't even get the AfterEnter to fire either.

Not really surprised, as to my knowledge, at least thru 2007 (and certainly not in 2003) there is no 'AfterEnter' event!

A Control's AfterUpdate event is not going fire until data is entered or changed in the Control, and the user either moves to another Control, closes the Form or closes Access itself. Simply hitting <Enter> won't, in and of itself, won't cause it to fire...unless...you have the Move After Enter option, for your installation of Access, set to Next Field or Next Record. It sounds as if it's set to Don't Move in the installation of Access you're currently using. That's the first thing I'd check. Don't remember exactly where to find that option in 2003, but in 2007 it's in Options - Advanced - Editing, and should be similar in 2003.

Linq ;0)>

[GraeagleBill]

Linq,
We must have some sort of misunderstanding about what I was trying to explain, as I have several counter-examples to what you're saying. Certainly about A2003 not having an OnEnter event for text box properties.
I'll do some tests in the AM to see if my db is either corrupted or getting confused with multiple forms where telephone numbers can be entered. Like maybe more than one text box with the same name but in different forms. The controls collection maybe corrupted?
Bill

[Missinglinq]

When things go wonky corruption is always a possibility! Although we usually think of Forms or entire Databases when we speak of corruption, individual Controls, such as Textboxes, can and do become corrupted. The test and the fix are one and the same; deleting the Control then re-creating it! If it was corrupt, you've verified the fact and solved the problem! If not, you've only lost a minute or two!

Linq ;0)>

[rpeare]

Try using the ON EXIT property rather than the AFTER UPDATE property to call your function. or alternately using an input mask to set up your formatting rather than relying on the function to do it (I'm guessing that's what fmtPhoneNos is doing), unless fmtphonenos is also validating length of the phone number etc as well.


Can you show the code for your function?

[Missinglinq]

AfterUpdate is the appropriate event for this kind of thing, but it only fires

after changed data in a control or record is updated

and despite the OP saying

I have 2 other apps that are structured in exactly the same way and the AfterUpdate event fires exactly as expected

unless code is in place to Call the AfterUpdate event (using the Control's KeyDown event and trapping the <Enter> key...and GraeagleBill hasn't mentioned such) the AfterUpdate event will not fire on a Textbox until focus moves elsewhere! How could it? Until you leave the Control, Access doesn't know that you are thru entering data and ready to save the input!

OnExit would work, of course, but firing his code before actually exiting the Textbox was his concern here. Also, not that it's a big point, but using OnExit would mean that the code would execute anytime the user tabbed thru the Control, instead of only when data had been entered/changed.

Linq ;0)>

[GraeagleBill]

Finally! The troublesome front-end db has been around for many years and I failed to notice the "Enter Key Behavior" for text boxes defaulted to "New line in field". Thus, when a string was entered and the enter key pressed the cursor continued to blink but was actually blinking on the "next line". Obviously, if the control's height can't grow beyond "one line" then one cannot observe what's happening. The A2003 Enter key default is move to next field in the tab sequence. Once I set the "Enter Key Behavior" for the offending tb controls to "Default" then the issue cleared up.

rpeare's post mentioned the use of function "FmtPhoneNos" versus perhaps the use of an input mask. The function operates on phone numbers taking into account the apps regional settings with respect to the installations default area code. In the current installation, the default area code is for north-east California, 530. In the case of area code 530, there are 639 valid prefixes among all the landlines and cell phones. If the user enters a string from which the function can isolate 7 discrete digits, the user is informed as to what type of phone relates to the first 3 digits and the nominal city to which it pertains. If defaulting to area code 530 is acceptable, the string is formatted to "(530) nnn-nnnn". Otherwise, the user can change the area code as appropriate. If the function can isolate 10 discrete digits, then the area code is taken to have been included in the string and any user interaction is avoided.

[GraeagleBill]

Sorry Linq, I meant "OnEnter" event.

[pbaldy]

For the record, the On Enter event is when focus arrives at the control, not when Enter is pressed while making an entry in it. From Help:

When you move the focus to a control on a form (for example, by opening a form that contains one or more active controls, or by moving the focus to another control on the same form), the Enter and GotFocus events occur in this order:



Enter GotFocus

[GraeagleBill]

Hi paul,
Thanks for that little lesson. I don't recall ever having had the occasion to use the OnEnter event and my assumption about how it would be used was totally misconceived.
Thanks,
Bill

[pbaldy]

No problem Bill. I looked for you at Applebee's yesterday.