continuous form next record

[Scott]

i have a continuous subform that i'm trying to forcce the focus to the next
continuous record after the user modifies the last textbox control on a row.

i tried the below code on the afterupdate event, but get error "you can't go
to the specified record". any ideas to force focus from last control of the
row to the first control of the next row?

CODE:

DoCmd.GoToRecord , , acNext

 

[Marshall Barton]

i have a continuous subform that i'm trying to forcce the focus to the next
continuous record after the user modifies the last textbox control on a row.

i tried the below code on the afterupdate event, but get error "you can't go
to the specified record". any ideas to force focus from last control of the
row to the first control of the next row?

CODE:

DoCmd.GoToRecord , , acNext

That should be automatic if you set the form's Cycle
property to All Records

 

[Scott]

tabbing to next record works, but hitting enter after changing the record
makes focus jump to the first control on first row of continuous form. i
think this happening because i'm setting the forms record source with code
and doing so from the on current event.

is there any way to control after effects of hitting enter?

 

[Marshall Barton]

tabbing to next record works, but hitting enter after changing the record
makes focus jump to the first control on first row of continuous form. i
think this happening because i'm setting the forms record source with code
and doing so from the on current event.

is there any way to control after effects of hitting enter?

Hitting enter is not really the issue. It's going to a
different record (running the Current event) that's the root
of the problem.

Changing the form's RecordSource in the Current event is an
inherently strange thing to do. How can you ever hope to
navigate fro one record to another when the form's recordset
is changed at the same time???

 

[Scott]

i was forced to use the on current event to change recordsource because the
data displayed had to be shown in 2 modes - one for enter/edit data, 1 for
only viewing.

Reason for that is we needed to see some calculated fields on the subform's
data that could only be done with subqueries that of course, don't have add
ability.

 

[Marshall Barton]

Now I am really baffled. If you want to prevent a form's
data from being edited, why not just set the form's
AllowEdits, AllowDeletions and AllowaAdditions properties to
No???

But even that may not be needed if the record source query
is not updatable.