[AccessD] Re: [Private] Framework Discussion - Dependent Objects

Ken Ismert KIsmert at TexasSystems.com
Tue Mar 16 12:05:40 CST 2004


My miscellaneous observations:

(Colby, Fri 3/12/2004)
>I am open to interfaces, assuming that you can present a case for a
>significant advantage ... Am I getting early binding out of this so
>that Intellisense works?  If so can I "get at" all of the class
>properties, i.e. not just those implemented?

Yes, you will get early binding and Intellisense, if you use interfaces. No,
you won't get all of the class properties of the underlying object VIA THE
INTERFACE. But you can still get at them. Drawing on Drew's example:

    Dim rFWC As FrameWorkControl
    Dim rCbo As Access.ComboBox

    Set rFWC = New FWComboBox
    Set rFWC.LinkedObject = cboMyCombo
    ' do FrameWorkControl things ...
    If rFWC.ObjectType = "ComboBox" Then
        Set rCbo = rFWC.LinkedObject
        ' do Combo things ...
        Set rCbo = Nothing
    End If

The point is you can use the generic methods of the interface and the
specific combobox methods, and still preserve early binding.

(Brock, Tue 3/16/2004)
> ... Also, and seriously, I find my forms so diverse and often highly
>specialized as I can't see a framework fit in and certainly not worth
>spending the time to build it ...

This is one of the big challenges of frameworks: no matter how suited it is
for you, it often won't fit the unique requirements of others. You can never
build a framework that is big enough for everybody.

However, frameworks can have a payoff in standardization and consistency,
provided that the cost to build and implement them are kept to a reasonable
level.

Which brings us back to the case for interfaces. They are the best way (in
VB6) to provide:

 * Standardization - An interface allows you to define a common set of
behaviors for a group of objects.
 * Extensibility - Interfaces allow you to extend your framework in a
consistent, controlled way. This has two benefits: First, helps keep your
initial investment lower. Define your interface, build only what you need,
and move on. Second, it allows others to more easily extend the framework to
fit their own unique requirements.

When Microsoft wanted to allow VB programmers a standard way to extend
Office, they provided the Office Add-In framework, which implemented the
IDTExtensibility2 interface. This is the COM way of allowing extensibility.

-Ken




More information about the AccessD mailing list