I am planning on adding a "DateLastUpdated" field to a record, and am trying to understand the difference between OnChange, OnDirty and Afterupdate.
Changes to the record are made on a single form. The form has a header with an unbound record-selection control and also a sub-form to a linking table. I want the DateLastUpdated to update whenever the value of text or combo controls in the main and subform are changed, but not when someone types in the header fields. The update should only occur if text/value is actually changed in a control, not just having gotten focus such as tabbing through or having focus as the records are scrolled through with pgup/pgdown.
Based on my reading so far, it looks like an Afterupdate event is the thing to use (rather than OnDirty) and to have the Afterupdate date-update action occur individually from each control that should cause it (including the fields of the subform).
Before I begin a massive coding change to all the forms and controls, I'd appreciate any recommendations, comments, or referals to pertinent writeups.
I'd agree with after update. I think dirty will only fire with the first keystroke, and change will fire with every keystroke. After update will fire only when the user has completed their changes, so it's the appropriate event for what you're doing. It won't fire if they just tab through the control.
Thanks. I seem to remember an in-depth discussion of all the peculiarities of the "On-" events, with examples of where to and where not to use them, but can't seem to find it. The stuff I've read in the past few days is also confusing on whether each event works only at the record level or also at the detail control level.
I'll see if anyone else responds, but will proceed with the job.
Both forms and controls have after update events. The control's would fire when it gets updated, the form's not until the entire record is being updated. Perhaps that's where your confusion comes from; they are two different events. The form doesn't have a change event and controls don't have a dirty event.
No, my confusion comes from some writeups that said that changes to unbound fields did not trigger the form's afterupdate event, but others that said they did. I was originally considering using the form's afterupdate rather than having to put an afterupdate event in each control's property. My concern was making sure that the event didn't fire when the unbound "name search box" in the formheader was used; but did occur when any bound record fields changed. I will probably just have to experiment to find out.
My second and seperate requirement is setting a new date when the data in the sub-form changes. Those fields are not part of the person record, but in a separate table that links the person with an item. Again, one writeup said any data in the form (and subform) would trigger, others said that only changes to the parent record fields would trigger the event.
btw, you don't happen to be in LV? I'm heading out there next week.
This is the way I remember
OnChange when the object is change
OnDirty a new record before it's save
Afterupdate. This when the field has lost focus moving to next field
hope this help
See clear as mud
the aim is store once, not store multiple times
Remember... Optimize 'til you die!
Progaming environment: Access based on my own environment: DAO3.6/A97/A2000/A2003 VB based on my own environment: vb6 sp5 ASP based on my own environment: 5.6 VB-NET based on my own environment started 2007 SQL-2005 based on my own environment started 2008 MYLE