Access Cookbook - Ken Getz [56]
Follow these steps to convert your own forms to allow for multiple instances:
Add two buttons to your form, with captions like Create New Instance (named cmdViewAnother in the example) and Delete All Extra Instances (named cmdCloseAll in the example).
Add the following code to the Click event procedure of the Create New Instance button:
Private Sub cmdViewAnother_Click( )
Call acbAddForm
End Sub
Add the following code to the Click event procedure of the Delete All Extra Instances button:
Private Sub cmdCloseAll_Click( )
Call acbRemoveAllForms
End Sub
Add the following code to the Close event procedure for the form:
Private Sub Form_Close( )
Call acbRemoveForm(Me)
End Sub
Import the module basMultiInstance from 02-11.MDB.
To see this functionality in action, load and run frmCustomers from 02-11.MDB. Once it's open, click View Another Customer. This will create a new instance of the original form, with its own set of properties and current row. You can create as many new forms as you like and move from row to row on any or all of them. When you're done, click Close All Extra Copies, which will run code to delete all the extra forms. Figure 2-18 shows the original form, along with three extras.
Figure 2-18. Clones of frmCustomers with their own current rows
Discussion
Working with multiple instances of forms requires three skills: creating the new forms, storing their references, and deleting them. All three topics center around user-defined collections. These collections allow you to add and delete items at will, based on either their position in the collection or a string value that uniquely identifies each element. This example uses each form's hWnd property (its window handle) to identify the form in the collection.
In Access, each form stored in the database can be viewed as its own "class" of form: it's an object that you can replicate in memory, using the New keyword. The following statement will create a new instance of the form named frmCustomers:
Set frm = New Form_frmCustomers
Form_frmCustomers is the object type, and its name originates from its type (Form) concatenated with the actual class name (frmCustomers). Once you've executed this line of code, frm refers to a new, invisible form. You can set its properties, if you like, or make it visible with the following statement:
frm.Visible = True
If you want to refer to your new form later, you'll need to store a reference to it somewhere. In the example code, we used a user-defined collection. When you create a new instance of the form, the code adds that form reference to the collection so you can find the form, under program control, when you need to refer to it again.
LIFE SPAN OF A FORM
The variables that refer to the newly created forms must have a life span longer than that of the procedure that created the forms. In this case, the form references are stored in a module-level collection, so their lifetime is the same as the database itself. When you create a new instance of a form, if the variable referring to that form goes out of scope, Access destroys the new form instance. Because you'll want your forms to hang around longer than that, make sure your form variables have a static, module, or global scope.
In this example, the acbAddForm subroutine creates and stores the new form references. As it creates a new form (when requested to do so by that button click on frmCustomers), it adds the form reference to the collection of forms. A collection's Add method allows you to add the item and optionally store a unique string value describing the value at the same time. In this case, the code stores the form's hWnd property, converted to a string, as its unique identifier. The code also increments a variable that keeps track of the number of instances and places the new form at a convenient location before making it visible. This is the acbAddForm subroutine:
Private colForms As New Collection
Private