DEEP-object concept – Dynamic External Event Processing objects
(an introduction for advanced MS Access 97/VBA/VB developers)

Shamil Salakhetdinov
e-mail: shamil@marta.darts.spb.ru
All rights reserved. Terms of use.

Written in September, 1998

Originally published on http://www.wji.com/access in September 1998
(www.wji.com/access is down now)

SUMMARY

This article provides an introductory information on how to implement simple DEEP-objects in MS Access 97. DEEP-object is an instance of a custom class bound on run-time to the events of forms, reports and/or their controls. DEEP-object is a way to implement “codeless” yet flexibly customizable forms and reports, create highly reusable inter-application generic and specific custom classes/object code repositories, design, develop and simulate visual layer OLE-servers in MS Access and easily convert/transform them into VB ActiveX DLLs and much more…

MORE INFORMATION

This article presents the following topics:

• Publications of using WithEvents-feature in MS Access 97
• Code Behind Form
• Limitations of Code Behind Form
• Sample “standard” CBF
• DEEP-object – conceptual code to create it
• Object wrapper module
• “Codeless” form
• Another way to create and use DEEP-objects
• Some of DEEP-object concept applications

Publications of using WithEvents-feature in MS Access 97

DEEP-object uses WithEvents-feature of MS Access 97. This feature is poorly described in MS Access 97's online help and technical publications. First public announcement/example of using WithEvents-feature with MS Access 97 visual layer objects I know can be found using this URL (Access-L discussion list archive):

http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind9807D&L=access-l&P=R831

This was a key information I used to find DEEP-object concept as a result of the discussion:

http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind9807C&L=access-l&P=R21471
http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind9807C&L=access-l&P=R21833
http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind9807C&L=access-l&P=R26661

Code Behind Form

Code Behind Form – AKA CBF – is a class module bound to form or report. Since MS Access 2.0 CBF was primarily used to write a code processing events of forms, reports and their controls. MS Access 97 introduced the possibility to create custom class modules separated from forms and reports and extended the concept of CBF allowing to use it to create true custom objects with public properties (get, let and set), methods, encapsulated data and visual layer mock-up – form or report layout.

Limitations of Code Behind Form

CBF is a great concept/feature but it has an obvious limitation – programmer has to bind event processing code to the events on design time. This limitation leads to the usage of code templates and trivial but not easy additional work programmer/utility have to do in the case of template code modifications.

Sample “standard” CBF

In this section you'll find sample "standard" CBF which processes form's and its combo-box's events to navigate in bound form. To use this code you have to:

• Create new .mdb
• Import Employees table from Nwind.mdb as tblEmployee
• Create form in Single Form View (New object: AutoForm)
• Create combo-box cboEmployee on this form
• Set combo-box's properties: Rowsource = "SELECT EmployeeID, LastName, FirstName FROM tblEmployee", BoundColumn = 1, ColumnCount =3
• Insert the following code into form's class module

  
  Private Sub Form_Load()
      Form.KeyPreview = True
  End Sub
  
  Private Sub Form_Current()
      FormContextSynchronize
  End Sub
  
  Private Sub Form_KeyUp(KeyCode As Integer, Shift As Integer)
      FormContextSynchronize
  End Sub
  
  Private Sub Form_AfterUpdate()
      FormContextSynchronize
  End Sub
  
  Private Sub cboEmployee_AfterUpdate()
      With Form.RecordsetClone
        .FindFirst "[EmployeeId] = " & Form![cboEmployee]
        If Not .NoMatch Then
          Form.Bookmark = .Bookmark
        End If
      End With
  End Sub
  
  Private Sub FormContextSynchronize()
      Dim strEditMode As String
      
  ' Set edit mode to show it in form's caption
      If Form.NewRecord Then
         strEditMode = "(New) "
      ElseIf Form.Dirty Then
         strEditMode = "(Edit) "
      Else
         strEditMode = "(View) "
      End If
  
  ' Set form caption to Employee:  
      Form.Caption = strEditMode & "Employee: " & _
                     Form![LastName] + _
                     " " + Form![FirstName]
  ' Synchronize combo-box with the current record
      With Form![cboEmployee]
           .Requery
           .Value = Form![EmployeeID]
      End With
  ' Disable navigation combo-box for dirty form
      With Form![cboEmployee]
        If Form.Dirty Then
         .BackColor = 12632256
         .Enabled = False
        Else
         .BackColor = 16777215
         .Enabled = True
        End If
      End With
  End Sub
  

• Save form as frmEmployee.
• Play with form to see how events are processed

Note: All the code in this article is written without error-handling etc. bullet-proofing techniques to not loose the main subject – DEEP-objects – behind dozen of code lines. Non-traditional usage of Form default object variable in CBF instead of standard Me object variable isn't necessary but it saves you time when you move CBF into custom class module – you can easily find other similar techniques.

DEEP-object – conceptual code to create it

• Create custom class module clsFrmEmployee
• Insert the following code into it

  
  Private WithEvents Form As Form
  Private WithEvents cboEmployee As ComboBox
  
  Public Sub BindMe(ByRef rfrm As Form)
      Set Form = rfrm
      With Form
         .OnLoad = "[Event Procedure]"
         .OnCurrent = "[Event Procedure]"
         .OnKeyUp = "[Event Procedure]"
         .AfterUpdate = "[Event Procedure]"
         Set cboEmployee = ![cboEmployee]
         cboEmployee.AfterUpdate = "[Event Procedure]"
      End With
  End Sub
  

• Copy and paste all the code from frmEmployee's CBF (except declaration lines) into clsFrmEmployee
• Compile and Save clsFrmEmployee

Object wrapper module

• Create standard module named basWrapper/Registry
• Insert the following code into it

  
  Public pcol As New Collection
  
  Public Function BindMe(ByRef rfrm As Form)
      Dim objDEEP As New clsFrmEmployee
      objDEEP.BindMe rfrm
      pcol.Add objDEEP
  End Function
  

• Compile, save and close basWrapper/Registry module

“Codeless” form

• Save frmEmployee as frmEmployeeNoCBF1
• Open frmEmployeeNoCBF1 in design mode
• Delete all the code from its CBF but leave its HasModule property equal to True and set its OnOpen property to "=BindMe([Form])" without double quotes
• Save and close frmEmployeeNoCBF1
• Open frmEmployeeNoCBF1 in normal mode and play with it
• It works as original frmEmployee, isn't it?

Another way to create and use DEEP-objects

• Save frmEmployeeNoCBF1 as frmEmployeeNoCBF2
• Open frmEmployeeNoCBF2 in design mode
• Clear its OnOpen property and close it
• Save module clsFrmEmployee as clsFrmEmployee2
• Open clsFrmEmployee2
• Replace BindMe and Form_Load subs with the following code:

  
  Private Sub Class_Initialize()
      Set Form = New Form_frmEmployeeNoCBF2
      With Form
         .OnCurrent = "[Event Procedure]"
         .KeyPreview = True
         .OnKeyUp = "[Event Procedure]"
         .AfterUpdate = "[Event Procedure]"
         Set cboEmployee = ![cboEmployee]
         cboEmployee.AfterUpdate = "[Event Procedure]"
         
         .Visible = True
      End With
      Form_Current
  End Sub
  

• Compile, save and close clsFrmEmployee2
• Open Immediate window
• Type pcol.Add New clsFrmEmployee2 in it
• You should see now frmEmplyeeNoCBF2
• It works as original frmEmployee, isn't it?

Some of DEEP-objects concept applications

This article seems to be just an introduction to a lot of articles, discussions, sample code, applications and even books which can be written to investigate/use DEEP-object concept. Here are some obvious application areas of it:

• general buttons/keypreview DEEP-objects
• form resize and run-time customizable styles – like CSS
• custom delete
• custom data validation
• custom events (simulating Event feature which is present in VB 5.0 but absent in MS Access 97)
• generic form's error handlers
• componentized add-ins/wizards
• Automation – MS Access <-> MS Office and other WithEvents-enabled apps/OLE-servers integration object interfaces (.mdb components) - huge subject
• multi-tier MS Access apps - again a lot of subjects
• ..…..

DEEP-objects can be used in VB 5.0 too but this is a little bit another story/code.

CONCLUSION

I don't think that DEEP-object concept is an absolutely new concept for Object Oriented and Event-driven programming in general but it seems to be a brand-new concept for VBA (at least MS Access 97 VBA) programming. Please correct me if I'm wrong.

Click to download sample database (deepcnpt.zip - 29286 bytes)