Database development and training for Birmingham and the midlands
Specialists in Microsoft Access and Visual Foxpro database training and development
I am happy to hear from existing clients but I am taking no new calls.
Standard Access navigation buttons
Microsoft Access provides basic navigation buttons as standard on any form you design and you have to set theproperty 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 itsproperty 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 noof 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.
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.
DoCmd.Close acForm, Me.Parent.Name
Private Sub Sub firstButton_Click()
DoCmd.GotoRecord acDataForm, Me.Parent.Name, acFirst
Private Sub Sub previousButton_Click()
DoCmd.GotoRecord acDataForm, Me.Parent.Name, acPrevious
Private Sub Sub nextButton_Click()
DoCmd.GotoRecord acDataForm, Me.Parent.Name, acNext
Private Sub Sub lastButton_Click()
DoCmd.GotoRecord acDataForm, Me.Parent.Name, acLast
As a bonus in Access 2007, you can set theproperty 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