Question : Alternative method of referencing forms in an Access project?

A few years ago I did a quick Access 2003 project that involved a couple of 3rd party custom treeview controls that were used on a variety of forms throughout the project. I came from a .NET environment so I started applying some class-based methodology to the Access project.

One area that I experimented with was referencing forms and controls through a custom class structure. I gathered a series of public functions in a class module that returned a reference to a specific form or control. Whenever I needed to reference a specific control I instantiated an instance of the class, called the appropriate function, and used the returned reference to access the UI control.

This seemed to work without any problems but I was wondering if class structures are relatively inefficient in Access?

 I like the flexibility and organization of using classes as reference factories for forms and controls, as opposed to the more common "bang" notation, but if it slows the project down at runtime then it negates the advantages of the flexibility.

Has anyone else used this kind of form and control  referencing in Access? I am debating using this on a new Access project that involves quite a few forms and controls.

Answer : Alternative method of referencing forms in an Access project?

<<The class approach was mainly to encapsulate all the functionality of form and control objects. In the previous application I used the classes to initialize, build, and update a variety of treeview controls. This new application is mainly datagrids and textboxes, most located on subforms. >>

 Again, your not going to be able to do that here in the typical OOP fashion.  You can't have a base class object, then subclass it and modify it.  Access/VBA supports none of that.

You can create a textbox class and sink events with it and introduce new properties and methods, but it will be the same for every control in the app unless you have separate classes.

<<Does this seem more reasonable from an ACCESS viewpoint? >>

  As I said, it seems I'm lacking the vision as I still really don't understand what it is your going after. This:

Private Sub Form_Load()

GetForm(FORM_MAIN).Caption = "Test caption string"

Dim TempControl As Control
Set TempControl = GetControl(FORM_MAIN, FORM_MAIN_TEXBOX_1)

With TempControl
   .SetFocus
   .Text = "Test"
End With

Set TempControl = Nothing

End Sub

Just doesn't make sense to me in Access.  It would be just as simple and clearer to do:

Private Sub Form_Load()

Me.Caption = "Test caption string"

Me.Text0.SetFocus
Me.Text0.Text = "Test"

End Sub

and without all the extra overhead.  So I don't see any advantage to using GetForm(), GetControl() etc just to get a reference to something.  Maybe what's missing is that normally, a developer will name a control something like this:

txtBirthDate
cbxHIPPAOnFile
lstSelectPatient

for naming of controls and others object (using a prefix), which is easier to work with and really helps with the modification and maintenance chores.

And as far as the routines that you have, no reason to loop through all the forms or controls like that.  Just do:

Public Function GetForm(ByVal sFormName) As Form

   On Error GoTo GetForm_Error

   Set GetForm = Forms(strFormName)

GetForm_Exit:
  Exit Function

GetForm_Error:
  Set GetForm = Nothing
  Resume GetForm_Exit

End Function

  As you can see, Access/VBA already has a forms collection and you can use the syntax:

 Forms(strFormName)

 to get a reference to using a string variable containing the name.  And it has collections for just about every other object as well.

 About the only place where it's required to do what your trying to do is when you need to have multiple instances of a form.  That typically needs to be handled with something like a GetForm(), which would maintain a collection of opened forms as Access/VBA won't handle that on it's own.  But outside of that, there's nothing else I can think of where it's worth the overhead.

JimD.