Object Models

When an application consists of many smaller objects, as Access does, then we use the term Object Model to show those objects and identify the relationship between them. This is generally shown in a diagrammatic form, and you'll see occurrences of these diagrams later in the book, for the data access object models.

The Access 2002 Object Model is quite large, so we won't be showing it here. However, showing you a bit of the model and how the diagram looks can help to understand how some of the Access objects fit together:

At the top we have the Application , which is the main Access application. This contains several smaller objects and numerous collections of objects, such as the Forms collection, which contains instances of Form objects. Each of these Form objects contains other objects. There are also some objects, such as the DoCmd object, which don't have any collections belonging to them.

Remember that this is just a portion of the object model - if you want to look at the full model, then you can find it in the Access Help File, assuming that you have chosen a complete install, and therefore have the full Help Files installed. In the Contents tab, it's under: Programming in Visual Basic Microsoft Access Visual Basic Reference Microsoft Access Object Model. As this is a help file it allows you to drill down into the objects for a more detailed look. Otherwise we provide a cut-down version of the object model in Appendix D.

Using Object Models in VBA

Using object models in VBA is quite intuitive, because you can just use a period to separate the various objects and collections. For example, to get to the Forms collection you would do something like this:

 Application.Forms 

As the Application object is the main object, it can generally be omitted when referencing sub-objects. For instance, the example above could simply be written as:

 Forms 

To reference an individual item in an object you must either know its name , or its position in the collection. For example, if you have a form called frmSwitchboard , then you could do this:

 Forms("frmSwitchboard") 

Here we are using the name (" frmSwitchboard ") to find the object in the Forms collection. This is a bit like the way we used a variable to index into a loop, in the previous chapter, and you can use that methodology too:

 Forms(0) 

This would give you the first object in the collection - it's the first object because collections start at 0.

To get further into the hierarchy of the model you just add the next item, separated by a period. For example:

 Forms("frmSwitchboard").Controls(0) 

This would get the first control on the form frmSwitchboard .

A practical benefit of using indexes rather than names is that we can loosely couple our code; that is, if the name of the form or the quantity of forms changed, then we do not need to adjust our code. However, we may need to if we had hard-coded (or tightly- coupled ) the name (" frmSwitchboard ") into our code. Don't worry too much about this now, because you'll be seeing lots of examples using objects and collections as we go through this chapter.