Access Cookbook - Ken Getz [63]
4
acPageFooter
Form or report page footer section
5
acGroupLevel1Header
Group level 1 header section (reports only)
6
acGroupLevel1Footer
Group level 1 footer section (reports only)
7
acGroupLevel2Header
Group level 2 header section (reports only)
8
acGroupLevel2Footer
Group level 2 footer section (reports only)
In the code, you'll find expressions like the following:
Me.ZipPostalCode
and
Me.Section(acPageHeader)
In these expressions, the built-in object named Me always refers to the form in which the code is running. (It's actually slightly more complex than this—"Me" actually refers to the class containing the code, not the form, but that's a topic best left for a more advanced book.) Whenever you see code that contains "Me." you can be assured that the code is referring to an object on the form, or a field provided by the form's data source. You may also find code that uses "Me!" syntax. For all intents and purposes, this is equivalent to the "Me." syntax, and you should simply treat the two syntaxes the same. At this time, the "Me." syntax is preferred because it provides a very slight performance edge. In addition, the "Me." is almost always optional—you'll see cases in this book in which the code simply doesn't include this prefix when referring to controls and fields provided by a form.
In the sample report, which prints one record per page, four controls need to be turned on or off together: the label with the message, two labels with Wingdings pointing-hand graphics, and a rectangle surrounding the other controls. Placing all of these controls in one section and making the section as a whole visible or invisible is more efficient than making each control visible or invisible. Often, however, you'll need to print a message on a report that contains multiple records per page. For example, you might print the word "Outstanding" alongside a sales report when a salesperson has had more than $1 million in sales for a year. In this case, you'll have to use code that works with the Visible property of individual controls, such as that shown here:
If Me.Sales >= 1000000 Then
Me.txtOutstanding.Visible = True
Else
Me.txtOutstanding.Visible = False
End If
If you look at rptMailingByZip or rptMailingByZipWithCondition in design view, you may notice an odd expression as the ControlSource property for the txtCityStateZip control in both reports:
=([City]+", ") & ([StateProvince]+" ") & [ZipPostalCode]
Note that we have used both the + and & concatenation operators in this expression. These two operators have a subtle difference: When you use + and one of the concatenated strings is Null, the whole expression becomes Null; when you use &, the null part of the expression is ignored. The effect caused by the + operator is termed null propagation, which you can short-circuit by surrounding that part of the expression in parentheses. The net effect of all this is that in the previous expression, if City is Null, City and the comma and space following it will drop out of the expression. Likewise, if StateProvince is Null, it and the two spaces to which it is concatenated will drop out of the expression. Selective use of the + concatenation operator is both easier to read and more efficient than using one or more IIf functions.
You may find it useful to collapse an If...Then statement down into a single expression. For example, the code in the sample report can be collapsed down to the following single statement:
Me.Section(acPageHeader).Visible = (Left(Me.ZipPostalCode, 2) = "98")
The second code example could be collapsed into this single statement:
Me.txtOutStanding.Visible = (Me.Sales >= 1000000)
It's up to you to decide which syntax you'd like to use. Some developers like the full If...Then statement. Others like the compactness of the single expression.
3.5. Create a Page-Range Indicator on Each Page
Problem
You're creating a report that contains a large number of items. To make it easier to see the range of items on each page, you'd like to create