Access Cookbook - Ken Getz [43]
Discussion
There are three other methods that you can use to create multipage forms, but each of these methods requires more work than using the Tab control:
You can create a continuous form with page breaks in between the pages. If you open the form in dialog view, the user will be prevented from maximizing the form. You can write code utilizing the GoToPage method of the form to navigate from page to page.
You can use multiple subforms, placing each of the subforms on the main form and setting all but one of them to be invisible. In the AfterUpdate event of the option group, you can make the current subform invisible and the new one visible. This method can be cumbersome because working with long multipage forms can be awkward. This method also consumes more system resources than the method shown in this solution.
You can create one subform control and, in reaction to pressing buttons in the option group, change the SourceObject property of the subform control. This is a very "neat" solution, because there's only one subform on the main form (as opposed to four in the previous alternative). The drawback here is that changing the SourceObject property is quite slow.
2.6. Provide Record Navigation Buttons on a Form
Problem
You'd like to provide some mechanism for allowing users to move from row to row on a form, but you think the navigation buttons Access provides are too small and unattractive. Also, you can't control when the user can or can't move to another row.
Solution
Access provides navigation buttons for you to use on forms, allowing you to move easily from row to row. However, you can neither move nor resize these buttons, and you can't change anything about their appearance.
You can create your own buttons, place them on a form, and have each button use the GoToRecord macro action. Unfortunately, this has two drawbacks:
If you attempt to move to the previous or next row and you're already at the end of the recordset, the macro will fail. The GoToRecord macro action just isn't smart enough to work in this case.
Your buttons will always be available, giving no indication of when you can use them.
To avoid errors, you must use VBA. This solution demonstrates the steps you can take to add the appropriate code to your application so that navigation buttons will move you safely from row to row and shows how to disable the navigation buttons when they are unavailable. The form frmNav in 02-06.MDB (see Figure 2-11) works this way. You can load it and give it a try before attempting to build your own. Use the navigation buttons to move from row to row (there are only a few rows in the table so far). Note that, as you move around in the table, the appropriate buttons become enabled and disabled. Also try using the PgUp and PgDn keys. You'll see that the appropriate buttons still become disabled as necessary. Try entering a row number into the text box in the navigation controls; when you leave the text box, you will move to the selected row number.
Figure 2-11. The frmNav form
Follow these steps to include this functionality in your own applications:
Set your form's properties as shown in Table 2-4, removing the form's scrollbars and built-in navigation buttons. (Because this method works only for scrolling through rows of data, your form must also have its RecordSource property set so that the form displays rows of data.)
Table 2-4. Property settings for forms to remove the built-in navigation buttons
Property
Value
ScrollBars
Neither
NavigationButtons
No
Copy the buttons from frmNav, or create your own five buttons on your form. Do not use the Access Button Wizard to create your buttons, because it will add inappropriate code to the buttons; you want to be able to supply the code yourself. If you create your own buttons, you can add pictures from Access's selection of pictures. Click on the Build button to the right of the Picture property on the properties sheet for each button. Also, create