Chapter 29: Building a Form

From the perspective of daily use, forms are the most important objects you’ll build in your Microsoft Office Access 2007 application because they’re what users see and work with every time they run the application. This chapter shows you how to design and build forms in an Office Access 2007 desktop application. You’ll learn how to work with a Form window in Design view to build a basic form based on a single table, and you’ll learn how to use the Form Wizard to simplify the form-creation process. The last section of this chapter, “Simplifying Data Input with a Form,” shows you how to use some of the special form controls to simplify data entry on your forms.

Note 

The examples in this chapter are based on the forms, tables, and data in  ContactsDataCopy.accdb on the companion CD included with this book. The results you see from the samples in this chapter might not exactly match what you see in this book if you have changed the sample data in the file. Also, all the screen images in this chapter were taken on a Microsoft Windows Vista system with the display theme set to Blue, and Use Windows-Themed Controls On Forms has been turned on in the sample databases. Your results might look different if you are using a different operating system or a different theme. We’ll discuss the Use Windows-Themed Controls On Forms option later in this chapter.

Forms and Object-Oriented Programming

Access was not designed to be a full object-oriented programming environment, yet it has many characteristics found in object-oriented application development systems. Before you dive into building forms, it’s useful to examine how Access implements objects and actions, particularly if you come from the world of procedural application development.

In classic procedural application development, the data you need for the application is distinct from the programs you write to work with the data and from the results produced by your programs. Each program works with the data independently and generally has little structural connection with other programs in the system. For example, an order entry program accepts input from a clerk and then writes the order to data files. Later, a billing program processes the orders and prints invoices. Another characteristic of procedural systems is that events must occur in a specific order and cannot be executed out of sequence. A procedural system has difficulty looking up supplier or price information while in the middle of processing an order.

In an object-oriented system, however, an object is defined as a subject that has properties, and you can invoke certain actions, or methods, to be performed on that subject. Objects can contain other objects. When an object incorporates another object, it inherits the attributes and properties of the other object and expands on the object’s definition. In Access, queries define actions on tables, and the queries then become new logical tables known as recordsets. That is, a query doesn’t actually contain any data, but you can work with the data fetched by the query as though it were a table. You can base a query on another query with the same effect. Queries inherit the integrity and formatting rules defined for the tables. Forms further define actions on tables or queries, and the fields you include in forms initially inherit the underlying properties, such as formatting and validation rules, of the fields in the source tables or queries. You can define different formatting or more restrictive rules, but you cannot override the rules defined for the tables.

Within an Access database, you can interrelate application objects and data. For example, you can set startup properties that prepare your application to run. As part of the application startup, you will usually open a switchboard form. The switchboard form might act on some of the data in the database, or it might offer controls that open other forms, print reports, or close the application.

Figure 29–1 shows the conceptual architecture of an Access form. In addition to operating on tables or queries in a database, forms can contain other forms, called subforms. These subforms can, in turn, define actions on other tables, queries, or forms. Events that occur in forms and subforms (such as changing the value of a field or moving to a new record) can trigger macro actions or Microsoft Visual Basic procedures. As you’ll learn when you read about advanced form design, macro actions and Visual Basic procedures can be triggered in many ways. The most obvious way to trigger an action is by clicking a command button on a form. But you can also define macros or Visual Basic procedures that execute when an event occurs, such as clicking in a field, changing the data in a field, pressing a key, adding or deleting a row, or simply moving to a new row in the underlying table or query.

Figure 29–1: An Access form can contain other objects, including other forms, and you can set some of its properties to define procedures that respond to events.

Several of the more complex forms in the Conrad Systems Contacts and Housing Reservations sample databases are automated with Visual Basic. Figure 29–2 shows a few of the automated processes for the frmContacts form in the Conrad Systems Contacts database. For example, printing the contact currently displayed in the form is triggered by using a command button.

Figure 29–2: Some of the automated processes for the frmContacts form include opening a dialog box to choose a contacts report and automatically filling in the city and state when you enter a postal code.

In addition to automating print options, code behind the frmContacts form automatically fills in the city and state when you enter a postal code and provides a graphical way to choose a date if you click the button next to a date. On the Events tab, when you enter a sale of a product to the contact, code automatically generates a product record.

Object-oriented systems are not restricted to a specific sequence of events. So a user entering a contact event in Access 2007 can open up a new form object in the Navigation Pane and start a search in a companies or products form window without having to first finalize or cancel work already in progress in frmContacts.