INCREASING TABBED FORM PERFORMANCE
In the days before Access 97, the way most developers created multiple page forms was by simply using the Page Break control and the GotoPage method off the Form object.
As of Access 97, you now have the built-in Access native Tab control to use. Although you can put fields and controls directly on all the pages of the Tab control, this can sometimes really bog down the loading of the form. You can also put subforms on some of the pages. The problem when you start getting a number of pages, even using subform controls on them, is that performance can degrade pretty rapidly.
Tip
If you're using a Page Break control with the GoToPage method, you can now use the Cycle property to help control how your control keys (such as Page Down and Page Up) are used. This property also allows you to specify whether to cycle to the next record and/or page when the last field is reached. The settings are as follows:
All Records—When the last field is reached on a form, the cursor continues to the next record.
Current Record—The cursor stays on the current record when the last field is reached and simply cycles around to the first field.
Current Page—The cursor stays on the current page and cycles to the first field on the page. This is useful only when a form has multiple pages.
One way to enhance performance is to bind subforms to their SourceObject properties later during runtime. This works especially well for forms that have a good number of pages on the Tab control but don't necessarily use them all that often.
To demonstrate this, let's look at the form CustomerTabbedFormLateLoadExample. This form consists of three pages on the tabInfo Tab control. The first page just has the data right on it so it displays when the form is opened. The other two pages, Relations and Rental History, load the first time the tabs are chosen for those pages. If you look at Figure 9.12, notice that the SourceObject property of the subCustomer2 subform control isn't set, although the Link Master Fields and Link Child Fields properties are set.
Figure 9.12. The SourceObject property is set at runtime for this subform control.
The Rental History page is set up basically the same way.
Tip
A good idea is to have the subform controls that will have their SourceObject properties set at runtime also have their Visible property set to False. That way, you can set SourceObject first and not have the control flash at all.
The main work for this technique is performed in the Tab control's OnChange event, shown in Listing 9.7.
Listing 9.7. Chap09.mdb: Loading a Subform Control at Runtime
Private Sub tabInfo_Change()
Select Case tabInfo
Case pgRelation
If Len(Me!subCustomer2.SourceObject) = 0 Then
Application.Echo True, "Loading Page, Please wait..."
Me!subCustomer2.SourceObject = "CustomerSub2Relations"
Me!subCustomer2.Visible = True
Application.Echo True
End If
Case pgHistory
If Len(Me!subCustomer3.SourceObject) = 0 Then
Application.Echo True, "Loading Page, Please wait..."
Me!subCustomer3.SourceObject = "CustomerSub3RentalHistory"
Me!subCustomer3.Visible = True
Application.Echo True
End If
End Select
End Sub
|
For the Relations and Rental History pages, the steps are the same:
1. |
Test the current value of the tabInfo control against the constants assigned for the pages. (These were assigned in the Declaration section of the form's class module.) Here are the constants listed for you: Const pgMain = 0 Const pgRelation = 1 Const pgHistory = 2 |
Note
The constants were assigned to make testing for the pages simpler. The constant pgMain isn't actually used for this example.
That's it. The beauty behind this technique is that
The pages aren't loaded if they aren't used.
Each page is loaded only once if it is used.
The only downside is that it takes more effort to set up the form because you have to create the subforms, rather than just slap the data on the main form, and then you have to create the code. After you do this on a couple of key forms, you will definitely see a big benefit immediately.