Yellow is the New Blog

Thanks for all the feedback on my recent ramblings regarding LotusScript event binding. Just one more post on this and I'll leave it alone for a while.

Both Thomas Bahn and Devin Olson chimed in on the last article in this series, and Peter Presnell posted a great article about compensating for weaknesses in LotusScript's OOP model, all of which prompted some useful mods to the framework. If you've already downloaded it, you may want to snag a fresh copy.

Thomas suggested that, instead of calling each bound Sub recursively with stack trace checking to prevent infinite recursion in cases where the event handler has not been overridden in the derived class... just bind the event to a delegate function that, in turn, calls the actual event handler. This results in a bit more code within the framework classes, but since the structure is such that you won't need to modify those classes again until new events are added in future versions of Notes, I'm perfectly fine with that as a tradeoff for avoiding recursion altogether. Don't worry, we'll find another excuse to use Nathan's code locking approach.

Devin's comments and Peter's article both provided insight into forcing (at runtime, at least) methods and classes to be treated as abstract, and, as such, overridden and derived, respectively. That was a bit of a mouthful, so perhaps it would be simpler to just show you the most basic of the EventBinder child classes in its current form:

Public Class TimerEventBinder As EventBinder
    
    Public Sub New (Source As NotesTimer)
        Dim classname As String
        
        Let className = Typename(Me)
        If (className = "TIMEREVENTBINDER") Then
            Error ERR_ABSTRACT_INSTANTIATION, MSG_ABSTRACT_INSTANTIATION & classname
            Exit Sub
        End If
        Set Me.context = Source
    End Sub
    
    Private Function bindEvent (Byval eventName As String, Source As Variant)
        Select Case Lcase(eventName)
        Case "alarm":
            On Event Alarm From Source Call delegate_Alarm
        Case Else:
            Error ERR_UNSUPPORTED_EVENT, MSG_UNSUPPORTED_EVENT & Ucase(eventName) & " in class " & Typename(Me)
        End Select
    End Function
    
    Private Sub delegate_Alarm ( Source As NotesTimer )
        Call Me.Alarm(Source)
    End Sub
    
    Private Sub Alarm( Source As NotesTimer )
        If (OPTION_FORCE_METHOD_OVERRIDE) Then
            Error ERR_ABSTRACT_METHOD, MSG_ABSTRACT_METHOD & Typename(Me)
        End If
    End Sub
    
End Class

The end result is a class that cannot be instantiated; to use its functionality, you must create a class that inherits from it. Similarly, in order to attach to the Alarm event, you must override the Alarm Sub with the same method signature (although there's a Const in the framework library that you can change to False to allow silent failure, but if you're not overriding the method, your event will do nothing, so you probably want an error thrown to notify you of the omission). Finally, another error is thrown if you try to attach to an event that doesn't even exist.

All in all, I think this has become a pretty solid framework, allowing you to bind UI events within an OOP context in a straightforward manner. Let me know if you have any additional suggestions for how this should be structured or examples of where it would be particularly useful.