<<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.
