Hi All,
First, I'm sorry to hear about the death of David Fenton who answered
a couple of my questions and whose answers to others I found useful.

I have a form built with the wizard based on a table. One field in
the table is an ID to another table. The other table is tblRequestor,
theat has columns ID, RequestorLastName, RequestorFirstName,
RequestorType. I have a combo box based on a query to tblRequestor
that shows. So int he combo box the user sees a list of folks and
when he chooses one, the ID field in the form is populated and gets
saved in the underlying table. I have a couple of fields in which I
added to the form that display the last & first names of the requestor
and the requestor type. I use the combo box change event to update
those fields whenever the user uses the combo box, like this:

Private Sub cmbRequestor_Change()
MsgBox ("Change combo box")
txtReqLastName.Value = cmbRequestor.Column(1)
txtReqFirstName.Value = cmbRequestor.Column(2)
txtReqType.Value = cmbRequestor.Column(3)
End Sub

This works well. However, I cannot seem to work out which event is
triggered by using the arrows at the bottom of the form (the built in
ones that access puts there). I should similarly update the
txtReqLastName.Value and other fields when the user arrows to the next
record. What's the event? And is there a way to step through the
debugger and have it tell you about every form and object event that
occurs?

Any help appreciated.

Mike

On Jan 25, 11:47*am, Gilgamesh <michaelsfl... (AT) gmail (DOT) com> wrote:
Are you referring to Navigation buttons? The Oncurrent event might be
useful. When you move to a new record the OnCurrent event is
executed.

You can then have code like this in the OnCurrent event
If Not Me.NewRecord then
'...initialize processes for an existing record
Else
'...initialize processes for a new record
Endif

On 2012-01-25 6:47 PM, Gilgamesh wrote:
Hi Mike,


You could use the Form_Current event, which is triggered every time the
record changes. There is no need to hook into the arrows at the bottom
directly, since this event is always triggered when those buttons yield
a different record. For the order of the various events, see
http://office.microsoft.com/en-us/ac...005186761.aspx

However, if you simply set txtReqLastName.ControlSource (et al) to the
function itself, you do not need ANY code as the control will be
automatically recalculated whenever cmbRequestor changes. So, setting
the ControlSource of the 3 text fields to :

=cmbRequestor.Column(x)

will have the desired effect without any code.


HTH

Jan T

On Jan 25, 10:45*am, Jan T <access... (AT) yahoo (DOT) com> wrote:
Brilliant! That's exactly what I needed. Thanks for the help.

On Jan 25, 10:33*am, Patrick Finucane <patrickfinucan... (AT) gmail (DOT) com>
wrote:
This works too. Thank you for the help.

On 2012-01-25 8:29 PM, Gilgamesh wrote:
Hi Mike,


Happy to help. Note that this approach is fine for single forms, but not
very suitable for continuous forms and datasheets. Once you get to a
certain number of records the performance will become sluggish, since
all controls need to be recalculated continually in response to many
different events.

To avoid this, you could add the required "extra" information to the
query underlying the form itself (add the Requestor table, make sure it
is properly linked, add the desired fields) and then bind to those
fields directly. Access will still refresh the information whenever a
different Requestor is selected, but this solution resolves your entire
issue at the recordset-level itself, thus avoiding all the complexity of
code, functions and calculations and providing the best possible
performance at the same time.

HTH2

Jan T