Form Overview

Let's first get an idea of the internal workings of a form before you start building any form objects.

The Nifty Lions Database

For this chapter, you'll use the Nifty Lions database that's among the files you downloaded. This database is for a small mail-order company that specializes in clothing, jewelry, novelty items, and other items with a lion motif.

Download NiftyLionsChap11.mdb to a convenient folder on your hard drive and open it. (NiftyLionsChap11End.mdb shows the database after all exercises in this chapter have been completed.) The database is modeled on the Northwind sample database and has most of the same tables and fields. But I hope the simpler names and fewer records make it a little easier to work with.

Let's briefly review its relationships, as shown in Figure 11.1. (For a more hands-on view, choose Tools, Relationships to open the Relationships window.) All tables are related to at least one other, with referential integrity enforced. Because one order can have many items, and one item can be in many orders, tblMerchandise and tblOrders have a many-to-many relationship. A third table, tblOrderDetails, has been created as a linking table to bring them together.

Figure 11.1. The relationships of the Nifty Lions database.

Understanding a Form/Subform

Forms are often accompanied by subforms. Let's take a closer look at the form/subform shown in Figure 11.2.

1.	In the Database window, click the Forms button.
2.	Right-click frmOrders and select Copy. Right-click anywhere in the Forms section of the Database window and select Paste.
3.	Rename the copied form frmOrdersPractice and click OK. Open the form (see Figure 11.2).

Figure 11.2. A form/subform created from several tables.

The form won't win any design prizes, nor does it have all the data you might want on an orders form. But it will be useful for exploring key form tools and functions.

The form combines data from several tables, including Orders, Customers, Shippers, and Order Details. As you'll see throughout the chapter, to combine fields from several tables in a single form robustly, the tables must be tightly bound through relationships. The scheme in the Relationships window demonstrates that such integration exists.

At the top of the form are fields that show the name and address of the customer, as well as key order data such as date shipped. At the bottom is a datasheet that shows the order details for each order. The datasheet is the subform. I use form to refer to the entire form (both form and subform), main form to refer to the fields on top, and subform to refer to the datasheet.

Note that there are two sets of navigation buttons. The buttons all the way at the bottom are for the form; they are used to move to specific orders. The navigation buttons in the middle of the form move the focus from record to record in the order details subform. This second set of navigation buttons is not overly useful here because each order has relatively few order detail records. But for longish datasheets whose records remain partially hidden, the buttons are helpful.

Detail Section

Click the View button at the far left of the Form View toolbar to go to Design view (see Figure 11.3). As is true with most forms, the Detail section is by far the most important and contains nearly all of the form's actual substance. Directly below the Orders title are the label/text box pairs that determine the content of the main form. The label on the left (Last Name, First Name, and so on) is just a caption, a mere string of text that tells you what's in the field. The text box on the right controls the content and display of the actual field values. Let me re-emphasize this important distinction: The label control simply contains static text that describes the field; the text box contains the actual values.

Figure 11.3. The Orders form in Design view.

The Overnight control is an option group, which I describe later in the chapter. Below the fields is the large OrderDetails subform control. Later in the chapter, you'll re-create it.

Form Header/Footer Sections

The Form Header appears once at the top of the form and is usually used for a title, as it is here. The Form Footer appears once at the end. Currently, it doesn't exist: Its height is 0 and, by extension, there are no controls. You might use the footer for command buttons or perhaps some general instructions on using the form.

The form header/footer always appear as a couple. They can be toggled on and off (that is, made to appear and disappear) by choosing View, Form Header/Footer. But if you select this command while the sections are in view, Access deletes both the sections and their controls (you will get a warning message before deletion).

Page Header/Footer

The mechanics of the Page Header/Footer are similar to those of the Report Header/Footer. They differ markedly in their content and objectives, however, as the following exercise demonstrates:

1.	You should be in Design view. On the menu bar, choose View, Page Header/Footer. Page Header and Page Footer sections 0.25 inch long appear on your form. Both are currently empty.
2.	Drag any field on the field list (say, CustZIP) and drop it anywhere in the Page Header section (see Figure 11.4). Figure 11.4. The CustZIP field has been added to the Page Header.
3.	Drag the same field and drop it anywhere in the Page Footer.
4.	Click View to switch to Form view and attempt to find the CustZIP data you just added. Hmm, where are these values? Controls in the Page Header and Footer appear only when you print the form. Many forms are printed only occasionally or never. Moreover, page numbers are less crucial in forms than they are in reports. You might find that you use the page header/footer infrequently in forms.
5.	Click View to return to Design view. Choose View, Page Header/Footer and confirm the deletion.

The Data Source

In a form, controls have property sheets, sections have property sheets, and the form itself has a property sheet. You can find the data source of the form's records in, you guessed it, the form property sheet.

1.	Double-click the Form Selector to view the property sheet (it's the small square at the very top left of the Form Design windowsee Figure 11.3 if you need help locating it).
2.	Click the Data tab and click in the Record Source property.
3.	Click the ellipsis (…) button at the end of the property. As you see, the source for the form's records is the qryOrders query (see Figure 11.5), which itself was built from underlying tables. The Customers and Orders tables have been added to the query. Several fields from the Customers table have been added to the design grid. Use the horizontal scroll bar to move to the last column. It contains all the fields for the tblOrders table. Figure 11.5. The Orders query in Design view.
4.	From the Customers field list in the query, double-click CustFax to add it to the design grid.
5.	In Design view of the form, find the field list and scroll to the end. (If the field list isn't in view, click the Field List button on the toolbar or choose View, Field List.) The CustFax field has been added and can be used to create additional controls.
6.	Close the query and save your changes. Close the form property sheet.