USING ACCESS 2000'S NEW FORM FEATURES
Access 2000 contains some handy enhancements to forms requested by developers. You might want to take advantage of them in your applications. The examples for the following sections can be found on Chap09.mdb on the accompanying CD-ROM in the ExamplesChap09 folder.
Using the Form Recordset Property
In past versions of Access, you could use the RecordsetClone property to retrieve a recordset object containing a form's underlying data. This technique is still valid in Access 2000. Unfortunately, changes to a recordset obtained via RecordsetClone happen independently of the form itself. For example, record navigation on the form isn't reflected in such a recordset.
Access 2000 goes a step beyond this by exposing the form's actual recordset—not just a clone—via the Recordset property. You can now manipulate the data on a form precisely like you manipulate a recordset in code. What's even better is that this property is read/write—you can build a recordset in code and then hook it up to a form.
Caution
When working with an MDB, a form's recordset is always a DAO recordset—even when you're using ADO in your database. Failure to take this into account can lead to unexpected errors at runtime.
To see the form Recordset property in action, look at the CustomersRecordset form and its friend, CustomersRecordsetRelations (see Figure 9.1). Both forms can be found in Chap09.mdb, located in the ExamplesChap09 folder on the CD-ROM.
Figure 9.1. The Recordset property keeps these forms in sync.
Both forms are bound to the Customers table. When you click the Show Relations button on the CustomersRecordset form, the CustomersRecordsetRelations form opens to the same record, but it's displaying CustomerRelations data in a subform.
Note
The subform on the CustomersRecordsetRelations form takes advantage of a new feature in Access 2000—namely, the ability to bind a subform directly to a table or query. Its source object is specified as Table.CustomerRelations, which causes the appropriate fields from that table to appear in a datasheet.
Now actions on these forms are completely in sync. For instance, if you move to the next record on one form, the other form moves to the next record, too. Listing 9.1 shows the code to create this effect.
Listing 9.1. Chap09.mdb: Connecting Forms via the Recordset Property
Private Sub cmdShowRelations_Click()
DoCmd.OpenForm "CustomersRecordsetRelations"
Set Forms("CustomersRecordsetRelations").Recordset = Me.Recordset
End Sub
|
This code simply opens the “child” form and sets its Recordset property. Achieving this effect in previous versions of Access was very difficult.
Using the Dirty Event
Access 2000 now fires a form-level event when a record is first dirtied in the user interface. (In a database, you dirty a record when you make any change to the data in the record.) You can use this event to do any special processing, and the event can be canceled so that, if necessary, you can deny users the ability to make changes.
The CustomersDirty form demonstrates the Dirty event by adding (Changed) to the window caption when a record is first changed. Many Windows applications use this technique to stress to users that there are unsaved changes and they should therefore be careful. You can see this in Figure 9.2.
Figure 9.2. This form's window caption is modified when its data is dirtied.
When the changes are committed, the caption is changed back in the AfterUpdate event. Again, the code to do this is very simple (see Listing 9.2).
Listing 9.2. Chap09.mdb: Trapping Changes on Forms by Using the Dirty Event
Private Sub Form_AfterUpdate()
Me.Caption = "Customers"
End Sub
Private Sub Form_Dirty(Cancel As Integer)
Me.Caption = "Customers (Changed)"
End Sub
|