Standard Access navigation buttons
Microsoft Access provides basic navigation buttons as standard on any form you design
and you have to set the property to
"No" in order to remove them. These are popular with users because the buttons are a
familiar way of moving between records.
Although the Access navigation buttons are familiar, they are not perfect. Some users
find that they are just too small to be usable. This is a problem whenever you have
users who don't have fine control over the movement of the mouse. This might be because
the users are older or it might be because they're trying to use a laptop in awkward
surroundings.
The solution for both these categories of user is to suppress the built-in buttons and to
provide some nice, large buttons as a replacement as in the example opposite. This is
easy enough because the Control Wizard will automatically write the VBA code for the
buttons' click events.
Although it's easy enough, creating these buttons adds extra work to the design of
every form and your application will look rough and unfinished if the buttons aren't
absolutely the same on every form.
The answer is to use a subform.
Navigation buttons on a subform
It's not obvious from the first screenshot but the five navigation buttons are
actually held on a subform. There's no reason for the user to know about this and it's
very easy to hide the edges of the subform by setting its
property to "Transparent". This subform can be
used on every form in a database, saving you a lot of time and giving a nice consistent
look to the application.
The navigation subform is very simple. It has no
of its own and just holds the five buttons, each with a snippet of VBA code behind it.
The code behind the buttons is based on the standard code that is generated by the
Control Wizard. The only additions are needed because the subform is never navigating
through its own data. Instead we have to specify another parameter in the calls to
DoCmd.GotoRecord so that it will move through the data
associated with its parent form.
Similarly we have to tell the Close button to close the parent form rather than closing
its own form and any extra buttons you might like to add, such as "Add", "Find" or
"Delete" would need similar modifications.
VBA code
This is a simplified version of the code and lacks any error handling. A real world
form has to check for beginning and end of file so that the user can't run out of
records.
Private Sub closeButton_Click()
DoCmd.Close acForm, Me.Parent.Name
End Sub
Private Sub Sub firstButton_Click()
DoCmd.GotoRecord acDataForm, Me.Parent.Name, acFirst
End Sub
Private Sub Sub previousButton_Click()
DoCmd.GotoRecord acDataForm, Me.Parent.Name, acPrevious
End Sub
Private Sub Sub nextButton_Click()
DoCmd.GotoRecord acDataForm, Me.Parent.Name, acNext
End Sub
Private Sub Sub lastButton_Click()
DoCmd.GotoRecord acDataForm, Me.Parent.Name, acLast
End Sub
Access 2007
As a bonus in Access 2007, you can set the property
to "Yes" on the "Previous" and "Next" buttons and the database will keep moving through
the records as long as the user keeps the mouse button pressed. Obviously, you don't
need an autorepeat on "First" and "Last".
A minor problem with Access 2007 is that the Control Wizard generates an Access macro
rather than program code in Visual Basic
|
