AfterUpdate?

J

John Keith

AfterUpdating a control in my forms detail section, The
detail-field_AfterUpdate event is triggered and calls another function that
directly re-populates an unbound text box in the forms header section via a
DAO SELECT reading the detail-fields from the underlying table. Even though
this is supposed to be AFTER the unpdate, it seems that the unchanged-data is
still buffered at the header level. The detail has 6 fields that can
possible be updated. Each of these fields will call the _AfterUpdate which
in-turn calls the SELECT to repopulate the unbound-header controls. None of
the detail fields afterupdate triggered event's subsequent SELECT, seem to
see the table updates.

If I force the header key to change to itself, by deleteing the last digit
of the key and rekeying, pressing enter, then the exact same SELECT routine
runs and the data is now properly refreshed.

How do I make the detail level calls from their AfterUpdate routines, truely
update in a manner that the SELECT will read the new values that were just
updated?

It appears that the detail level updates do not fully ripple back up the
chain until the form's header sees some kind of change. Is this by design?
How do I get around this issue?
 
M

Marshall Barton

John said:
AfterUpdating a control in my forms detail section, The
detail-field_AfterUpdate event is triggered and calls another function that
directly re-populates an unbound text box in the forms header section via a
DAO SELECT reading the detail-fields from the underlying table. Even though
this is supposed to be AFTER the unpdate, it seems that the unchanged-data is
still buffered at the header level. The detail has 6 fields that can
possible be updated. Each of these fields will call the _AfterUpdate which
in-turn calls the SELECT to repopulate the unbound-header controls. None of
the detail fields afterupdate triggered event's subsequent SELECT, seem to
see the table updates.

If I force the header key to change to itself, by deleteing the last digit
of the key and rekeying, pressing enter, then the exact same SELECT routine
runs and the data is now properly refreshed.

How do I make the detail level calls from their AfterUpdate routines, truely
update in a manner that the SELECT will read the new values that were just
updated?

It appears that the detail level updates do not fully ripple back up the
chain until the form's header sees some kind of change. Is this by design?


Sorry, but I am having trouble understanding what you want
to happen. Maybe a few comments will help clarify what's
happening.

A control's AfterUpdate event has nothing to do with saving
a record back to its table. The control AfterUpdate only
signals that the value of the control was changes by a
user's action.

The form's AfterUpdate event signals that changes to the
current record were saved to the table.

Changing a control's Value via VBA code does not trigger any
events. If you want to execute a control's events when
updating it through VBA, then call the event procedure
directly from your code. E.g.
Me.textbox = ...
Me.textbox_AfterUpdate
 
J

John Keith

The AfterUpdate routines needed "Me.Refresh" added before calling the code
that was reading those values for display in the header. Now the SQL selects
the newly updated values from the underlying table as I was expecting.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top