A Class Wrapping a Form

The class wrapper for a form doesn’t do much of anything. It creates a form object and passes through a few properties. But its most important job is to shield the user from all the form’s unnecessary methods, properties, and events. Here are the properties the form passes through:

' Private form variable
Private about As New FAbout

' Could be App object, or anything with the same version properties
Public Client As Object
' Normally the icon of the client application
Public Icon As Picture
' Miscellaneous properties
Public InfoProg As String
Public Copyright As String
Public Comments As String
Public SecretButton As Integer
Public SecretKey As Integer
Public SecretShift As Integer
Public Animator As IAnimation

None of these properties needs validation, so they can be public variables. The UserInfo property works the same, but requires Get and Let procedures (not shown) because it’s an array. Technically, I could just implement all these properties with Let procedures so that I could have the first class in history with write-only properties exclusively.

The Load method passes the properties on to exact duplicate properties on the form variable. The form is a private form in the VisualCore component. Outside applications have no way to get to it except by setting CAbout properties and calling the Load method:

Sub Load()
With about
    ' We need version properties to display on About form
    If Client Is Nothing Then ErrRaise eeAppNotInit
    ' Pass other optional properties through to form
    Set .Client = Client
    Set .ClientIcon = Icon
    .InfoProg = InfoProg
    .Copyright = Copyright
    .Comments = Comments
    .SecretButton = SecretButton
    .SecretKey = SecretKey
    .SecretShift = SecretShift
    .UserInfo(1) = UserInfo(1)
    .UserInfo(2) = UserInfo(2)
    .UserInfo(3) = UserInfo(3)
    ' Show the form
    .Show vbModal
End With
End Sub

The most interesting feature is the required Client property. From Visual Basic, you’ll usually set this to the App object of your program, but note that it is declared with Object type, not with App type. The App type is private to the Visual Basic library. Technically, Visual Basic ought to display an error if you try to pass the private App object, but it doesn’t. Nevertheless, it’s not a good idea for two reasons. First, the documentation forbids it and says that bad things might happen if you modify and return private objects. That’s not a problem in this case because the Client property will be read but not modified. The second reason is that ActiveX is supposed to be a language-independent standard, and it wouldn’t be very polite to require a C++ client to pass a Visual Basic App object. Therefore, CAbout doesn’t require an App object. It does require that any late-bound object have some of the same properties as the App object—specifically those containing version information. It would be easy for a C++, Delphi, or Java client to create and pass such an object if they knew exactly which properties the About form uses. I’m planning to put the full requirements in the CAbout help file “real soon now” for the benefit of all those thousands of C++ clients who desperately want to use the VBCore component.