Navigating on forms...

M

magmike

Is there a way to make your form operate like a browser with a forward
& back button?

And I don't mean sequentially through the records the form is bound
through, but as far as history, or visited records per se.

For example, I do a search on my form and pull up Acme Printing
(record # 103). While looking at their record, I get a phone call from
Johnson Marine (record # 671), so I therefore go to their record on
the form. Once done with call and their record on the form, I simply
hit the "Back Button" to return to Acme Printing.

Thanks in advance for you help.

magmike
 
T

tina

there's no built-in way to do it, but you could probably set up your own
system. i've never tried it, but you create a "history" table, to hold the
form table's primary key value. then add code to the form's Current event
procedure, to write the current record's primary key value to the history
table. set your back button to do a Find where the form's primary key = the
value in the history table.

that would give you a simple "go back one" action. with more work and
thought, you might be able to expand the history to multiple records, and
hold "x" number of records in the history table between sessions.

hth
 
M

magmike

there's no built-in way to do it, but you could probably set up your own
system. i've never tried it, but you create a "history" table, to hold the
form table's primary key value. then add code to the form's Current event
procedure, to write the current record's primary key value to the history
table. set your back button to do a Find where the form's primary key = the
value in the history table.

that would give you a simple "go back one" action. with more work and
thought, you might be able to expand the history to multiple records, and
hold "x" number of records in the history table between sessions.

hth










- Show quoted text -
Click to expand...

- Or perhaps on the id field's OnUpdate? What exactly does OnCurrent
cover?

Or, perhaps - add a "lastvisited" field to the primary table, and then
the back button would resort the form based on lastvisited DESC? If
you think that's a decent idea, how would you go about updating that
field with the current date/time when the record is brought into the
form?
 
D

Douglas J. Steele

The Current event fires every time a different record in the form's
underlying recordset becomes active (i.e.: becomes the current record),
whereas the Update event only fires when you make a change to the data in
the current record. Therefore the Current event would be the correct one.

Putting a last visted field in the primary table would be a mistake, since
that would cause problems if you had more than one concurrent user for your
application.
 
M

magmike

The Current event fires every time a different record in the form's
underlying recordset becomes active (i.e.: becomes the current record),
whereas the Update event only fires when you make a change to the data in
the current record. Therefore the Current event would be the correct one.

Putting a last visted field in the primary table would be a mistake, since
that would cause problems if you had more than one concurrent user for your
application.

--
Doug Steele, Microsoft Access MVPhttp://I.Am/DougSteele
(no private e-mails, please)










- Show quoted text -
Click to expand...

Thanks. I'd probably have done it that way.
 
Top