The AfterUpdate event for the Control holding the date/time data should, indeed, pop when it is being populated via the native DatePicker! By native, I mean the small DatePicker that Access 2007/2010, by default, shows when entering a Textbox that is Bound to Date/Time Field.
You have to move off of the Textbox that holds the data, or Close the Form, before it pops, but that's true of the AfterUpdate event of any Textbox, regardless of how it's populated.
If it's not exhibiting this behavior, best guess would be that the Control itself is corrupted. Although we think in terms of Forms or Databases when corruption is mentioned, Controls can and do become corrupted. Easy solution for that is to Delete then Re-create the Control.
Note that the above is said assuming that you are talking about the built-in DatePicker that came with versions 2007/2010. ActiveX and Form-based DatePickers are a different story! They populate the Textbox through code, and doing so will, indeed, not pop the Control-associated events.
Linq ;0)>
The Missinglinq
Richmond, Virginia
The Devil's in the Details!